discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backend <-> GUI Library Interaction


From: Christopher Armstrong
Subject: Re: Backend <-> GUI Library Interaction
Date: Tue, 07 Nov 2006 19:49:16 +1100
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]