User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20070208 Mandriva/2.0.0.1-8mdv2007.1 (2007.1) Firefox/2.0.0.1 Build Identifier: when using SWT based applications, on can for example detach certain parts of the application as seperate windows. When doing this for example with eclipse or azureus, the detached windows cannot be moved to another workspace, the "send to" menu entry in the context menu is grayed out. Reproducible: Always
This is because these windows have a "transient" relationship. xfwm4 keeps transients with their parent window, therefore they cannot be moved to different workspace independently. Please note that xfwm4 also supports the notion of transient for group [1] which seems to be widely used by SWT applications. This is a design decision, not a bug. [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2512420
Hmm, ok then, but I don't know any other WM that behaves like xfce here (gnome, kde, blackbox & derivates, windowmaker to name but a few). And to be honest, I don't see the advantage of such an implementation (at least from my users POV). At least some configuration setting should be there to allow "detaching" transient windows from their parents. But anyhow, I am marking this as an "enhancement" now.
Well, I'd have to reject this. I don't see why (In reply to comment #2) > Hmm, ok then, but I don't know any other WM that behaves like xfce here (gnome, > kde, blackbox & derivates, windowmaker to name but a few). Frankly, very few implements the transient for group, and even less do it properly. > And to be honest, I don't see the advantage of such an implementation (at least > from my users POV). At least some configuration setting should be there to > allow "detaching" transient windows from their parents. Well, maybe SWT is not using the transient relationship properly, so you don't see the advantage of the current implementation. Doesn't mean that the window manager is misbehaving. Just a very simple example, using SWT, run Eclipse, open its preference window. As you can see, this a modal dialog, so the parent window (the Eclipse workbench) is frozen, unresponsive to user actions. Now, imagine you could move the preference window on another workspace independently, then the parent window would "look" frozen for no reason. > But anyhow, I am marking this as an "enhancement" now. I'm afraid I have to disagree. I don't see degrading the window manager for one specific (mis)use of a standard property would be an enhancement.
Just tried kwin and it behaves just like xfwm4. The option is visible in the menu, but sending the window to another workspace has no effect, it stays on the same workspace as the parent window.
BTW, it would be great if you could provide a sample program, so I'd be able to confirm the transient relationship between windows.
Hehe, I see you want some real reasons :-) First, I am certainly not talking about breaking modal/non modal behaviour. The best example I have in hand is the eclipse console. I don't know, how familiar you are with eclipse, but the console essentially is something like a better "stdout", allowing to view eg. the state/behaviour of various eclipse plugins or (self) developed applications. Now one of the nice things is that you can do is to "detatch" the mentioned console, allowing to have it maximized as a seperate window, ideally (at least IMO) on a different workspace, so that a switch between the eclipse "main" window (or a developed application) and the console becomes very easy. And the console is certainly non modal. And as you mentioned kwin, you can for example successfully send the detached console to another workspace using kwin.
Ok, I checked with eclipse and the so called "detached" windows are really transients (confirmed with xprop) Indeed, kwin does allow transient to reside on separate desktops and I see this as a bug in kwin To give you a real life example, I opened the search dialog in my favorite text editor and moved that to another workspace. Now, whenever I try to open that search window again, nothing happens, because the window is already opened and resides on another workspace. Therefore, I consider the current behavior of xfwm4 to be correct and the desired one. Removing this feature would introduce bugs and misbehavior in many applications.
So be it, I can't argue with you about that, after all it is _your_ window manager. All others I have checked now (fvwm1, fvwm2, WindowMaker, blackbox, fluxbox, kwin, metacity, sawfish, compiz, beryl) allow these kinds of movements. So from what you claim, all of them must be buggy then ... but well, why not. Quite strange, IMHO.
(In reply to comment #8) > All others I have checked now (fvwm1, fvwm2, WindowMaker, blackbox, fluxbox, > kwin, metacity, sawfish, compiz, beryl) allow these kinds of movements. Nope, metacity doesn't allow it either (tested with version 2.16.3) and always keeps transients with their parents. Don't know or care much about the others.
Hmm, the metacity version I am using (2.17.5) allows detached windows on different worspaces. Using xprop I get this for the eclipse main window when running metacity: --------CUT--------- % xprop [...] _NET_WM_ICON_GEOMETRY(CARDINAL) = 11, 1000, 182, 24 _NET_WM_STATE(ATOM) = WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_FRAME_EXTENTS(CARDINAL) = 3, 3, 25, 3 _NET_WM_DESKTOP(CARDINAL) = 0 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1a007a8 bitmap id # of mask for icon: 0x1a007aa window id # of group leader: 0x1a00001 [...] WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "Eclipse", "Eclipse" [...] --------CUT--------- as you can see, the main window is on desktop#0. For the detached console I get this: --------CUT--------- % xprop WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_FRAME_EXTENTS(CARDINAL) = 3, 3, 25, 3 _NET_WM_DESKTOP(CARDINAL) = 1 _NET_WM_STATE(ATOM) = _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x1a007a8 bitmap id # of mask for icon: 0x1a007aa window id # of group leader: 0x1a00001 [...] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG WM_TRANSIENT_FOR(WINDOW): window id # 0x1a00792 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 27265836 _NET_WM_USER_TIME(CARDINAL) = 2438644 WM_CLIENT_LEADER(WINDOW): window id # 0x1a00001 [...] WM_CLASS(STRING) = "Eclipse", "Eclipse" [...] --------CUT--------- so as you see, the console is on desktop#1.
No worry, I believe you ;) Although beta release don't really count as much as stable ones :P But again, I'm convinced that the current implementation is the correct one, and the best suited for most applications. Sure, there are some cases or applications where it would be handy to have a different behavior, but then it would better to change the application rather than changing the behavior of the window manager, that would affect all applications for one specific need. The definition on Transient windows in ICCCM gives: "The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of another top-level window. The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction. Dialogue boxes, for example, are an example of windows that should have WM_TRANSIENT_FOR set." I therefore believe that transients should be kept with their parents and placed above them in stacking order. I think this is very helpful with most applications and a lot of code/checks/tests have been put into this feature...