Richard Frith-Macdonald wrote:
On 7 Nov 2006, at 08:11, Christopher Armstrong wrote:
Hi
Richard Frith-Macdonald wrote:
That's interesting, I thought the only way a window could change
window
levels was by the setwindowlevel: message.
I thought the same until I checked. The documentation suggested
that behavior but was not completely explicit, so I looked at the X
backend code to confirm it.
The other interpretation (that ordering of windows relative to each
other only worked for windows in the same level) seems a bit more
intuitive to me.
It actually might be worth checking what MacOS-X actually does, and
consider changing the GNUstep behavior if it does it the other way.
There seems to be a little debate about this one (re: message from
Sheldon Gill). I'll have to dig a bit deeper on this, but I think the
MacOSX notes are ambigious too (IIRC).
Well, in answering your question about the gui/backend interaction in
GNUstep, Sheldon has just said how he thinks it *should* behave rather
than how it *does* behave. If you want to 'fix' the windows backend
to work better with the gui now, you need to implement the actual
behavior rather than a potential future behavior.
However, his idea of how it should behave is perfectly reasonable ...
and I would probably support moving to it if (and only if) it's the
way MacOS-X behaves ... once we have checked what the impact/breakage
of changing behavior would be and if we got consensus/majority in
favour of changing. Perhaps very few apps actually depend upon the
existing behavior and changing would be pretty painless.
I did a quick check against the old orderwindow operator for OpenStep
(the docs for www.toodarkpark.org). Whilst not explicit, it does say
that when orderwindow is called to order a window relative to another
one, that this operation should be followed. Implicitly, the window
level would change when it is called in this matter. It would not change
when the user simply switches to it.
MacOS X seems to concur in the same ambiguous fashion. A window that is
ordered relative to another (via NSWindow's -orderWindow:relativeTo:),
it seems to imply (it doesn't say) that the window should be moved
immediately above/below this window. It also mentions the relative
window number being zero, in which case it moves the window to the
top/bottom of that window level. The -orderFront:/-orderBack: methods
explicitly mention the window level i.e. they order to the front or back
of that window level. Therefore, I think the compatible or "correct"
behaviour is being observed. I'm not sure about what should happen when
an application is inactive though. An interesting snippet from the
NSWindow docs is that a window is brought to the top of its window level
when its window level is changed using -setLevel:.
And damn, I've been forwarding the messages to the wrong mailing list.
Oh well, I'll CC to both now.
Thanks for your help on this; with a little effort I think it may be
possible to emulate this window level stuff on Windows. I just hope
there isn't too many race conditions and I'm not sure what I'll do about
other application's windows.
Cheers
Chris
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
