Wed 10 Dec 2008 08:37:04 PM UTC, comment #11:
Closed as the behaviour turned out to be a debugging artefact.
|
Wed 10 Dec 2008 07:15:32 PM UTC, comment #10:
I just discovered that this problem goes away when I run my application directly. It seems to only be an issue when I am running through gdb. Sorry it took so long to figure this out -- since I'm at a development stage where there are many issues, I've been consistently running in gdb (on Win XP) so I didn't notice this until now.
|
Thu 27 Nov 2008 11:40:38 PM UTC, comment #9:
hmmm... DO yo uhave the same problem under X11 under unix too? Maybe it is not windows specific.
|
Mon 24 Nov 2008 09:59:13 PM UTC, comment #8:
I'm going to try to test this with a nib file to see if that's the issue. There may be some initialization issues with regarding window level.
|
Fri 21 Nov 2008 07:46:58 AM UTC, comment #7:
orderwindow::: is at the buttom of all the methods you mention. But what you are asking for is not window ordering based on any calls from GNUstep, it is window ordering in responce to operation system activity. This gets done in [WIN32Server decodeWM_ACTIVEParams:::], or rather it doesn't.
Most likely what you are looking for is even less than that. What is missing in GNUstep is to tell the window system which windows are directly related (popups, modal dialogs) so that the ordering of these windows could be handled by the window system automatically. This is different from full window ordering and really should be implemented in GNUstep.
|
Fri 21 Nov 2008 12:53:59 AM UTC, comment #6:
Hmm... well, orderwindow::: gets called when I open or close a window, but not when I click on overlapping windows. Neither does [NSWindow makeKeyAndOrderFront:] or orderWindow:relativeTo: or anything of the sort. When I click a non-key window it becomes key and gets moved behind all of the other windows, but I can't seem to find any method to break on to see what's happening in that case.
Any thoughts?
|
Thu 20 Nov 2008 10:37:51 PM UTC, comment #5:
The method to look at is [WIN32Server orderwindow:::] here we try to transform the GNUstep window level into something usefull on Windows.
|
Thu 20 Nov 2008 09:58:53 PM UTC, comment #4:
Unfortunately I don't have an example app that I can share. I'll be happy to try debugging this here though, if you can suggest a method where I might set a breakpoint to see what's happening.
|
Thu 20 Nov 2008 08:05:28 PM UTC, comment #3:
Possible. Do you have an example app that shows the problem?
|
Thu 20 Nov 2008 07:47:00 PM UTC, comment #2:
I checked out the latest updates from svn. I don't believe I have any defaults set that should have any impact. A couple of other pieces of information that might be helpful: If I run Gorm, its windows seem to be ordered normally. All of my application's interface files are Cocoa nibs -- I wonder if that could have anything to do with it.
|
Wed 19 Nov 2008 11:57:01 PM UTC, comment #1:
I don't get this behavior with either the latest Windows intaller (0.20.3) or with gnustep from svn (actually the stable branch, but that should be similar enough to the main trunk). What version are you using? Do you have any unusual defaults set (what does "defaults read" say?)?
|
Tue 18 Nov 2008 05:45:56 PM UTC, original submission:
Clicking on a window will make it key (black title bar) but send it BEHIND other windows (to the BACK of the window ordering, rather than the FRONT). It appears that the window ordering is completely reversed, as a modal panel (Open Panel in this case) is staying behind all of the other windows.
|