Chris Moore <dooglus@gmail.com> wrote on the devel ML: I'm having problems with xfwm4 and an app (synfig-studio) which makes a bunch of dialog windows, using the xubuntu live CD version 6.06. xfwm4: Installed: 4.3.90.1svn+r21712-0ubuntu1 The application sets the dialog windows to be 'utility' windows using set_type_hint(Gdk::WINDOW_TYPE_HINT_UTILITY); This prevents the windows from showing up in the taskbar. With metacity, clicking on the main app window brings the dialogs to the front but with xfwm4, they stay hidden. This makes it hard to find the dialog windows once they've been covered. Clicking the 'show desktop' icon exposes them, but this is a little inconvenient. Is this a bug in one of the two wms?
The spec [1] says: /_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window./ Because of the nature of utility windows, xfwm4 choose to set the skip taskbar/skip pager hints on utility windows (metacity does the same btw). One improvement could be to ignore the UTILITY type of windows unless the WM_TRANSIENT_FOR is set. That would definitely help with such applications. Can you open an terminal, run "xprop|grep TRANSIENT" and click on one of the utility windows and check if the WM_TRANSIENT_FOR is set?
Chris Moore <dooglus@gmail.com> wrote on the devel ML: There can be multiple canvas windows open at a time, and we would want the dialog windows to be 'transient for' all of them. ie. whichever of the canvases is clicked on, we want the dialog window(s) to be brought to the front as well. Is it possible for a dialog window to be 'transient for' more than one window at a time? But then all the dialog windows would appear in the task bar wouldn't they? What I'm wanting is for them to not take up space in the task bar (for they are pretty much useless without a canvas window also being shown), but for them to pop up whenever any of the canvas windows is clicked on. This is exactly what metacity is doing, by the way. $ xprop|grep -i -e transient -e window_type _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
Revision 25409 in SVN implements what you want (I built synfigstudio to check). You can grab snapshots here: http://foo-projects.org/~olivier/preview/
Created attachment 1086 Make all UTILITY and DIALOG window transients
Committed in SVN
Created attachment 1283 Do not make DIALOG windows transients
(In reply to comment #4) > Created an attachment (id=1086) [details] > Make all UTILITY and DIALOG window transients > I don't think it's a good idea for DIALOG windows, because it is not possible to create parentless dialogs now. There are softwares which use modeless dialogs with null parent where the goal is to be independent from the other windows and these are unusable now.
Sorry, but, can you elaborate a bit, how does this make the dialogs unusable? A simple sample program that shows what you mean by unusable would be useful too.
Created attachment 1285 main window covered by other windows sample (In reply to comment #8) > Sorry, but, can you elaborate a bit, how does this make the dialogs unusable? A > simple sample program that shows what you mean by unusable would be useful too. So... I attached a small wxwidgets program, it has a main window and one may create modeless dialog windows with NULL parent. The problem is: under XFCE 4.4.1 the main window is covered by the dialog windows, it cannot be brought to front. This does not happen with this small program under XFCE 4.2.3, KDE, Windows XP and other X window managers. And I have some software which is unusable because of this behaviour.
> This does not happen with this small program under XFCE 4.2.3, KDE, Windows XP > and other X window managers. And Mac OSX 10.4 too.
(In reply to comment #9) > Created an attachment (id=1285) [details] > So... I attached a small wxwidgets program, it has a main window and one may > create modeless dialog windows with NULL parent. The problem is: under XFCE > 4.4.1 the main window is covered by the dialog windows, it cannot be brought to > front. > > This does not happen with this small program under XFCE 4.2.3, KDE, Windows XP > and other X window managers. And I have some software which is unusable because > of this behaviour. Well this is the desired behaviour, keep dialogs above the main window. I hardly see how this can be a problem unless you are misusing the concept of dialogs. What the point of using dialogs rather than regular top level windows then?
Created attachment 1286 error log BTW, the example doesn't build here, however I think I get the idea.
> Well this is the desired behaviour, keep dialogs above the main window. I > hardly see how this can be a problem unless you are misusing the concept of > dialogs. > > What the point of using dialogs rather than regular top level windows then? It's not my duty to define what a dialog window is. But IMHO it's neither the window manager's duty to decide which window should cover the other one. I'm just suggesting the following: let's give the freedom (back) to the programmer to decide which window should cover the other one. When a dialog has a parent, then it should cover it's parent, certainly. But when ANY WINDOW has no parent, IMHO covering the application's main window it's not a good idea. There could be some cases when the user wants to work with a MODELESS DIALOG independently of the main window. And he can't. These kind of restrictions usually could have heavy consequences. For example: AFAIK in GTK there is no way to create a MODAL dialog which is not application-wide, but window-wide. The GTK designers said: even if an application has multiple windows, for example someone is painting on 2 images at once, he cannot have 2 color picker dialogs open at once. Weird, huh?
(In reply to comment #13) > It's not my duty to define what a dialog window is. But IMHO it's neither the > window manager's duty to decide which window should cover the other one. Sorry, but this is exactly the role of the window manager, manage windows, including (obviously) the Z-order. > I'm just suggesting the following: let's give the freedom (back) to the > programmer to decide which window should cover the other one. When a dialog has > a parent, then it should cover it's parent, certainly. Of course, the programmer has the freedom to use toplevel windows. > But when ANY WINDOW has no parent, IMHO covering the application's main > window it's not a good idea. But again, what's the point of using a dialog in this case. Just use a plain toplevel window and you'll be safe. Using a dialog and expect it to behave like a toplevel, then use a toplevel. > There could be some cases when the user wants to work with a MODELESS DIALOG > independently of the main window. And he can't. I'm afraid you are being confused between semantics and behaviour. The program indicates that a window is a dialog, expecting a certain kind of behavior. But this is not the way it works. The program indicates that a window is a dialog (ie a window that has to be treated differently, because it's a basic window that is opened by a program to display information to the user and/or obtain information), then the window manager decides of the behavior to use for this kind of windows. > These kind of restrictions usually could have heavy consequences. For example: > AFAIK in GTK there is no way to create a MODAL dialog which is not > application-wide, but window-wide. The GTK designers said: even if an > application has multiple windows, for example someone is painting on 2 images > at once, he cannot have 2 color picker dialogs open at once. Weird, huh? I'm sorry I don't get the point here, it has nothing to do with window management, does it?
> I'm afraid you are being confused between semantics and behaviour. The program > indicates that a window is a dialog, expecting a certain kind of behavior. > > But this is not the way it works. The program indicates that a window is a > dialog (ie a window that has to be treated differently, because it's a basic > window that is opened by a program to display information to the user and/or > obtain information), then the window manager decides of the behavior to use for > this kind of windows. there are 2 possibilities: 1. You are right, I'm wrong: do make impossible to create any kind of dialog which does not cover the main window in xfce 4.4.1. But then the KDE is wrong too, Mac OSX, XFCE 4.2, windows XP, other systems and window managers too. Then nevermind, I didn't say anything, I'll continue to use my own patched xfce... 2. I'm right, you're wrong: you'll realize that sometimes creating a DIALOG which does not cover the main window could be important. When the "dialogness" of the window is already decided... you decide...
Well, what I can tell is that, yes, I'm right when I'm saying that it's up to the window manager to decide how to manage windows, and yes, you are wrong to assume any kind of behaviour from any window manager. But don't get me wrong, it's just a friendly advice, you should not assume any behaviour. For example, if you say "I want this window to behave like that, then I use the type dialog because it works like that with X, Y or Z", then this is wrong. If you say "This window is a dialog window because it's displaying or requesting information to/from the user", then this is right.