On Mon, Mar 15, 2004 at 03:58:53PM +0100, Jean-Marc Bourguet wrote:
> Dominik Vogt wrote:
> >On Tue, Mar 09, 2004 at 05:30:35PM +0100, Jean-Marc Bourguet wrote:
> >>I've an application wich tend to reopen transient windows while
> >>I've switched to another desktop. The transient window is opened
> >>on the desktop where it was previously mapped. With fvwm 2.4.2,
> >>I can switch or not to that desktop (with SkipMapping style), but
> >>I could not have it mapped to the current desktop (which would be
> >>the best choice for that application). Did I miss something? Is
> >>it possible in another fvwm version?
> >
> >
> >Currently, transients are always placed on the same desk as their
> >"parent" window.
> > Also, I think putting both on different desks
> > can be extremely confusing, for example if you have a modal
> > transient on one desk and wonder why you can't to anything with
> > the parent window because input is blocked while the transient
> > exists. All you can do is using pages instead of desks at the
> > moment.
>
> I've just checked. My program takes a long time before opening some
> forms, which are transient window according to FvwmIdent and the
> window opens on the current desk and not on the desk where the other
> windows of the process are openened. As a matter of fact, the behaviour
> given above (allways on the same desk as the parent) would also be an
> improvement on the current situation, where indeed I got blocked parent
> window because it remapped a transient on a desk where it was put two
> days before.
Fvwm does the following with transient windows:
Each time fvwm is interested in whether a window is a transient
window of another one (the "transientfor" window in X11 slang), it
checks whether
- the transientfor is set to None, the window itself, the EWMH
desktop window or any window created by fvwm to decorate
itself,
OR
- the transientfor window does not exist,
OR
- the transientfor window is one part of the window decoration,
OR
- the transientfor window is not managed by fvwm and itself or
one of its ancestors is not mapped,
OR
- there is a circular transience relationship between
the windows involved.
If any of these conditions is true, fvwm assumes the window is
transient for the root window, i.e. the window and the
transientfor lose their special relationship.
Now, when the window is mapped, and the (modified) transientfor is
a window managed by fvwm, the transient is mapped on the same desk
as the the transientfor. In any other case it is mapped on the
current desk (except when told otherwise with the StartsOn...
styles).
> After some more investigation with xprop, it seems that the transient
> windows are declared transient for a window which is not mapped.
In that case I can not understand why the window is not mapped on
the current desk. It should. Is there some StartsOnDesk style
for this window? Or the application uses the obnoxious EWMH or
GNOME hints to specify a desk where it wants to be mapped. Try
the styles
Style <window name> EWMHUseStateHints, GnomeIgnoreHints
> I obviously am not in the position to change the behaviour of the
> program.
> In that case I'd like very much to change the desk to which
> they are mapped to the current one (but the behaviour you state: the
> desk of what I considered the parent is also a good choice, I just don't
> know if you can detect which it is).
See above explanation. If the window is unmapped, fvwm forgets
that the window was transient for the transientfor.
Ciao
Dominik ^_^ ^_^
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Mon Mar 15 2004 - 10:20:02 GMT