"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

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.

"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

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.