GNOME Bugzilla – Bug 83483
dialog windows in taskbar list
Last modified: 2004-12-22 21:47:04 UTC
Transient-for windows are all listed in gnome-control-panel.
Is this a WM or panel bug? [slowly trying to pick up WM knowledge]
It's a libwnck issue, I'd like to hear from the UI guys on whether they consider it a bug though.
Sorry for wrong address. :-) The trouble is for users in CJK locales. Input methods uses so-it-called lookup-choice windows and they are usually created as popup-dialogs. They can be poped up and down as often as every keystroke in some cases - and will update the panel as many times.
I hate to make such a major UI decision just to work around one app though. I'm sure the input methods are closed source and we can't add "skip task list" hints to them. :-/ Maybe we could hardcode a workaround for specific window classes...
Usability folks? Can you take a look at this? [Didn't realize libwnck did window list too.]
I was not aware of libwnck's skip task list - I'd try this in an input method at least for testing purpose, (But judging from the comments in libwnck/window.h - WNCK_I_KNOW_THIS_IS_UNSTABLE... I'm afraid this API is safe to use.:-) As Havoc said, it would be easier to adapt existing input methods to the workaround. But where can this workaround be prepared? In metacity?
The point about libwnck isn't that it would be used by the input methods, the point about libwnck is that you would put the code in there to ignore dialog windows in the task list. i.e. the task list is in libwnck. To have an input method set the skip tasklist hint, you just need a fairly simple Xlib function, or a GTK patch such as the one attached to bug 83057. I wonder if Metacity should have a blacklist feature, where a file /usr/share/metacity/blacklist.xml contains something like: <metacity_blacklist> <window class="InputMethod" name="foo"> <problem name="does_not_set_skip_tasklist"/> </window> <window class="javax*"> <problem name="popup_menus_marked_transient_for"/> </window> </metacity_blacklist> This is just the matched windows feature which I really hate, but maybe if it's billed as a blacklist of broken apps and only available by editing a text file I could live with it. Since it might let us avoid adding so many workarounds to Metacity for the general case. I don't know though, it would add quite a bit of code complexity and size most likely.
Yeah - I don't want my input methods listed in metacity's blacklist, even saying <authtor="toshi">.. It's great if libwnck would ignore dialogs in the task list. Another UI issue in the current way is users can close dialogs in the task list even if the dialog windows themselves don't have WM decoration or command menu.
mmm, mismatch with WM decoration is also the case with regular toplevel windows? I'll create a test case and open a separate libwnck bugzilla if it's so.
Raised this up to higher/major.
It isn't obvious to me that dialog windows in general should skip the task list, and I have no way to special-case input methods. So I would like someone to check what Windows XP does, and get some UI team feedback.
I'm not really sure that this is a high priority bug. It is irritating, but irritating to a small subset of users of proprietary software and 'fixing' it in the proposed manner would have implications for every one else that may or may not be desirable. Removing the 'high' tag.
A small subsets of users in Asian countries - if this is hundreds, thousands, or 100 thousands order - will be irritated out of this. Not major problem, you say? I'll attach a sample screenshot to demostrate how irritating it is. It's the screenshot when I run a mozilla and opens 4 brower windows of it. There are four "Htt IM Status" windows in the task list as it is created per application's toplevel window. Imagine you have 10 brower window's open and 20 other applications served by the input method, you will see 30 "Htt IM Status" windows in the task list - while they are not necessary to be controlled separately from these transient parent windows.
Created attachment 9215 [details] 4 irritating "Htt IM Status" Input Method dialogs in task list
<hp> I would like someone to check what Windows XP does, and get some UI team feedback. In XP, it's only top level windows that appear in the tasklist, and the occasional app-modal alert box (although they're not really supposed to, they're just supposed to flash the top-level window's entry in the tasklist to draw your attention to it). Things like download progress indicators also appear in the tasklist, but although they look like secondary windows it actually makes sense to have them be top level windows, so you can continue to download a file even after you've closed all your browser windows for example.
Havoc: skip_taskbar_hints works for me but only when I sent the ClientMessage *after* mapping a window. When I send the client message before XMapWindow, metacity does not seem to process the client message event, since "if (window)" test at display.c:line 1369 fails, and does not reach to meta_window_client_message(). Of course, I can first map a window then send skip_taskbar_hint. I'd just like to know if it is expected behaviour or not.
Before mapping the window you need to set the property directly instead of sending the client message. However, I was planning to make the change to avoid putting transients in the tasklist.
Thanks, setting properties to the transients works very well regardless of mapping states. But, yes please - it's much better if metacity(or libwnck) can avoid putting them in the tasklist.
Fixed in CVS libwnck
I must say I really hate this change. Now mozilla download windows don't show on the taskbar, and I have to minimize mozilla to see how the downloads are doing. I agree that maybe pref dialogs could skip the taskbar, but not download progress indicators, I think what Windows does is right this time
There is already an open bug report on mozilla to fix that, as noted in the other bug on this topic.