Description of problem: 1) alltray should start with --sticky option by default. Both in command-line mode and in click-mode. 2) Additionally there could be a switch in dropdown menu of the tray icon to change sticky vs. non-sticky mode. 3) In non-sticky mode, unhiding docked application on different workspace produce strange behaviour. The advantage of docking solution is with the ability to access desired program with a single click. If (by default) a docked application opens only on one workspace (the one it was running before docking), one have to remember which workspace was it. With 6-10 workspace it is hard to remember. And even if I remember what it was, I have to switch to this workspace before clicking on tray icon. This way all the idea behind using AllTray is lost. As one need to do more actions than with standard approach (application bar instead of system tray) When using Gnome (with no sticky option), showing docked application when beeing on another workspace ends up with strange behaviour. Application title shows on Application Bar, blinking, but clicking on it does nothing. It doesn't show in current workspace, nor shows on another workspace, nor switches workspace to a proper one. Just nothing happens. In such case, Hiding or Showing with drop-down menu does nothing also. The only way to regain control of the application is to: 1) undock 2) or iterate through all workspaces and click on application bar on all of them, to see if this is a proper workspace for this articular application to show on. Version-Release number of selected component (if applicable): alltray.i586 0.70-3.fc11 gnome-session.i586 2.26.2-1.fc11 How reproducible: allways Steps to Reproduce: 1. dock an application using command-line mode or click-mode 2. switch workspace 3. click on system tray icon Actual results: Application is not showing up. Tilte of the application is blinking on Application Bar. Clicking on it does nothing. There is no symbol of the application on any workspace icon on Workspace Switcher on Panel. There is no indication on what workspace I should look for docked application. After starting AllTray, I have no option to change mode to sticky. Expected results: AllTray starts with --sticky mode, so its behaviour is as expected by the user, who is trying it. And if I choose to start with --no-sticky option, the application should acctualy show on workspace (no minimized) in order to be able to find it (by icon on Workspace Switcher or by iterating through workspaces). Additional info:
I have transferred this request upstream to https://bugs.launchpad.net/alltray/+bug/425833 Since there isn't much use in tracking this RFE in two different places, I would like to close it here and request you to continue any conversations directly in the upstream tracker. Let me know your thoughts.
I have accepted the bug in LP. However, work on the old versions of AllTray is a lower priority at the moment, as I am working on getting out a rewritten, more robust, more modern, standards-compliant and generally more useful AllTray. Should RH/Fedora create a patch for this issue, I recommend branching the old-maintenance branch (bzr branch lp:alltray/old-maintenance) applying the patch there and publishing the branch back on Launchpad. If the happy patch contributor does not have a LP account, I'll also take a merge directive (bzr send --mail-to=mike lp:alltray/old-maintenance) since I can preview/merge the changes that way as well. I'd _prefer_ that LP is used (e.g., bzr push lp:~your_lp_user_account/alltray/fix-unhide or something like that) but it's certainly not a requirement. If a patch is contributed and it works, it will be accepted and merged as soon as I can reasonably do so. However, please note that I am not rolling any more released based on old AllTray, since development is working its way to 0.8.0. However, distributors (RH, Fedora, Ubuntu, et al.) should feel free to merge their distribution-local changes to old AllTray to the old-maintenance branch so that the community has an improved version to work with until 0.8.0 (the next stable) is released.
Hi Michael B. Trausch, Thanks for the detailed reply and signing up here as well. Do you have a ETA on the new release?
The ETA is, well, fuzzy. I am having a lot of trouble with implementing the close-to-tray functionality in new AllTray. Mostly this is due to my lack of knowledge with what's required to do it cleanly and consistently without creating interaction issues between applications and the window manager, and so forth. Last thing I want is to implement a solution that fails to work because it has unintended consequences. The best that I can say at present is that when 0.7.5dev is released, the 0.8.0 release won't be far away from that. 0.7.5dev is intended to be the last release in the 0.7.x development series. I am trying to get my hands on Adrian Nye's book on X11 programming, in the hopes that it will help me to figure out what I am seemingly missing. So far, no luck, though: I am presently horribly broke, and cannot purchase a copy just yet. I would happily accept a copy as a donation towards the progress of AllTray (or, just as happily, certain knowledge of whether or not the book will help me serve my purpose, or even better, someone who is intimately familiar with X11 programming at the Xlib level to help me through it or even write the code and explain it to me so that I can learn from it). In any case, I cannot offer a solid timeline at the moment, and I am sorry about that. The best that I can say is that I will have it released as soon as it is implemented and ready for testing, because close-to-tray is important to a lot of people and I would not consider releasing a stable to replace 0.70 until it's done, and done right.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.