Firetray Workspace Present; Openbox and others..

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open Thunderbird on Workspace 1 of Openbox
2. Switch to Workspace 2-4 (or whatever)
3. Click the firetray icon (and even try multiple times- no difference).

What is the expected output? What do you see instead?
Thunderbird should come to the current workspace. Instead, it simply stays on 
the current workspace and I cannot access Thunderbird until I switch back to 
the initial workspace it was opened on.

What version of the extension (FireTray) are you using?
Ive tried 0.3.2, 0.3.3 and 0.4.0a2. I should note that 0.4.0a2 operates 
differently; the app will minimize to tray after a click, but ONLY when I 
switch back to the workspace Thunderbird is open on.

What application (Firefox, Thunderbird, ...) and which version are you
using?
Thunderbird 6.0.2

On what distribution, version and architecture (x86 vs amd64)?
Arch linux, Openbox, 64bit

Please provide any additional information below.
Most apps in the linux world that are systray based present themselves on the 
current workspace when clicked. While some window managers force this behavior, 
others do not (Openbox is one of the most popular examples of the latter). 
Xchat for example: if you open xchat on workspace 1, switch to 3, then click 
xchat, the first click minimizes xchat on workspace 1 to tray, while the next 
click presents xchat on the current workspace.

I am going to use this bug report as a reference for Openbox devs; I talked 
with them and they felt that forcing this behavior would cause certain users to 
have issues with other apps, and that ultimately this behavior needed to be 
determined by application's systray itself. Let me know if you need any 
additional information.

Original issue reported on code.google.com by poetic...@gmail.com on 4 Oct 2011 at 5:02

[GoogleCodeExporter]

I forgot to mention: I tried this with fbpanel (latest svn release), tint2, and 
xfce4-panel. 

Original comment by poetic...@gmail.com on 4 Oct 2011 at 5:03

[GoogleCodeExporter]

What is the expected output? What do you see instead?
Thunderbird should come to the current workspace. Instead, it simply stays on 
the initial workspace (not coming to the current workspace I am on) and I 
cannot access Thunderbird until I switch back to the initial workspace it was 
opened on.

**Sorry, I used current incorrectly in my initial post and decided to post a 
comment to clarify..

Original comment by poetic...@gmail.com on 4 Oct 2011 at 5:10

[GoogleCodeExporter]

Issue 214 has been merged into this issue.

Original comment by foudil.newbie on 4 Mar 2012 at 10:49

[GoogleCodeExporter]

Hi, an appropriate option has been added in the latest commit 
(https://github.com/foudfou/FireTray).
Download the source, and build (cd src; make all).

Original comment by foudil.newbie on 4 Mar 2012 at 10:49

• Changed state: FixReady

[GoogleCodeExporter]

[poeticrpm@geekdom src]$ make all
Stripping debug calls from JS file chrome/content/overlay.js
Stripping debug calls from JS file chrome/content/options.js
Stripping debug calls from module modules/commons.js
Stripping debug calls from module modules/FiretrayMessaging.jsm
Stripping debug calls from module modules/PrefListener.jsm
Stripping debug calls from module modules/VersionChange.jsm
Stripping debug calls from module modules/logging.jsm
Stripping debug calls from module modules/FiretrayHandler.jsm
Stripping debug calls from module modules/ctypes/ctypes-utils.jsm
Stripping debug calls from module modules/ctypes/ctypesMap.jsm
Stripping debug calls from module modules/ctypes/linux/pangocairo.jsm
Stripping debug calls from module modules/ctypes/linux/libc.jsm
Stripping debug calls from module modules/ctypes/linux/glib.jsm
Stripping debug calls from module modules/ctypes/linux/gtk.jsm
Stripping debug calls from module modules/ctypes/linux/gdk.jsm
Stripping debug calls from module modules/ctypes/linux/cairo.jsm
Stripping debug calls from module modules/ctypes/linux/pango.jsm
Stripping debug calls from module modules/ctypes/linux/gobject.jsm
Stripping debug calls from module modules/ctypes/linux/x11.jsm
Stripping debug calls from module modules/linux/FiretrayPopupMenu.jsm
Stripping debug calls from module modules/linux/FiretrayStatusIcon.jsm
Stripping debug calls from module modules/linux/FiretrayWindow.jsm
Creating XPI file.
  adding: LICENSE (deflated 38%)
  adding: install.rdf (deflated 67%)
  adding: chrome.manifest (deflated 71%)
  adding: defaults/preferences/prefs.js (deflated 62%)
  adding: chrome/content/overlay.js (deflated 59%)
  adding: chrome/content/options.js (deflated 77%)
  adding: chrome/content/overlay.xul (deflated 45%)
  adding: chrome/content/options.xul (deflated 82%)
  adding: chrome/skin/overlay.css (deflated 58%)
  adding: chrome/skin/message-mail-new.png (stored 0%)
  adding: chrome/skin/firefox32.png (stored 0%)
  adding: chrome/skin/blank-icon.png (stored 0%)
  adding: chrome/skin/seamonkey32.png (stored 0%)
  adding: chrome/skin/chatzilla32.png (stored 0%)
  adding: chrome/skin/firetray64.png (stored 0%)
  adding: chrome/skin/firetray48.png (stored 0%)
  adding: chrome/skin/thunderbird32.png (stored 0%)
  adding: chrome/skin/cbox-check.gif (deflated 6%)
  adding: chrome/skin/cbox-disabled.gif (deflated 7%)
  adding: chrome/locale/en-US/overlay.dtd (stored 0%)
  adding: chrome/locale/en-US/options.dtd (deflated 72%)
  adding: chrome/locale/en-US/overlay.properties (deflated 38%)
  adding: chrome/locale/en-US/options.properties (deflated 29%)
  adding: modules/commons.js (deflated 61%)
  adding: modules/FiretrayMessaging.jsm (deflated 72%)
  adding: modules/PrefListener.jsm (deflated 55%)
  adding: modules/VersionChange.jsm (deflated 65%)
  adding: modules/logging.jsm (deflated 31%)
  adding: modules/FiretrayHandler.jsm (deflated 69%)
  adding: modules/ctypes/ctypes-utils.jsm (deflated 63%)
  adding: modules/ctypes/ctypesMap.jsm (deflated 61%)
  adding: modules/ctypes/linux/pangocairo.jsm (deflated 52%)
  adding: modules/ctypes/linux/libc.jsm (deflated 55%)
  adding: modules/ctypes/linux/glib.jsm (deflated 42%)
  adding: modules/ctypes/linux/gtk.jsm (deflated 79%)
  adding: modules/ctypes/linux/gdk.jsm (deflated 75%)
  adding: modules/ctypes/linux/cairo.jsm (deflated 61%)
  adding: modules/ctypes/linux/pango.jsm (deflated 70%)
  adding: modules/ctypes/linux/gobject.jsm (deflated 67%)
  adding: modules/ctypes/linux/x11.jsm (deflated 66%)
  adding: modules/linux/FiretrayPopupMenu.jsm (deflated 76%)
  adding: modules/linux/FiretrayStatusIcon.jsm (deflated 70%)
  adding: modules/linux/FiretrayWindow.jsm (deflated 70%)
Creating XPI file. Done!

Build finished successfully.


All seems great, but I dont see any xpi file/extension created anywhere. Ive 
checked virtually everywhere- am I missing something really obvious?

Original comment by poetic...@gmail.com on 5 Mar 2012 at 8:34

[GoogleCodeExporter]

it should be created in ../build (that is: in the build/ dir of the project's 
root dir).

Original comment by foudil.newbie on 5 Mar 2012 at 7:43

[GoogleCodeExporter]

Ok, I feel dumb. It was indeed right there. I built this and installed it in 
the latest thunderbird, but I still have the issue. I am assuming it is the 
"Remember Desktop" option in the preferences. Still, the window does not 
present on the workspace I am on. For example, if I open thunderbird on 
workspace 4, switch to workspace 3, and then click the firetray icon in the 
systray, it stays on workspace 4 (no matter how many times I click, etc). I 
must switch to workspace 4, minimize thunderbird to the systray, switch to 
workspace 3, and then reopen. This is on the latest Openbox (by Archlinux 
standards).

I have included a video to demonstrate exactly what im talking about. Whenever 
my mouse is hovering over the firetray icon and I seem to be doing nothing, im 
clicking repeatedly trying to get thunderbird to present on the currently open 
workspace.

http://videobam.com/ZrJMD

Original comment by poetic...@gmail.com on 6 Mar 2012 at 2:51

[GoogleCodeExporter]

Hi, I must be missing something:
* can you confirm that the issue is: with FireTray's "Remember Desktop" option 
off, TB should show to the current workspace instead of the workspace on which 
it was hidden ? (given that the user switched to a different workspace in btw.)
* AFAICS, your video shows that it's working as expected: just after 0:56 
(after you de-select "Activate..." and "Remember..."), you switch from 
workspace 1 to 2 and click on the TB tray icon which shows the TB window on the 
current workspace (2). What happens around 1:04 is unclear: I agree the TB 
window seems to show on workspace 1, whereas you're on workspace 2...
* window managers have a "remember option", check it is not switched on for TB
* the scenario you described works in my environment (Fluxbox with wm and 
FireTray "Remember..." option off):
- open thunderbird on workspace 4 (TB shown)
- switch to workspace 3
- click the firetray icon in the systray (TB expected to "hide")
[this is now added by me:]
- click the firetray icon in the systray: TB shown on current workspace (3)

Could you either provide a more detailed textual scenario or contact me on IRC 
(foudfou on freenode) for further diagnostics ?

Original comment by foudil.newbie on 6 Mar 2012 at 1:24

[GoogleCodeExporter]

It will work on fluxbox, as the window manager itself forces an app to come to 
the current workspace. For example, Pidgin has the same problem as Firetray, 
yet on Fluxbox it is brought to the front (while on Openbox, pidgin has the 
same issue that Firetray/Thunderbird has). This is a design decision of the 
Openbox devs (though it does the same thing on other minimalistic window 
managers); originally I went to them to see if they could code a fix, but they 
directed me to go to the app developer for a fix. You are the developer (or one 
of?) of firetray ;)

I apologize I was not clear; its hard to convey easily in words. I will try to 
be boringly methodical in my explanation. Everything is closed on the desktop 
(no windows at all open) for the sake of clarity. Thunderbird is opened and 
minimized to the systray by Firetray. Im on workspace 1, and I open Thunderbird 
(click on the systray icon so Firetray brings Thunderbird up). I do nothing 
else; with Thunderbird still open and in focus on workspace 1, I switch to 
workspace 2. Then, I click the Firetray icon in the systray. Expected behavior: 
Thunderbird comes to the workspace OR it minimizes to systray on first click 
and presents on workspace with second click (Xchat does this natively). Actual 
behavior: Thunderbird stays on workspace 1 no matter how many times I click- I 
cannot get it to present on workspace 2 UNLESS I go back to workspace 1. Once I 
go back to workspace 1, for some reason Thunderbird is minimized, but a few 
clicks will get it to present on workspace 1, then get it to "minimize" to the 
systray. NOW, if I go to workspace 2, I can click Firetray and it will come up 
on workspace 2. This is what you saw in the video, and I apologize for not 
being clear about this..

In other words, I MUST have Thunderbird "minimized" to the system tray BEFORE I 
switch out to another workspace. If I dont minimize it to systray, Thunderbird 
will NOT be accessible on any other workspace until I: 1) switch back to the 
workspace it is open on, and 2) minimize it to the systray, then 3) switch back 
to whatever workspace I want and bring it up there.

Most apps (xchat, gmusicbrowser, skype, etc) that run in the systray can be 
accessed at any time simply by clicking the icon in the system tray (and this 
is on Openbox, so it can be controlled by the app). Xchat is a little weird 
since the first click minimizes xchat to systray, and the next click presents 
on current workspace. All other apps listed immediately present on whatever 
workspace you are currently using.

Example: I have skype (the contact list) open on workspace 1. I switch to 
workspace 2. I click the skype icon in the system tray, and it (the contact 
list) immediately comes up on workspace 2 right where I am. 
Thunderbird/Firetray does not do this regardless of the Remember Desktop 
option. 

You might have to run a test on Openbox to see the problem; I myself tried 
Fluxbox and noticed that the window manager itself forced the app to come to 
the current workspace regardless of where it was opened. Openbox does not do 
this- it relies on the application to determine what happens in terms of 
"present". 

Hopefully the above is clear :)

Original comment by poetic...@gmail.com on 6 Mar 2012 at 10:37

[GoogleCodeExporter]

Thanks for the detailed explanations.
Still I can't reproduce the bug you describe. I've been testing on 
Fedora16+Openbox, and on a fresh Archlinux+Openbox+Lxpanel.

Here are the steps I followed, with "Remember Desktop" unset:
1. launch TB from terminal on workspace (ws) 1: this shows TB in ws 1 (and 
shows the TB icon in the system tray)
2. switch to ws 2
3. click on TB's tray icon: hides TB in ws 1 (as shown by the panel's pager)
4. click on TB's tray icon: shows TB in current ws 2

I propose you contact me on IRC so we can diagnose further.

Original comment by foudil.newbie on 7 Mar 2012 at 12:58

[GoogleCodeExporter]

Further development: I went ahead and tried a number of other window managers 
and had no issues- works exactly how you describe.

However, I realized something that never dawned on me as a potential problem, 
and it seems that it is in fact the problem: I am running two monitors. I am 
running separate X-sessions with openbox on monitor 1 and another instance of 
openbox on monitor 2.

I normally run Thunderbird on monitor 2- the EXACT problem described above is 
what happens with firetray/thunderbird running on monitor 2. However, when I 
run thunderbird/firetray on monitor 1, it works FINE. I tried Xchat, and the 
EXACT same problem exists on monitor 2 (i run xchat on monitor 1 normally). 
This is either a dual-head openbox problem, or a limitation both firetray and 
xchat shares.

Anything come to mind or do you still want to meet up on IRC? I am GSF1200S on 
freenode and you can contact me at any time. I have tried contacting you, but 
it says user does not exist, so.. If it takes me awhile to get back to you, im 
prolly doing calculus or off at school :)

Original comment by poetic...@gmail.com on 8 Mar 2012 at 3:56

[GoogleCodeExporter]

If you have another monitor or a tv you can connect your computer to, you can 
prolly see what im talking about... this is 100% reproduceable for me

Original comment by poetic...@gmail.com on 8 Mar 2012 at 3:59

[GoogleCodeExporter]

I can confirm that Skype on monitor 2 works exactly how its supposed to: 1 
click brings it from whatever workspace its on to the current workspace. It 
must be how the application tries to handle this operation. Both Xchat and 
Firetray utilize the "one click minimizes to tray, another click brings to 
current workspace" approach, and both of them fail to work on the second 
monitor despite the fact its a second (and theoretically completely separate) 
X-session. Gmusicbrowser (the dev actually coded a fix late last year for this 
issue) and skype work fine on monitor 1 or 2. Coincidence?

Im going to point the devs of Gmusicbrowser and Openbox towards this bug report 
in the event they might be willing to add to it.

Original comment by poetic...@gmail.com on 8 Mar 2012 at 4:20

[GoogleCodeExporter]

I confirm the bug you described. Just tested on the following setup: fedora 16, 
openbox 3.5.0, lxpanel 0.5.6, 2 X-Screens without Xinerama. BTW one must run 
one openbox instance for each monitor/screen, and I had to

 xprop -display :0.1 -root -remove _NET_NUMBER_OF_DESKTOPS -remove _NET_DESKTOP_NAMES -remove _NET_CURRENT_DESKTOP
 DISPLAY=:0.1 /usr/bin/openbox --startup /usr/libexec/openbox-autostart  &

to actually get multiple desktops on the second screen.

Now I'm unsure of how to fix the problem, and don't understand exactly why it 
occurs on the second display, but not on the first one.
You said previously:

"It will work on fluxbox, as the window manager itself forces an app to come to 
the current workspace. [...] This is a design decision of the Openbox devs 
(though it does the same thing on other minimalistic window managers); 
originally I went to them to see if they could code a fix, but they directed me 
to go to the app developer for a fix."

Could you explain what the design decision is, and possibly point me to (or 
cite) the discussion you had with the openbox devs ?

Original comment by foudil.newbie on 11 Mar 2012 at 7:35

[GoogleCodeExporter]

Since we keep missing each other on IRC, ill try to explain here..

Design decision: In fluxbox (as I said), the window manager itself forces apps 
to present on the current workspace. I talked to an Openbox dev in the Openbox 
IRC channel (irc.oftc.net, #openbox)  about possibly giving the user the option 
(via the rc.xml, openbox's config file) to mirror fluxbox's behavior. I asked 
them this since, at the time, I had issues with Pidgin, Firetray, and 
Gmusicbrowser. After we talked a bit, he made the decision that it was not 
practical for them to code a change to Openbox for a very small use case, and 
that if I wanted different behavior in terms of the systray, I should go to the 
application developers and have them change it. It boiled down to: 1) we dont 
want to code for every little feature someone wants else we make openbox 
bloated like everything else, and 2) its not the window managers job to handle 
the scenario, but the application itself depending on what the developer wants. 
As ive said before, the dev of Gmusicbrowser fixed this problem, but he used a 
different way than I believe you are using (as well as xchat is using). If you 
do end up fixing this on firetray, I will immediately file a bug on Xchat and 
link them to this bug and to your code.

I do not have a log as this was all discussed in the IRC channel (scrollback 
not enough)

Original comment by poetic...@gmail.com on 11 Mar 2012 at 9:39

[GoogleCodeExporter]

Hi, I came to the following conclusions:
1. running separate X screens is a kind of extreme usage for Openbox
2. the different window show/hide behaviour in different X screens is not normal
It'd great if you could post a bug report to the Openbox issue tracker to 
confirm that.

Original comment by foudil.n...@bigfoot.com on 8 Apr 2012 at 11:54

[GoogleCodeExporter]

Apologies for the insane delay- end of semester stuff and family issues. I will 
file a bug report tonight and link back to here..

Original comment by poetic...@gmail.com on 10 May 2012 at 12:07

[GoogleCodeExporter]

Alright, well, I talked to dana who is one of the Openbox developers, and shes 
not exactly sure what the issue is. She had this to say initially:

"<GSF1200S> what might I tell the dev or what might the problem be? Im trying 
to use all the channels available to solve this issue :)
<GSF1200S> talked about this issue with you*
* qeed has quit (Quit: qeed)
<dana> GSF1200S: NET_ACTIVE request has completely un-standardized behaviour
<dana> GSF1200S: apps are able to provide both behaviours with an option if 
they like
<dana> and set the desktop to the current desktop before calling NET_ACTIVE, if 
the option is set
<dana> GSF1200S: as much as it's a bug that openbox doesn't move it 
automatically, it would be a bug if it did too.
<dana> GSF1200S: it's completely unsatisfying i'm sure, i find it pretty 
annoying"

I then explained that your extension worked fine on screen 1, and that only 
when used on screen 2 did it fail to work as you designed it. She didnt know 
exactly what could cause that, but gave me a good suggestion- run Openbox in 
debug mode.

When I ran Openbox in debug mode, I made sure I did EXACTLY the same thing on 
screen 1 as I did on screen 2 so the debug output could be sensibly understood. 
I did the following:
1) launched openbox in debug mode
2) used gmrun to launch my panel (so I have a systray to test with)
3) launched thunderbird
4) with thunderbird open on workspace 1, I switched to workspace 2, then 
clicked the firetray icon a total of two times (which should bring it to the 
current workspace). Of course, on Screen 1 this worked perfectly, while on 
Screen 2 it did not.

I then saved this debug output to pastebins so you can examine them:

Working Screen Pastebin: http://pastebin.com/L6feFAJA
Not Working Screen Pastebin: http://pastebin.com/P26pYN17

I am no expert at this, but notice line 84 on the not working pastebin- nothing 
similar to that line appears in the other pastebin, and it definitely seems 
related.

Im about to throw in the towel man- youve coded a fix that satisfies 90% of 
users (since 10% at best use dual monitors) so this isnt really on you. Im 
about to just switch my monitors where my screen 1 appears to me as screen 2 
(haha). Let me know if you need any other info..

Original comment by poetic...@gmail.com on 10 May 2012 at 1:38