User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: The panel add item dialog sets the _NET_WM_STATE_SKIP_TASKBAR hint. While it may be nice to not have the dialog show up in the (disabled) taskbar, it also disables window cycling. Often I'll have a maximized Firefox behind the dialog, and a misclick will cause me to lose the dialog behind it. At this point, user instinct is go to the taskbar, which doesn't show the dialog. One either A) presumes the dialog has crashed or gone away, leaving your panel in a disabled state, or B) attempt to Alt+Tab to the window, which isn't possible. I think the best solution is to set _NET_WM_STATE_ABOVE in order to keep the dialog out of the taskbar (which is again, disabled) but will prevent the user from losing it behind another window. Alternatively, we shouldn't set _NET_WM_STATE_SKIP_TASKBAR, in order to allow window cycling, but I think that just hides one set of UI problems for another. Reproducible: Always
I'm not a huge fan of _STATE_ABOVE (isn't it _STATE_KEEP_ABOVE? whatever). I think the skip-taskbar-hint should just be removed. I've noticed this myself, and it's a pain when the dialog pops up behind another window (this should be fixed as well) and then it isn't in the alt+tab list. _KEEP_ABOVE doesn't seem wholly appropriate here, though I agree it's better than the current situation.
Bleh, I suck at bugzilla.
_KEEP_ABOVE is a crime against humanity, I agree. The problem is that you're editing what is essentially a desktop level toolbar - you want to make the dialog modal, but you don't have a conventional application window to make the dialog modal -to-. Of course, modal dialogs are kinda a pain as well. This is the kind of problem you want to solve with sheets, but Gtk+ doesn't have any kind of built in support for sheets, and if you ran pre 1.0 Firefox on *nix, you know what a mess it can be to try to implement them yourself. Though this does bring up an idea - would it be possible to make the dialog modal to the panel? Since the panel no longer receives focus, that may not be possible, or require a nasty hack. But if you could click on the panel (whose widgets are all disabled in this context anyway) and bring the dialog to the front, it might be the most elegant solution.
I run into this myself, yesterday. I don't remember setting the dialog explicitly to not show in the taskbar. That would be the easiest solution. I specifically didn't make the dialog modal, since the user should IMO be allowed to change the properties of a newly added plugin, even when the dialog is still open. Also for drag 'n drop I believe the dialog can not be modal (not 100% sure about that). Anyway, I'll see what I can do to make the dialog not skip the taskbar. If anyone else wants to do it, please go ahead. I should be able to have a lool at it myself this evening or this weekend.
Is the dialog a transient? If so, then it doesn't show in the taskbar.
The thing is, all these dialogs should *not* have any transient relationship with the panel. The panel is a dock, and any window that has a transient relationship with it (er eventually belong to the same group) will be treated differently. Idelaly, all doalogs should not belong to the same group. I've posted how to do that on the ML (xfce). I can dig and provide the sample code if needed.
Olivier, you mean calling gdk_window_set_group(dialog->window, dialog->window) on the dialog window? Erik, my vote here is just to not set the skip-taskbar hint, and to call gdk_x11_window_set_user_time() on the dialog to make sure it gets focused and sent to the top of the stack. I really think we should just treat it as a 'normal' window.
Oh, it looks like Olivier fixed the _TYPE_UTILITY problem, which automatically fixed the skip-taskbar and fix-pager problems. Looks like it's being brought to the front and focused properly as well. Aside from the group leader thing, is this bug fixed?
Humm, the group/transient is a theory, I did not actually tested it. So it might be that I fixed that also along with the utility problem ;)
Thinking about it, it would explain why I'm not seeing that bug, now that I'm trying to reproduce it :)
Hey, seems like you guys get by without me just fine ;-) Olivier, thanks for the fix. It seems to work very well for me, so I'm closing this. PS No, I have no idea why that dialog was of type UTILITY. Must have been my alter ego who wrote that...