Motif Dialog Shells and the XmNtransientFor resource - Xwindows

This is a discussion on Motif Dialog Shells and the XmNtransientFor resource - Xwindows ; I work on a Motif app which has several modal and non-modal dialogs. In a recent tidy-up of the code, I got it to set the XmNtransientFor resource explicitly for all of the dialogs in an attempt to solve some ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Motif Dialog Shells and the XmNtransientFor resource

  1. Motif Dialog Shells and the XmNtransientFor resource

    I work on a Motif app which has several modal and non-modal dialogs. In a
    recent tidy-up of the code, I got it to set the XmNtransientFor resource
    explicitly for all of the dialogs in an attempt to solve some problems with
    window stacking order. It worked fine until my users tried it. It went
    wrong on their systems because I was sometimes setting the resource value
    to a widget whose X window is not a top level window (e.g., a
    FileSelectionBox rather than the dialog shell that contains it).

    This was easy enough to fix, but what puzzles me is why I didn't discover
    the problem: it looks like some window managers (or something?) compensate
    for the error: I run

    bernoulli/rda- testit -display localhost:0
    bernoulli/rda- xwininfo -children
    bernoulli/rda- xprop

    and (selecting the main window in my app for xwininfo and an open file
    dialogue for xprop), I get this:
    ....
    xwininfo: Window id: 0x400051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    ....
    WM_TRANSIENT_FOR(WINDOW): window id # 0x400052 <=============== WRONG!

    then:

    bernoulli/rda- testit -display tychonov:0

    and over on the system called tychonov, I run:

    tychonov/rda- xwininfo -children
    tychonov/rda- xprop

    and (selecting the same windows as before) I get this:

    ....
    xwininfo: Window id: 0x3800051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    ....
    WM_TRANSIENT_FOR(WINDOW): window id # 0x3800051 <=============== RIGHT!
    ....

    And on bernoulli the window manager will let the main window obscure the
    file dialog and on tychonov it won't. What's happening on tychonov?

    Regards,

    Rob.


  2. Re: Motif Dialog Shells and the XmNtransientFor resource


    "Rob Arthan" wrote in message
    news:e8la2n$ade$1$8302bc10@news.demon.co.uk...
    >I work on a Motif app which has several modal and non-modal dialogs. In a
    > recent tidy-up of the code, I got it to set the XmNtransientFor resource
    > explicitly for all of the dialogs in an attempt to solve some problems
    > with
    > window stacking order. It worked fine until my users tried it. It went
    > wrong on their systems because I was sometimes setting the resource value
    > to a widget whose X window is not a top level window (e.g., a
    > FileSelectionBox rather than the dialog shell that contains it).
    >
    > This was easy enough to fix, but what puzzles me is why I didn't discover
    > the problem: it looks like some window managers (or something?) compensate
    > for the error: I run
    >
    > bernoulli/rda- testit -display localhost:0
    > bernoulli/rda- xwininfo -children
    > bernoulli/rda- xprop
    >
    > and (selecting the main window in my app for xwininfo and an open file
    > dialogue for xprop), I get this:
    > ...
    > xwininfo: Window id: 0x400051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    > ...
    > WM_TRANSIENT_FOR(WINDOW): window id # 0x400052 <=============== WRONG!
    >
    > then:
    >
    > bernoulli/rda- testit -display tychonov:0
    >
    > and over on the system called tychonov, I run:
    >
    > tychonov/rda- xwininfo -children
    > tychonov/rda- xprop
    >
    > and (selecting the same windows as before) I get this:
    >
    > ...
    > xwininfo: Window id: 0x3800051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    > ...
    > WM_TRANSIENT_FOR(WINDOW): window id # 0x3800051 <=============== RIGHT!
    > ...
    >
    > And on bernoulli the window manager will let the main window obscure the
    > file dialog and on tychonov it won't. What's happening on tychonov?
    >
    > Regards,
    >
    > Rob.
    >

    Some window managers allow primary windows on top of child windows, some do
    not allow this, and some allow the user to choose whether it is allowed (for
    example, CDE).

    If the user sets up her WM to allow primary windows on top, there is not a
    whole lot you can do to guarantee the "proper" stacking order. You can use
    things like XRaiseWindow, but the user can override that by selecting which
    window to place on top. if you check for property changes and try to keep
    the order you think is preferable, you will just irritate the user.
    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Software Reuse Project



  3. Re: Motif Dialog Shells and the XmNtransientFor resource

    Fred Kleinschmidt wrote:

    >
    > "Rob Arthan" wrote in message
    > news:e8la2n$ade$1$8302bc10@news.demon.co.uk...
    >...
    >> ...
    >> xwininfo: Window id: 0x400051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >> ...
    >> WM_TRANSIENT_FOR(WINDOW): window id # 0x400052 <=============== WRONG!
    >>
    >> ...
    >> xwininfo: Window id: 0x3800051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >> ...
    >> WM_TRANSIENT_FOR(WINDOW): window id # 0x3800051 <=============== RIGHT!
    >> ...
    >>
    >> And on bernoulli the window manager will let the main window obscure the
    >> file dialog and on tychonov it won't. What's happening on tychonov?
    >>
    >> Regards,
    >>
    >> Rob.
    >>

    > Some window managers allow primary windows on top of child windows, some
    > do not allow this, and some allow the user to choose whether it is allowed
    > (for example, CDE).
    >
    > If the user sets up her WM to allow primary windows on top, there is not a
    > whole lot you can do to guarantee the "proper" stacking order. You can
    > use things like XRaiseWindow, but the user can override that by selecting
    > which window to place on top. if you check for property changes and try to
    > keep the order you think is preferable, you will just irritate the user.
    >...


    That doesn't answer my question. I am only concerned with setting the
    WM_TRANSIENT_FOR properties right in the first place so the window manager
    will understand what the relationships between my dialogues are. My code is
    doing nothing like what you suggest - it's just doing standard
    ICCCM-compliant stuff, with one small mistake (now fixed - but that's not
    the question).

    The question is how can the same application running on the same platform
    and (mistakenly) passing the widget id of a Motif FileSelectionBox to the
    XmNtransientFor resource result in the WM_TRANSIENT_FOR property being the
    FileSelectionBox window under one window manager and the window of the
    DialogShell that contains it under another. Is it ICCCM-compliant for the
    window manager to change this property? That seems very odd.

    Regards,

    Rob.



  4. Re: Motif Dialog Shells and the XmNtransientFor resource


    "Rob Arthan" wrote in message
    news:e8m1pg$8so$1$8300dec7@news.demon.co.uk...
    > Fred Kleinschmidt wrote:
    >
    >>
    >> "Rob Arthan" wrote in message
    >> news:e8la2n$ade$1$8302bc10@news.demon.co.uk...
    >>...
    >>> ...
    >>> xwininfo: Window id: 0x400051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >>> ...
    >>> WM_TRANSIENT_FOR(WINDOW): window id # 0x400052 <=============== WRONG!
    >>>
    >>> ...
    >>> xwininfo: Window id: 0x3800051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >>> ...
    >>> WM_TRANSIENT_FOR(WINDOW): window id # 0x3800051 <=============== RIGHT!
    >>> ...
    >>>
    >>> And on bernoulli the window manager will let the main window obscure the
    >>> file dialog and on tychonov it won't. What's happening on tychonov?
    >>>
    >>> Regards,
    >>>
    >>> Rob.
    >>>

    >> Some window managers allow primary windows on top of child windows, some
    >> do not allow this, and some allow the user to choose whether it is
    >> allowed
    >> (for example, CDE).
    >>
    >> If the user sets up her WM to allow primary windows on top, there is not
    >> a
    >> whole lot you can do to guarantee the "proper" stacking order. You can
    >> use things like XRaiseWindow, but the user can override that by selecting
    >> which window to place on top. if you check for property changes and try
    >> to
    >> keep the order you think is preferable, you will just irritate the user.
    >>...

    >
    > That doesn't answer my question. I am only concerned with setting the
    > WM_TRANSIENT_FOR properties right in the first place so the window manager
    > will understand what the relationships between my dialogues are. My code
    > is
    > doing nothing like what you suggest - it's just doing standard
    > ICCCM-compliant stuff, with one small mistake (now fixed - but that's not
    > the question).
    >
    > The question is how can the same application running on the same platform
    > and (mistakenly) passing the widget id of a Motif FileSelectionBox to the
    > XmNtransientFor resource result in the WM_TRANSIENT_FOR property being the
    > FileSelectionBox window under one window manager and the window of the
    > DialogShell that contains it under another. Is it ICCCM-compliant for the
    > window manager to change this property? That seems very odd.
    >
    > Regards,
    >
    > Rob.
    >

    I was just responding to your question:
    "And on bernoulli the window manager will let the main window obscure the
    file dialog and on tychonov it won't. What's happening on tychonov?"
    ---
    Fred



  5. Re: Motif Dialog Shells and the XmNtransientFor resource

    Fred Kleinschmidt wrote:

    >
    > "Rob Arthan" wrote in message
    > news:e8m1pg$8so$1$8300dec7@news.demon.co.uk...
    >> Fred Kleinschmidt wrote:
    >>
    >>>
    >>> "Rob Arthan" wrote in message
    >>> news:e8la2n$ade$1$8302bc10@news.demon.co.uk...
    >>>...
    >>>> ...
    >>>> xwininfo: Window id: 0x400051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >>>> ...
    >>>> WM_TRANSIENT_FOR(WINDOW): window id # 0x400052 <=============== WRONG!
    >>>>
    >>>> ...
    >>>> xwininfo: Window id: 0x3800051 "PPXpp-2.5.11.A: * NO FILE NAME *"
    >>>> ...
    >>>> WM_TRANSIENT_FOR(WINDOW): window id # 0x3800051 <=============== RIGHT!
    >>>> ...
    >>>>
    >>>> And on bernoulli the window manager will let the main window obscure
    >>>> the file dialog and on tychonov it won't. What's happening on tychonov?
    >>>>
    >>>> Regards,
    >>>>
    >>>> Rob.
    >>>>
    >>> Some window managers allow primary windows on top of child windows, some
    >>> do not allow this, and some allow the user to choose whether it is
    >>> allowed
    >>> (for example, CDE).
    >>>
    >>> If the user sets up her WM to allow primary windows on top, there is not
    >>> a
    >>> whole lot you can do to guarantee the "proper" stacking order. You can
    >>> use things like XRaiseWindow, but the user can override that by
    >>> selecting which window to place on top. if you check for property
    >>> changes and try to
    >>> keep the order you think is preferable, you will just irritate the user.
    >>>...

    >>
    >> That doesn't answer my question. I am only concerned with setting the
    >> WM_TRANSIENT_FOR properties right in the first place so the window
    >> manager will understand what the relationships between my dialogues are.
    >> My code is
    >> doing nothing like what you suggest - it's just doing standard
    >> ICCCM-compliant stuff, with one small mistake (now fixed - but that's not
    >> the question).
    >>
    >> The question is how can the same application running on the same platform
    >> and (mistakenly) passing the widget id of a Motif FileSelectionBox to the
    >> XmNtransientFor resource result in the WM_TRANSIENT_FOR property being
    >> the FileSelectionBox window under one window manager and the window of
    >> the DialogShell that contains it under another. Is it ICCCM-compliant for
    >> the window manager to change this property? That seems very odd.
    >>
    >> Regards,
    >>
    >> Rob.
    >>

    > I was just responding to your question:
    > "And on bernoulli the window manager will let the main window obscure
    > the
    > file dialog and on tychonov it won't. What's happening on tychonov?"


    Thanks, but unfortunately, your response is not the explanation. The window
    managers I am using on both systems honour the convention that a top level
    window W1 won't obscure another window W2, if W2 has its WM_TRANSIENT_FOR
    property set to the id W1. What I can't understand is that the window
    manager (or something?) seems to be correcting an inappropriate setting of
    this property (either that or the Motif library is doing something weird).

    Regards,

    Rob.




+ Reply to Thread