[Pan-users] pan systray behavior

[Duncan]

This is mostly aimed at Heinrich, and I'd post it to the dev list, except 
for the fact that last time I tried, I couldn't consistently get my posts 
to appear there; some posts appeared, some didn't, with no pattern that I 
could see.  So I'll post here, where my posts DO seem to show up 
reliably. =:^)

Plus, posting here gives other people the chance to chime in with 
disagreements, if any, and the resulting discussion will hopefully hash 
out the differences in opinion. =:^)


I've been routinely using pan's systray option since shortly after it was 
introduced, but it has some deficiencies.  FWIW, commit 29120fa, built 
against gtk2, specifically 2.4.13.

Here I'll compare options and behavior against those of claws-mail 
(another gtk2 based app) with its trayicon plugin active, as it has the 
behavior I'd normally expect.

Options:

claws:  Hide at startup
pan:    Start pan minimized

Claws' option and behavior is expected.  With the option checked, there's 
no minimized window, just the icon in the system tray.  Due to this and 
the below focus behavior, the first time I access pan I have to remember 
to alt-tab or otherwise switch to it (I don't run a taskbar at all, so 
switch using alt-tab, desktop-grid or similar method), to normalize and 
bring it into focus.  Simply clicking pan's systray icon, which SHOULD 
bring up the window, does nothing.  Once pan is normalized and focused, 
if I click the icon, the main pan window hides (not minimizes) as 
expected, and clicking again shows and focuses it, as I'd expect.  But 
the first time, pan's minimized instead of hidden, and because it's not 
focused, clicking its icon does nothing, I have to remember to alt-tab or 
whatever to it.

claws:  Close to tray
pan:    n/a

Claws' option and behavior is expected.  When closed via window manager 
function (traditionally triggered via title-bar button, but the method 
can be triggered using wmctrl's window close method via command-line/
script, or I'm told top-bar button in ubuntu's unity or similar, etc), if 
this option is enabled, claws "closes" to the tray, where it continues to 
run.  Only the window disappears.

To actually close a systray app, one uses either the app's quit function 
(as normally found in the file and systray menus).  The app's quit 
functionality should be entirely distinct from a window-manager triggered 
window-close, which for a systray app, normally means close (or hide, but 
NOT minimize) the window, but keep the app running, still accessible via 
its systray icon.

(Of course one can also invoke app termination using SIGTERM, or via dbus 
quit function invocation, etc, which should still terminate the app, but 
again, that's entirely distinct from a window-manager invoked close-
window, which for a tray app should do just that, close/hide the WINDOW, 
while the app continues to run, with the icon remaining in the tray.)

claws:  Minimize to tray
pan:    Hide to system tray (inexact match?)

Claws' option is expected, but both get the behavior wrong.  The option 
should be minimize to tray, and that's what it should do when the option 
is enabled.  Unfortunately, when specifically minimized (via window-
manager function), neither one actually minimizes to tray, despite the 
claws trayicon option.  Instead, both minimize normally -- the window 
remains in the window-switcher list and presumably shown in the taskbar, 
while it should disappear from both, so the only UI evidence of the app 
is the tray icon.

And I'm not entirely sure what the "hide" in pan's "hide to system tray" 
actually means.  It's obviously not close to system tray, since pan 
actually quits when the window manager's close function is invoked.  And 
it can't be minimize to system tray either, since pan does the normal 
minimize window thing, the window remaining in the window-switcher list.

The only way to actually "hide" the window, AFAIK, is to click the systray 
icon with pan's main window active.  That DOES seem to work, but that 
does NOT seem to be what the pan option actually controls.  It seems the 
pan option actually controls whether the tray icon appears at all, which 
is not how the option is labeled. 

In claws-mail, the option of whether the tray icon appears at all or not 
is separate from the above three options, but appears elsewhere, in the 
plugin config, where activating the trayicon plugin means it appears in 
the tray, regardless of the setting of three options above, which are 
actually trayicon plugin options -- they appear under plugins, trayicon, 
in claws' config dialog, and if the plugin is deactivated, the trayicon 
entry along with its options disappears entirely, there's only the plugin 
option to enable the trayicon plugin again.


Meanwhile...

Pan's tray icon behavior is not as expected in one other way, not covered 
by an option, as well.  Clicking the tray icon when pan's main window is 
shown would be expected to hide it (as it does with claws) regardless of 
which window (other pan window or other app entirely) is active.  

Unfortunately, that's not current behavior.  Currently, the main pan 
window hides on systray icon click IF AND ONLY IF it's the currently 
active window.  If another window (like the superkaramba system-monitor 
window that I have docked at the top of my screen near the panel 
containing the systray, or with focus-follows-mouse, if another window 
appears between the pan main window and the systray and thus gets focused 
on the way to the systray) has focus, clicking pan's systray icon appears 
to do nothing at all. =:^(

It's actually the combination of the initial minimize (instead of hide) 
and the must-be-focused factor that forces me to alt-tab-activate pan the 
first time I want to use it, since it's minimized and not focused, so 
clicking pan's tray icon does nothing, while it SHOULD show pan (not 
unminimize, as it shouldn't be minimized in the first place, it should be 
hidden) and bring it into focus.


Finally, three additional pan trayicon-click behavior corner-cases:

First, assuming the expected (but not yet existent) hide to tray on 
minimize option is UNCHECKED, so pan does a normal minimize (as opposed 
to the hide to tray it would do if checked), there's the issue of what 
pan's behavior should be should pan's trayicon be clicked when pan is 
minimized.

I'd say ideal/expected behavior in that case should be to normalize the 
minimized window, thus requiring a second click of the icon if the user's 
intent was to actually hide the window to the tray.  This is because the 
user may have forgotten that the window is minimized, thinking it hidden 
to tray, thus expecting it to show up normalized on trayicon click.  If 
it shows up, and he knew it was minimized, that shouldn't be a surprise 
and a second click can be used to hide it.

The alternative would be for the first click to hide the minimized 
window, thus requiring a second click to show it, normalized, if that was 
the intent.  But this seems far more confusing, as if the user wasn't 
aware that the window was hidden, it will appear that it sometimes takes 
two clicks to show the pan window, sometimes only one, and that would be 
confusing indeed!

Second, a variant on the first.  What should happen with a trayicon click 
if pan's window is normalized but somewhere down the z-order stack, so it 
isn't visible?

Arguably, this should be the same behavior, again due to the principle of 
least surprise, focus and raise, thus making the window visible.  A 
second click on the trayicon can then hide it.  However, that may be 
complex to try to implement and from my experience, tray-app behavior in 
this regard isn't uniform enough to have a solid expectation either way.  
Thus, simply hiding the main pan window if it's normalized/maximized on 
trayicon click, regardless of whether the window is actually visible or 
hidden somewhere down the z-order stack, thus requiring a second click to 
show the window active and raised, is fine, even if I don't consider it 
ideal from a least-surprise perspective.

Third, another variant.  What happens at trayicon-click when pan's main 
window is on a different virtual desktop?  Does it simply hide on that 
desktop?  Does it hide on that desktop and appear active and raised on 
the current desktop?  Or does it trigger a desktop-switch to the desktop 
it was on, thus showing itself there?

This one's a tougher question, arguably partially window-manager domain.  
I'd argue that pan shouldn't trigger a desktop switch, for sure, because 
that's window manager policy domain.

Pan can thus either simply hide on it's existing desktop, requiring a 
second click to show it on the current displayed desktop (thus pan 
switching desktops in the process of the two clicks, but the displayed 
desktop remains the same), or it can hide on the existing desktop and 
appear on the current desktop with a single click, if it's on a different 
desktop when the trayicon is clicked.

I really don't have a preference here.  People who are using multiple 
desktops should be smart enough to work with either behavior, and I'm not 
sure there's consistent enough behavior to /have/ a principle of least 
surprise in this case.

Pan's current behavior of course forces a switch to the desktop it's on, 
since otherwise it's not focused and thus is unresponsive to trayicon 
clicks, so this question doesn't even apply, currently.  But that will 
obviously change once pan properly responds to trayicon clicks regardless 
of whether it's the focused window or not.  However, I don't have a 
preference as to whether when it's on a different desktop, a click on the 
trayicon simply hides it there (thus requiring a second click to show it 
on the current desktop), or both hides it there and shows it on the 
current desktop.  As long as it doesn't sit there, unresponsive to clicks 
because it's not focused, as it does now, I don't particularly care if it 
takes one or two clicks to make it appear on the current desktop.

Claws' behavior, FWIW:

If a claws window is normalized, it simply hides on its existing desktop 
with the first click, regardless of whether it's visible or hidden, 
current or some other desktop.  So if it's on a different desktop, or on 
the current one but hidden below a stack of windows from other apps, it 
requires two to show it, one to hide it wherever it is regardless of the 
focus state, the second to show/raise/activate it.  If it's actually 
minimized, claws treats that as hidden (tho as I said it doesn't actually 
hide it, it still shows in the alt-tab sequence, etc, behavior that I 
consider a bug when the minimize to tray option is enabled) for purposes 
of trayicon-click, and shows/raises/activates.  (At least with kwin, that 
triggers a desktop switch too, thus showing/raising/focusing claws on 
whatever desktop it was minimized to, switching to that desktop if needed 
in ordered to do so.)

While that differs from my behavior of least surprise as outlined above 
in at least one case, other than the bug that claws does NOT minimize to 
tray despite its option to do so being enabled, its trayicon behavior is 
satisfactory, certainly rather better than pan's at this point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman