why developers don't make their software independent from DE ?

ahmed.alamassi · 2015-08-01 16:00:02

I not a programmer and new to gnu linux , there will be lots of mistake (don't speak English well)

wouldn't be better if a software does not depend on a Desktop environment ? because it will have a fewer dependencies ,will be faster because it will not pull lot of dependencies into ram , easier to port to other platforms , and be more modular(you can easily remove the software without removing a bunch of other apps ) ,lower hard disk space is needed ( for example I use gnome and want to keep using gnome But I like to use some kde apps like Dolphin , kdenlive .. but hate the idea of downloading a lot of kde dependencies) and hate the idea that these apps will run slower because more dependencies is needed to be on ram.

when I heard the word "desktop environment" for the first time , I thought it means collection of apps that manages desktop like : taskbars , menus , desktop widgets , decorations etc.
I was wrong , It's more than that , take kde , kde is like almost a WHOLE operating system with many software for all categories , I know you will tell me if you use kde then only use kde apps and avoid gnome and gtk apps , But I can't do that because some if the app is really good and some of it is bad , so why those developers expect the user to use only kde and not any thing else ?

I know theres desktop independent apps , but its very few and bad quality
I don't mean lightweight , I mean apps that doesn't depend on desktop evironment like : VLC Leafpad Xarchiver pcmanfm firefox , why developers don't make apps like those ?

and another question , why there is no a universal system configuration tool that will work in all distro's ? somthing like yast or kde\gnome control center but be desktop independent and work for all distro's and all desktop environments ?

Last edited by ahmed.alamassi (2015-08-01 16:08:27)

karol · 2015-08-01 16:10:30

Users may want to have uniform look and feel, you can reuse code if applications depend on a common base etc.
Different people want different things in different ways, so One True DE / OS / system configuration tool https://xkcd.com/927/

You're not alone in your quest, some people don't even like toolkits: https://bbs.archlinux.org/viewtopic.php … 2#p1237042

Have you asked e.g. KDE devs why do they do things the way they do?

ewaller · 2015-08-01 16:16:48

Moved to GNU/Linux discussion.

drcouzelis · 2015-08-03 14:05:07

Desktop environments provide functionality in libraries that makes it easier to write software.

I don't care about what libraries were used to make an application. I use GTK2, GTK3, Qt 4, Qt 5, KDE, GNOME, and other applications. I use any software that provides the functionality I need. They are all fast enough and smooth on my computer from 2009. The extra libraries they install only need a few extra MB on my hard drive. The partition for my operating system uses less than 10 GB of space. I have 4 GB of RAM (no swap space) and have never come close to filling it up.

I don't discriminate. I just use the applications that work.

Trilby · 2015-08-03 15:11:47

I don't know of any software that depends on a DE - many programs do depend on Toolkits that are associated with certain DEs. And although I am snarky about toolkits on a regular basis, it is only an expression of my personal taste - I also support fair criticism. To that end:

ahmed.alamassi wrote:

... because it will have a fewer dependencies ,will be faster because it will not pull lot of dependencies into ram , easier to port to other platforms , and be more modular

These five claims would be (in order) Debatable, Probably False, False, Completely False, and Debatable.

1) Fewer dependencies: reimplementing a toolkit would certainly avoid the dependency, but then the new program would have to be that much larger, and that much buggier. If you need widgets, use a widget toolkit: don't reinvent the wheel. My gripes with toolkits is when people add widgets when no widgets are needed (e.g., mpv works great for me, I don't need menu's and buttons on a video player, in fact I much prefer it without gui buttons).

2) Faster: I doubt it. Comparing something that needs no widgets to something that needs widgets is not a fair comparison. If you need widgets I'd bet my last dollar that gtk/qt will create them more efficiently than anything you whip up over night.

3) Less ram use: completely false. Toolkits, like any other library, can be shared and reused. So unless the program you use is the only one that uses that toolkit, nothing else will be pulled into memory. If you hack together your own widgets, then all your code for those widgets will have to be pulled into memory. So if you need widgets, reuse the widget code that is already loaded in memory. Just like if you need a libc, use the libc already loaded in memory rather than reimplementing it yourself. This critique has nothing to do with toolkits, and is essentially a claim that shared libraries waste ram. Nonsense, that couldn't be farther from the truth.

4) Portable: ARGH, no! Definitely not. If you want portable, use the darned toolkits. In fact the need for portable code is the one and only thing that has me considering using a toolkit for one of my projects. I love writing Xlib code - see 'interrobang' for one of my relatively popular projects. Interrobang runs on X11 and on X11 only. It would never run on any other system. It couldn't even run under Wayland. In contrast if you take any gtk app, porting that gtk app from linux to Mac to Windows, or even to android/iOS phones probably wouldn't be much work at all. For the portability-requiring project I'm working on, I've been using freeglut, which is a version of Glut, which stands for GL Utility Toolkit. Another example was Slider, which in it's first incarnation relied heavily on X11 drawing, and it couldn't even run in Ubuntu! (I think because of Mir related stuff I don't understand).

5) Modular: This depends what you mean by modular. Something that reinvents the wheel is not modular: leave the wheels to the wheel makers. Toolkits are then more modular: one library for widgets, other code for the program logic.

Now, overall I agree with you: I wish there was more of an effort to write toolkit free code when there was no need for a widget toolkit. But let's stay on point on what the pros and cons are. Again, MPV works great without a widget toolkit. But if some program needs widgets, buttons, menus, and the like, then use one of the toolkits; that's what they are for.

Awebb · 2015-08-03 15:44:54

Creating standards is work. You need to come up with something sane and then convince the rest of the world, that you are not and idiot but that they are. While this works well in completely new fields in 2015, where the importance of portability and interoperability is a well known factor, the software ecosystems have grown organically over the past five decades. Yes, five decades after computers have become some sort of a thing people talk about in public and the inception of the shell concept in 1964 on Multix, people have been divided about basic design principles. For every problem exists a multitude of solutions and every author thinks their solution is the best, because it is not general enough and mostly tailored to a sub-class of problems. Ideas often conflict, so we have multiple paths.

Some problems that have not been solved since the pre-GUI days in a consistent way:

* undelete mechanism: UNIX and friends simply ignore the problem, shifting the responsibility to the user.
* programming languages per class of language: Instead of narrowing down the number of languages for better cooperation, a new language is spawned for every new problem of any kind.
* shell syntax: While most of not all UNIXoid shells are POSIX compliant, who wants to script in pure POSIX?
* IPC: Will you use dbus or some sockets or named pipes directly? The systemd.socket manpage does not mention dbus once, I wonder if that means it's assumed to be the default or another implementation.

Problems of the GUI age (excerpt):

* configuration hierarchy and syntax: JSON? INI? XML? $HOME? $XDG_CONFIG_HOME? $HOME/.config? dconf? That's just Linux. Every program on Windows seems to have its own syntax and idea where to put files, plus registry.
* message board syntax: Try porting message board posts from one board software to another. I frequent three sites with three different BBCode dialects alone. There is no unified markdown syntax.
* data types: What do a Python dictionary, a JSON string and a MongoDB entry have in common? Enough to make you careless, not enough to make you sleep well at night.

Now we will cross a certain line and actually accuse people of being an idiot. Imagine you write software and you have a look at KDE. I'm not actually sure all those things happen the way I describe them, so take this as a theoretical example of thoughts going through the mind of a developer:

1. KDE has this baloo/akonadi/nepomuk/PIM thing, a central source of information for your software to process. In simple, abstract and hypothetical terms, it makes your music player aware of some things going on in your mail client and other things not that obvious at the first glance.

2. Now you want a button in your mail client, that inserts whatever song is currently playing in the music player. While the obvious choice for that task would be D-Bus (our IPC behemoth), every music player will have its own interface to ask for the information and its own way of replying. Since you want more control about your email content, maybe you only want the artist, your mail client would need to know every single dialect for "currently playing" on the planet. Now you want the same thing in your messenger and in a script that sends strings to your watch over a microwave sidechannel or whatever. Since you don't want to copy-paste the same code again and again, you wrap the knowledge about the way mediaplayers communicate the "currently playing" problem in a library.

3. Since you're on KDE anyway, you want that thing to show up in the KDE notification system. In the past there was a simple notification daemon (libnotify and friends), that would wait for D-Bus stimulus and notify upon request. Since fine tuning such a system is a chore, you decide to move the responsibility to the daemon, the daemon still accepts stuff over D-Bus, but starts managing the sources and contents before outputting it. You don't want to re-invent the wheel and search your machine for libraries with functions fitting for your task. KDE is installed, you have been using it forever, why not use a KDE library?

4. Since so many people use KDE, you have started to publish your libraries and tools. You feel great, so many people find your code useful.

5. A Gnome user requests a version of your stuff based on a Gnome library. You tell the user you don't have a) the time and b) the experience with Gnome libraries and that Gnome lib is missing a class you know from the KDE libs anyway and since you are not interested in writing it (or probably not competent enough) and especially not maintaining it for a system you don't use (and probably don't want to use), so you tell the user to create his own fork or at least "fix" the missing classes in the upstream Gnome lib. The user gratefully starts forking your project, realizes he doesn't know enough about KDE libraries to understand your code, starts writing new procedures and pushes them upstream to the Gnome libraries. Since the user didn't understand your code, the procedures are not compatible and so you still have no interest in maintaining a Gnome version.

6. Five years later, your "currently playing" solution is the default in KDE. The former fork of your work is now the default in Gnome. Instead of maintaining a common code base, the two of you have been happily hacking in different directions. Everything that uses either of the solutions needs a fundamentally different interface and is not compatible with the others. Somebody decides to write a bridge module, but since running KDE applications in Gnome and vice versa is such an unpleasant experience, no patches arrive and the project is forgotten.

7. Some people dislike KDE/Gnome, but love Qt/GTK, so they fork and rewrite the respective parts with native the Qt/GTK calls, because nothing in the KDE libraries, that is not specific to KDE, is unique to the KDE libraries and can be reproduced with other toolkits.

8. Some people realize, that IPC regarding pure text information and document/database style structures are really nothing you need a GUI toolkit for and write a small, flexible cool library, that does the job with pure D-Bus. The project is abandoned after a while, because most player authors only care about their KDE/Gnome/Qt/GTK users and find, that users of non-DE systems usually prefer a less verbose style anyway, so they never bother supporting the project.

9. Step 8. is being repeated. Step 9. forks into step 10., so you can continue reading. If there already is a step 10., step 9 will call that fork instead of forking again. Just to make sure...

10. Even if one of those libraries from step 8. would have survived their first winter, chances are somebody doesn't like it and creates a fork, say, a disgruntled FreeBSD user, who does not want D-Bus just for a toy tool. Feel free to infinitely loop over step 8. with different arguments.

I promised to call somebody an idiot. They all are. If they weren't they would have gathered and discussed and found a common solution, that is compatible, lightweight, elegant, portable and sane. Instead they have spawned a million "Why does my particle cannon not send a notification when the ammo is empty?" posts on the Ubuntu forums.

ahmed.alamassi · 2015-08-04 08:13:09

thanks Trilby and Awebb.
that answered my question and more , very informative

Sara · 2015-08-07 23:21:57

There needs to be an upvote button for your post Awebb, very nice. That is, if there is some standard upvote button for forum software~

Arch Linux

#1 2015-08-01 16:00:02

why developers don't make their software independent from DE ?

#2 2015-08-01 16:10:30

Re: why developers don't make their software independent from DE ?

#3 2015-08-01 16:16:48

Re: why developers don't make their software independent from DE ?

#4 2015-08-03 14:05:07

Re: why developers don't make their software independent from DE ?

#5 2015-08-03 15:11:47

Re: why developers don't make their software independent from DE ?

#6 2015-08-03 15:44:54

Re: why developers don't make their software independent from DE ?

#7 2015-08-04 08:13:09

Re: why developers don't make their software independent from DE ?

#8 2015-08-07 23:21:57

Re: why developers don't make their software independent from DE ?

Board footer