3 ms·
Tray icons in Gnome are not about big ego guy. The issue is entirely different, rooted in different problem. Systray appeared for a first time in Windows 95, w
by vetinari 6y ago
Tray icons in Gnome are not about big ego guy. The issue is entirely different, rooted in different problem.
Systray appeared for a first time in Windows 95, which had no notion of services, say nothing of user services. Here it started to be abused, at first for quicklaunch scenarios (where an app preloaded itself into ram or disk cache at least at login, so when the user clicked the app icon, it launched "quickly"). Later it started to be abused by apps to make them difficult to turn off (Skype is the classic example). The respective developers redirected all the WM_CLOSE to just minimizing the app, removing it from taskbar, but kept the app running and restorable in the systray. Many users were frustrated that they are not able to quit the app (if they noticed), power users just nuked them from the taskbar.
Models like this are not acceptable on a modern desktop. Even if some people are used to this and cannot imagine something different.
It was Android that came with solution for this: split the app into the UI (Activity in Android parlance) and the background task (the service). The background task cannot interact with the user directly, but it can communicate with the UI (if/when it is running) and send notifications when it needs attention, so the user can launch the UI for ecample (one nice thing is that notifications persist even if the process originating it crashes). It can be launched by the system at login (i.e. as systemctl user service on linux desktop), or it can be launched on demand by the UI part, and it can be similarly terminated. The UI can do many things, but one thing it can't do is to keep it's process running once the user closed all it's windows (Gnome-on-Wayland started to check for this and complains to the user about that, offering whether to quit the app or not).
This model works greatly for apps that genuinely need to run in the background, check for things and on some event notify the user (mailbox monitors, instant messaging, file sync, media players etc). It does not work for apps, which want force themselves on the user, do something that the app developer wants but user doesn't (i.e. Skype) or those who have no reason to be in a background, but they do anyway (VLC for example, where users click on video, but since it is already running and it allows only for one instance so nothing happens then, frustrating user again). The split into UI/service is also positive in that the resources needed to run while in background are lower; all the assets the UI needs are only loaded, when the user launches the UI part.
Meanwhile, AppIndicators & co extensions are there until the developers migrate their app to the newer model. Which takes a while, Rome wasn't built in a day either.
- simion314 6y agoThis logic is fine for GNOME apps, sure use client side decorations, use background jobs, remove advanced options etc but GNOME can't force non GNOME apps top follow their big ego designer vision, there are also old application and games that can't just implement client side decorationbs because GNOME want to force their shit. So I see people like you that complaint hat Canonical did not implement X in snap(like third party repo) but defend GNOME that is rejecting keeping functionality with other applications with excuses like - GNOME devs are too busy to read and accept your patch (maybe Canonical devs are busy too) - GNOME devs don't want to add your patch that adds a checkbox to give you an option because is to much work maintining it (maybe Canonical thinks is too much work to maintain that third party repos patch) - GNOME devs don't want to support other applications and toolkits, is only the GNOME way or if you don't like it use KDE (then same should apply for snaps, you don't like it use flatpack) - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc) - there is a large number of GNOME users that want tray icons, then GNOME response is "you are stupid, we know better, use something else or patch the code with an extension - you should apply same excuse for Canonical) Hope I made it clear, there are some double standards here, so we should be more consistent, probably both snap and GNOME are less user targeted and dev/designer ego driven since nobody pays for the product the user requests are ignored.
- vetinari 6y agoI will use just one example to demonstrate that your double standards are not really double: > - systemd has some Google DNS hardcoded int he code, if you don't like it ask your distro to change it or recompile it yourself (then please apply same for snap, ask you distro to recompile, patch it , etc) Systemd has a default fallback hardcoded to Google DNS. Yes, distributions can compile in another default fallback. At the end of the chain, someone had to pick something, that works. The users can configure whatever they want - no need to recompile anything, just config file - and once they configure something, the default fallback is no more, the option picked by the user is used. Canonical's snap store, on the other hand, is not a default fallback. It is only one option allowed, and if you don't like it, tough luck. Wrt. the discussion, there are tree possibilities: - you don't understand the nuance that makes the difference between those two situations; - you willingly misrepresent two different situations as one; - you don't understand what you are talking about. Anyway, in all three cases, there's no point to any further discussion.