By default, no app should minimize to the system tray instead of quitting
Open, Needs TriagePublic

Description

Just what the title says.

ragreen created this task.Mar 30 2018, 6:38 PM

Please explain what you mean by that.

Say Akregator. I open it. I close it. It gets pined to Notifications. And it remains pinned to Notifications even after reboot. Closing it does not mean you quite it.

Integration is good but too much integration is bad.

rikmills moved this task from Packaging / Devel to Inbox on the Kubuntu board.Mar 30 2018, 7:23 PM

Are you referring to it minimizing to the system tray?

If so, (correct me if I'm wrong), it asks you if you want to quit _or_ minimize to the tray the first time you try to quit it.

Are you saying that Kubuntu should disable the behavior of apps that minimize to the system tray when closed, and that instead they should always quit instead?

I don't personally oppose this, but, again, it sounds like this might be better off as a series of upstream requests to change the default behavior for the apps in question.

ngraham renamed this task from No app should pin itself to Notifications by default to By default, no app should minimize to the system tray instead of quitting.Mar 30 2018, 8:28 PM

The targeted user has no notion of up or downstream. For them it's just Kubuntu. I'll load Kubuntu again, then I should be able to elaborate properly.

Akregator isn't running ...


It is now ...

This should terminate it, but it does not ...

Nor does this ...

Nor this ...

This does ...

This does as well ...


Terminated ...

Ktorrent isn't running ...

It is now ...

This should terminate it, but it doesn't ...

Nor this ...

Nor this ...

This does ...

This does as well ...

Let's not terminate it ...

Let's just "close" it ...

Apparently, it's terminated. But we know it isn't ...

Now, let's reboot ...

It' still there and "open"

My point is coming after a break ...

This comment was removed by ragreen.

Oh, forgot to mention: if you don't terminate properly, some apps will still be running even after a full shutdown & startup.

The golden rule for terminating apps is coming shortly ...

For most of these, they are designed or their nature is to be persistent and/or run in the background while you do something else. As such, that they close to the tray by default, and require a more deliberate effort to close them fully is actually helpful. In cases where apps with tray icons don't do this, or it has become turned off for some reason, it is quite irritating to click the X, expecting to send the app to the tray, only to find it has completely exited and you need to re-launch it.

-1 for changing what is a reasonable and expected default for these apps.

ngraham closed this task as Wontfix.Apr 2 2018, 5:54 PM
ngraham claimed this task.

As Rik says, some apps--like the ones you mention--are designed to be always running (for good or ill). There's always going to be the potential for confusion for these apps. That's just the way they've been designed, and if this isn't working, the real solution is not a distro hackaround, but rather more UX work on the apps themselves.

Konversation has a kludgy but possibly adequate solution: it shows a pop-up message when you close the window asking if you meant to quit instead of minimizing to the tray (you can turn it off or make it not show up again). Probably other KDE software that minimizes to the tray by default should adopt this UI convention.

Please report upstream and file bugs against the individual apps where you would like to see a behavior change or a better UI.

ragreen added a comment.EditedApr 2 2018, 6:35 PM

An example of an app that follows the golden rule is Kate.
Not running ...

Running ...

You can terminate it from ...




Terminated ...

(I'm quite sad. You've stopped me right there. I haven't dealt with multimedia yet, which, as implemented, just adds to the mess. You just can't blame upstream for everything)

Integration is only good when it serves a well-founded purpose and does not cause an unintuitive mess. Some standardization is desirable.

Integration is only good when it serves a well-founded purpose and does not cause an unintuitive mess. Some standardization is desirable.

(I'm quite sad. You've stopped me right there. I haven't dealt with multimedia yet, which, as implemented, just adds to the mess.

You just can't blame upstream for everything)

You've described a series of usability issues that are not Kubuntu-specific. What's the issue with reporting these issues upstream?

I hope I haven't upset you. But in a multi-layered software project with multiple upstreams and downstreams, it's important to find the right level to make the fix.
In general, it's vastly preferable to fix or improve things upstream than to patch or work around them at the distro level. It's not a matter of blame, it's a question of where the right place is to make the fix.

A good example would be T7854: Use default wallpaper as background for KScreenlocker and SDDM lock screen. We made this change here in Kubuntu only because the upstream task (D11308: Use the default Plasma wallpaper on the lock screen) has gotten derailed with bikeshedding and was not fixed in time for Kubuntu 18.04. We made the change here so as not to deprive our users of something better than the status quo until the time when the ultimate fix is produced upstream in the KDE world (which might be many months away).

For this issue, I would encourage you to file bugs on Akregator and KTorrent requesting that they adopt the Konversation UI and ask the user whether to actually quit, or to minimize to the tray instead.

You've described a series of usability issues that are not Kubuntu-specific.

What would you define as being Kubuntu-specific?

You've described a series of usability issues that are not Kubuntu-specific.

What would you define as being Kubuntu-specific?

Here are some examples:

rkflx added a subscriber: rkflx.Apr 2 2018, 8:11 PM

Konversation has a kludgy but possibly adequate solution: it shows a pop-up message when you close the window asking if you meant to quit instead of minimizing to the tray (you can turn it off or make it not show up again). Probably other KDE software that minimizes to the tray by default should adopt this UI convention.

Basket once had a nice feature to make users more aware (which seems like the root issue here) of an app developer's decision to close to the tray: http://basket.linux62.org/systemtray-on-close-info.php

(LikeBack was nice too…)

@ngraham Thank you.

You're welcome! As you can see, in general we should only resort to patching or changing behavior of KDE software in Kubuntu if:

  • Kubuntu folks are strongly in favor of it, and...
    • KDE folks have refused the proposed change or...
    • KDE folks plan to make the proposed change, but will not have it done in time for us

It makes everyone's life easier if upstream changes are made upstream wherever possible. This is not just for Kubuntu, but for every software project with upstreams and downstreams.

ragreen reopened this task as Open.Apr 2 2018, 9:59 PM

Are you saying that Kubuntu should disable the behavior of apps that minimize to the system tray when closed, and that instead they should always quit instead?

Indeed, I am.

This comment was removed by ragreen.

T8187

I've noticed the single vs double click debate. Seemingly, the purpose of switching the default to double is to ease usability for some people coming from Windows. Fine.

Apps minimizing to systray instead of quiting (terminating) when they are closed Windows-way is also a usability issue for those people, or not?

It seems to me you're using double standard (https://en.wikipedia.org/wiki/Double_standard) when taking decisions, or not?

Ray, I get the feeling that you think I'm picking on you here, but I assure you that's not the case! :) Rather, I'm trying to guide you through a process that seems to be new to you.

As I've mentioned before, in software projects where code is pulled from upstream sources, and packaged or consumed downstream, there are many possible places to fix a bug, but usually only one of them is the optimal one. We should always try to resolve issues at the optimal level first, and then only later, as a last resort, should we try a different level.

In this case, you have identified a usability issue with two pieces of KDE software--Akregator and KTorrent. The issues that you bring up are real. However, your proposed fix--changing the default settings via the Kubuntu packaging--does not seem optimal to me because:

  1. These apps have been designed around their existing minimize-to-tray behavior.
  2. There are fairly simply usability improvements that can be made in the upstream code emulating the Konversation example, as I've pointed out.
  3. Fixing issues upstream ultimately benefits every KDE user, not just those using Kubuntu.

So I have repeatedly encouraged you to instead engage with KDE upstream rather than Kubuntu to get the software improved, because what I believe to be the best way to resolve this issue requires code changes to the affected programs. And the best place to make code changes is in the app itself--not in the packaging. Here in Kubuntu-land, we only patch software as a last resort, and as little as possible. Kubuntu people's areas of expertise tend more towards the side of packaging and software delivery, and less so in software development.

In the case of the single-click-vs-double-click issue, it has nothing to do with Windows-friendliness; it's rather an issue of consistency, as every other desktop platform (Windows, macOS, GNOME, Cinnamon, etc) all use double-click by default. In addition, I have repeatedly started and led discussions on the subject upstream of Kubuntu in the KDE world--you find one of them, in fact. The reason why we changed the packaging in Kubuntu was because upstream KDE isn't willing or ready to make the change there, and there is a genuine difference of opinion between KDE and Kubuntu people, reflecting our different perspectives. Only in this circumstance do we reluctantly change the setting here in Kubuntu--but note that it's just a simple packaging change. It doesn't require any code changes, or even cherry-picking a patch or git commit.

ach added a subscriber: ach.Apr 6 2018, 4:13 PM

IMHO instead of filing bug report for the apps, it may make more sense to first add a describtion of the 'right' behaviour to the KDE human interface guide line https://community.kde.org/KDE_Visual_Design_Group/HIG . Maybe a new phab task and invite the developers to the apps of the apps that do it 'right' and 'wrong' to the task?

In T8378#137058, @ach wrote:

IMHO instead of filing bug report for the apps, it may make more sense to first add a describtion of the 'right' behaviour to the KDE human interface guide line https://community.kde.org/KDE_Visual_Design_Group/HIG . Maybe a new phab task and invite the developers to the apps of the apps that do it 'right' and 'wrong' to the task?

Since it's not a bug proper, your suggestion is better.

Steam, Discord, Spotify, many Email Clients, many torrent clients, VPN clients, Twitter Clients, and many more close to the system tray as a default function.

rkflx removed a subscriber: rkflx.Aug 2 2018, 6:46 PM
ach added a comment.Aug 2 2018, 11:31 PM

Let's try to define what we^W I are trying to define:

If an app show/uses a systray icon, then

  1. Closing the (last) window of the app with

    Ctrl-W or with the (x) icons in the titlebar, closes/hides the window but the app is running in the background and systray icons is visible
  1. Clicking several times on the systray icon, results in the cycle: a) raise to top or open the app window b) hide the app window a) .. b) ...
  1. Using Ctrl-Q closes the apps (ends the process) and therefore the systray icons too.

E.g, telegram uses the described except IMHO important 'raise to top' is not implemented.

Open/to discuss is what happens when several virtual desktops are used?
Jump to the virtual desktop that has the app window or move the app window
to the current desktop (my favorite), has it would be the case when a closed window is created again. Maybe this topic should be discussed in it's own task?

Achim