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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
