Fri 29 Sep 2006 11:11:44 AM UTC, comment #49:
I beleieve this is fixed now.
|
Wed 27 Sep 2006 07:13:24 AM UTC, comment #48:
> By the way, the quick tests on the window offset is a little bit annoying.
> Is it necessary after the support of _NET_FRAME_EXTENTS ?
Well, as you know _NET_FRAME_EXTENTS does not work for WindowMaker (and probably other comon window managers too), but even if it did, it does not change things at all ... you still have to create a test window in each style to check the value returned by _NET_FRAME_EXTENTS for that style of window.
Currently the information is cached in the window server, so it only hapens once after each restart of the window server. I suppose we could store it in the user defaults system for a longer lifetime.
Probably we should be storing window manager specific information anyway, in case the window manager changes.
|
Wed 27 Sep 2006 06:40:03 AM UTC, comment #47:
O.K. it works fine now after some quick tests.
Thanx a lot !!
I think GNUstep should only focus on EWMH window manager (including KDE and GNOME) and WindowMaker.
Otherwise, there are too much trouble to keep compatible with so many window managers.
That's why there is a EWMH protocol. :)
By the way, the quick tests on the window offset is a little bit annoying.
Is it necessary after the support of _NET_FRAME_EXTENTS ?
I am fine with that, but I guess some people may not be.
Yen-Ju
|
Wed 27 Sep 2006 06:18:30 AM UTC, comment #46:
> But I wonder why we cannot use _NET_FRAME_EXTENTS to retrieve the offset ?
Good point ... mostly because many window managers (including WindowMaker) do not support _NET_FRAME_EXTENTS.
However, I have modified the code to use _NET_FRAME_EXTENTS where the window manager does support it, since this should be more efficient than traversing the window hierarchy in reswponse to a reparent notify.
|
Wed 27 Sep 2006 05:23:05 AM UTC, comment #45:
O.K. I will try that tomorrow.
But I wonder why we cannot use _NET_FRAME_EXTENTS to retrieve the offset ?
If I never take a look of the source code,
I will have no idea that metacity need GSDoubleParentWindows user default.
Here is the document about _NET_FRAME_EXTENTS:
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2523626
It MUST be set by window manager. Therefore, it should be available all the time.
|
Wed 27 Sep 2006 05:12:57 AM UTC, comment #44:
> Root Window
> +- Window (the one with decoration)
> +- Plate (the part excludes decoration)
> +- GNUstep window (the same size and position of plate)
>
> Therefore, in ReparentNotify,
> we cannot simply based on the xEvent.xreparent.x and xEvent.xreparent.y.
Did you try using the GSDoubleParentWindows user default?
As far as I can see, this was added precisely for the sort of case you are describing..
|
Wed 27 Sep 2006 04:36:54 AM UTC, comment #43:
WindowMaker works fine, but not Metacity.
Here is how metacity reparents GNUstep window:
Root Window
+- Window (the one with decoration)
+- Plate (the part excludes decoration)
+- GNUstep window (the same size and position of plate)
Therefore, in ReparentNotify,
we cannot simply based on the xEvent.xreparent.x and xEvent.xreparent.y.
In case of metacity, the xreparent.x and y are zero all the time,
and the mouse is off by the hight of title.
|
Tue 26 Sep 2006 10:24:44 AM UTC, comment #42:
I added a load of debug and fixed a small bug in _checkStyle:
Running with --GNU-Debug=Offset should be able to give quite a bit of diagnostic info now.
|
Tue 26 Sep 2006 08:09:40 AM UTC, comment #41:
> Failed to determine offsets for style 1
> ... (same information from 2 - 14 and an window flicks)
> Failed to determine offsets for style 15
That's good news ... it means that your X server/windowmanager is failing to send the ReparentNotify events to tell us when it has reparented/decorated the window, or we are failing to read them for some reason.
All you need to do is find out why we are not getting the information ... and the code to look at is quite small, so you can add debug to trrack it down.
You can try getting some debug output using --GNU-Debug=Offset, but if that doesn't help (and it probably won't), you need to look in XGServerWindow.m at the _checkStyle: method.
This method creates a new window and orders it in (ie makes it visible).
It then does an XSync() to wait for all resulting events from X.
If then pulls events off the queue, looking for the ReparentNotify events (which tell us the offset from the parent (decorations) window to our window.
|
Tue 26 Sep 2006 07:11:12 AM UTC, comment #40:
Unfortunately, the bug with open panel is not fixed.
Here is the information I got:
Failed to determine offsets for style 1
... (same information from 2 - 14 and an window flicks)
Failed to determine offsets for style 15
styleoffsets ... guessing offsets
... (13 times totally)
Again, it all goes down to the buffer is smaller than expose rectangle (window->xframe).
That's why it generates a X window error.
|
Tue 26 Sep 2006 05:58:13 AM UTC, comment #39:
> Anyway, for the moment, the GWorkspace issues seem fixed. But now it seems that > there are some problems with the cursor not beeing reset to the arrow cursor in
> some situations. I'll try to find a way to reproduce this.
Can we confirm that the original bug with the open panels is fixed?
If it is, I'd like to close this bug and, if necessary, open new bugs for remaining (but different) issues.
1. shared memory buffer getting out of sync and causing X errors
2. cursor arrow resetting problems.
I'm not sure that either of these is related to the new coordinate mapping ... though I guess they easily could be.
|
Mon 25 Sep 2006 04:44:07 PM UTC, comment #38:
> With the suspicion that there may be two different issues (one with shared
> memory buffer management, one with coordinate mapping), I've tried to solve
> some possible problems in the latter by changing the code to determine all
> style offsets before they are used and to have the code stick to using those
> offsets when told something that appears contradictory by the X system (and
> log the discrepency). This involves briefly creating/destroying a series of
> test windows the first time a GNUstep application is started up using an X
> server which has not already had a GNUstep application running. It's abit
> ugly, but I can't think of any way to avoid it.
I don't think that it's ugly, it seems to me a very good idea.
Anyway, for the moment, the GWorkspace issues seem fixed. But now it seems that there are some problems with the cursor not beeing reset to the arrow cursor in some situations. I'll try to find a way to reproduce this.
|
Mon 25 Sep 2006 01:59:16 PM UTC, comment #37:
With the suspicion that there may be two different issues (one with shared memory buffer management, one with coordinate mapping), I've tried to solve some possible problems in the latter by changing the code to determine all style offsets before they are used and to have the code stick to using those offsets when told something that appears contradictory by the X system (and log the discrepency). This involves briefly creating/destroying a series of test windows the first time a GNUstep application is started up using an X server which has not already had a GNUstep application running. It's abit ugly, but I can't think of any way to avoid it.
|
Mon 25 Sep 2006 10:17:37 AM UTC, comment #36:
> ...
> I'm wondering if this might all be some problem with the shared memory image
> buffering getting out of sync somehow.
> Q. Does the GWorkspace issue persist if you set XWindowBufferUseXShm 0?
> Can you reproduce it with the xlib backend?
> ...
Setting XWindowBufferUseXShm to 0 or/and using the xlib backend doesn't change anything.
I'd want also to remember that one of the affected window is the Inspector window that is neither exposed nor resized when the problem appears.
|
Mon 25 Sep 2006 08:24:54 AM UTC, comment #35:
Responding to Yen-Ju Chen's three posts in one ...
> I think the size of XWindowBuffer is never updated even with the latest
> backend.
Probably ... we need to figure out why not though.
> I don't see the +windowBufferForWindow:depthInfo: is called
> when new expose event occurs. Maybe that's the bug.
I think that +windowBufferForWindow:depthInfo: should be called whenever the window is resized (and only when the window is resized). The idea of making sure that expose events were processed in the event stream passed to the GUI was that this should mean that resize and expose events were handled in order ... so that the buffer would have been resized to the new size before we process an expose event for the new size.
> And I realize that window->xframe does change for no reason.
Something must change it ... I will look through the code and try to identify all places where it can be changed and add debug to log all changes.
> So the solution would be to resize the buffer for every exposure
> if the buffer is retained.
This would not be good ... it would mean that we lose buffer contents on each exposure ... in which case we may as well not have a buffer at all since every expose event would have to trigger a redraw of the exposed region.
Talking about decoration of windows ...
> Therefore, you probably cannot expect the window size will stay the same
> during the order out and order front. But most of time, they will.
I think you are mistaken here ... changes in decoration should not effect the size of the window we are drawing into, just the offsets from its parent to it. Thus the size of the wdrawign window and the buffer area should not be effected by any decoration changes.
However, I certainly that the area of calculation of offsets is one we need to be very careful about, since if we pick different sets of information from the window manager at different times we could potentially map from X to OS coordinates using one set of offset info, and map back again later using a different set of info resulting iun incorrect coordinates.
|
Mon 25 Sep 2006 07:10:58 AM UTC, comment #34:
I haven't been able to work out as much as I hoped from the trace of GWorkspace events ... One section looked quite interesting, but after going through it carefully I concluded that it was doing just what we might expect when the finder window was resized. I guess we need to figure out more detailed debug about what is happening in the gui and buffering in response to the events.
I'm wondering if this might all be some problem with the shared memory image buffering getting out of sync somehow.
Q. Does the GWorkspace issue persist if you set XWindowBufferUseXShm 0?
Can you reproduce it with the xlib backend?
Unless the answers to the above are NO, coordinate mapping generally is still the prime suspect, and I think that adding a lot of debug to any chages to size and offset information should help us.
|
Sun 24 Sep 2006 11:11:11 PM UTC, comment #33:
I check the implementation of some window managers about close and map window.
When GNUstep ask to orderOut an window, it sends out a unmap notify via XWithdrawWindow().
Every window manager will remove the decoration and reposition the window.
That's where each window manager differs.
And it probably explain why the size change.
For example, if you open an inspector in WindowMakaer (right-click on title bar, then choose "Attribute..."),
and try to disable various window decoration.
You will notice that if you remove the border,
WindowMaker will try to move the window so that the top-left corner stay the same.
But if you try to remove the titlebar, it won't reposition the window.
So the title bar disappear and the rest of window stay where they are.
But in Azalea, if you remove the decoration by righ-click on the icon on the title bar,
it will reposition the window so that the left corner stay the same.
Therefore, you probably cannot expect the window size will stay the same during the order out and order front. But most of time, they will.
|
Sun 24 Sep 2006 10:30:51 PM UTC, comment #32:
I dump these information in -orderwindow:: (XGServerWindow.m):
NSLog(@"orderWindow:otherwin:");
NSLog(@"xframe %@", NSStringFromRect(window->xframe));
NSLog(@"buffer %dx%d", window->buffer_width, window->buffer_height);
NSLog(@"XSizeHints (%dx%d)", window->siz_hints.width, window->siz_hints.height);
And I realize that window->xframe does change for no reason.
When window->xframe is bigger than window->buffer_width*window->buffer_height,
the problem occurs.
And luckly in metacity, window->xframe is actually 2 pixels
less than window->buffer_widht*window->buffer_height during the exposure.
Therefore, this problem never happens to metacity.
So the solution would be to resize the buffer for every exposure
if the buffer is retained.
|
Sun 24 Sep 2006 07:55:17 PM UTC, comment #31:
I think the size of XWindowBuffer is never updated even with the latest backend.
Here is a short track:
1. 2006-09-24 12:42:07.330 Ink[2963] rect {x = 1; y = 6; width = 390; height = 426}, rectangle (0, 0, 390, 426)
A new Expose event goes into XGServerEvent (the new patch).
rect = [self _XWindowRectToOSWinRect:...];
Both the rect and rectangle has the right size, 390x426.
2. 2006-09-24 12:42:07.377 Ink[2963] -_exposeRect: (sx, sy) = (384, 426), rect = {x = 0; y = 0; width = 390; height = 426}
2006-09-24 12:42:07.378 Ink[2963] sx 384, sy 426, x 0, y 0, w 390, h 426
-exposeRect: in XWindowBuffer is called with NSRect (390x426).
But the sx, sy are still 384x426, which is the size when it is created in -windowBufferForWindow:depthInfo:
3. 2006-09-24 12:42:07.383 Ink[2963] X-Windows error - BadValue (integer parameter out of range for operation)
on display: :0.0
type: 0
serial number: 2365
request code: 143
Error occurs when XShmPutImage() is called.
I don't see the +windowBufferForWindow:depthInfo: is called
when new expose event occurs. Maybe that's the bug.
PS. Now, it works with XWindowBufferUseXShm 0.
PPS. It is not associated with left-mouse down.
|
Sun 24 Sep 2006 07:06:26 PM UTC, comment #30:
Now, I can say it is associated with the left-mouse down
in the open panel.
Still cannot find the bug yet.
|
Sun 24 Sep 2006 07:01:30 PM UTC, comment #29:
After the last changes in -back I can send a simpier trace:
window 52 is the file viewer window
window 26 is the finder window
in the Defaults the finder window is "567 221 486 388 0 0 1600 1176 "
8388848 EnterNotify
- KeymapNotify
8388848 ButtonPress: xEvent.xbutton.time 3777917674 timeOfLastClick 3777905149
Send NSEvent type: 0 to window 52
8388848 FocusIn
- KeymapNotify
8388848 ClientMessage
WM Protocol - WM_TAKE_FOCUS
8388613 UnmapNotify
8388613 ReparentNotify - offset 0 0
8388613 MapNotify
8388613 VisibilityNotify 2
8388975 ConfigureNotify x:0 y:0 w:1600 h:24 b:0 F
8388975 ReparentNotify - offset 0 0
8388975 ConfigureNotify x:0 y:0 w:1600 h:24 b:0 T
Send NSEvent type: 19 to window 52
8388975 MapNotify
8388975 VisibilityNotify 0
8388975 Expose
Expose frame 0 0 1600 24
8388975 ClientMessage
WM Protocol - WM_TAKE_FOCUS
8388848 VisibilityNotify 0
8388848 Expose
Expose frame 169 0 279 282
Send NSEvent type: 15 to window 85
Send NSEvent type: 15 to window 52
"GWorkspace" appDidBecomeActive
8388848 ButtonRelease
Send NSEvent type: 1 to window 52
8388848 KeyPress
Send NSEvent type: 14 to window 52
8388848 KeyPress
send key down event
8388848 KeyRelease
8388740 ConfigureNotify x:774 y:767 w:484 h:262 b:0 F
8388740 ReparentNotify - offset 0 24
8388740 ConfigureNotify x:775 y:792 w:484 h:262 b:0 T
8388740 ConfigureNotify x:0 y:24 w:484 h:262 b:0 F
8388740 MapNotify
8388740 VisibilityNotify 0
8388740 Expose
Expose frame 0 0 484 262
8388740 ClientMessage
WM Protocol - WM_TAKE_FOCUS
8388848 FocusOut
8388740 FocusIn
- KeymapNotify
8388740 ConfigureNotify x:0 y:24 w:484 h:312 b:0 F
8388740 VisibilityNotify 1
8388740 Expose
Expose frame 0 0 484 262
8388740 VisibilityNotify 0
8388740 Expose
Expose frame 0 262 484 50
8388641 Expose
Expose frame 1259 1002 1 15
Send NSEvent type: 15 to window 26
send key up event
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 5
8388740 KeyRelease
Send NSEvent type: 14 to window 26
8388848 ButtonPress: xEvent.xbutton.time 3777926022 timeOfLastClick 3777917674
Send NSEvent type: 0 to window 52
8388740 FocusOut
8388848 FocusIn
- KeymapNotify
8388848 ClientMessage
WM Protocol - WM_TAKE_FOCUS
8388848 ButtonRelease
Send NSEvent type: 19 to window 52
Send NSEvent type: 1 to window 52
|
Sun 24 Sep 2006 05:41:02 PM UTC, comment #28:
The problem is still there, but I haven't been able to track it down yet. Need more time.
But if I set XWindowBufferUseXShm 0 in NSGlobalDomain,
the submenus and windows need a second click to draw.
Otherwise, it is just a blank window.
I think there is something to do with the news expose event.
|
Sun 24 Sep 2006 04:58:01 PM UTC, comment #27:
We have been lucky because, this time, the finder window was messed from the beginning, without needing of adding or removing search options. The trace is simplier.
window 52 is the file viewer window
window 26 is the finder window
in the Defaults the finder window is "567 221 486 388 0 0 1600 1176 "
- click on a file viewer window
75497712 ButtonPress: xEvent.xbutton.time 3768923451 timeOfLastClick 3768914267
Send NSEvent type: 0 to window 52
75497712 PropertyNotify - 'WM_NORMAL_HINTS'
75497712 PropertyNotify - 'WM_HINTS'
75497712 PropertyNotify - 'WM_PROTOCOLS'
75497744 FocusOut
75497712 FocusIn
- KeymapNotify
75497712 VisibilityNotify 0
75497712 Expose
Expose frame 168 0 280 282
75497712 ClientMessage
WM Protocol - WM_TAKE_FOCUS
Send NSEvent type: 19 to window 52
Send NSEvent type: 15 to window 52
75497712 ButtonRelease
Send NSEvent type: 1 to window 52
- keyDown on the same window
75497712 KeyPress
Send NSEvent type: 14 to window 52
- command-f to open the finder window
71303408 KeyPress
send key down event
71303634 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303634 PropertyNotify - 'WM_PROTOCOLS'
71303634 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303634 PropertyNotify - '_NET_WM_WINDOW_TYPE'
71303634 PropertyNotify - 'WM_NORMAL_HINTS'
71303634 PropertyNotify - 'WM_NORMAL_HINTS'
71303634 PropertyNotify - 'WM_NAME'
71303634 PropertyNotify - 'WM_ICON_NAME'
71303634 PropertyNotify - '_NET_WM_NAME'
71303634 PropertyNotify - '_NET_WM_ICON_NAME'
71303634 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303637 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303637 PropertyNotify - 'WM_PROTOCOLS'
71303637 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303637 PropertyNotify - '_NET_WM_WINDOW_TYPE'
71303637 PropertyNotify - 'WM_NORMAL_HINTS'
71303637 PropertyNotify - 'WM_NORMAL_HINTS'
71303637 PropertyNotify - 'WM_NAME'
71303637 PropertyNotify - 'WM_ICON_NAME'
71303637 PropertyNotify - '_NET_WM_NAME'
71303637 PropertyNotify - '_NET_WM_ICON_NAME'
71303637 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303640 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303640 PropertyNotify - 'WM_PROTOCOLS'
71303640 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303640 PropertyNotify - '_NET_WM_WINDOW_TYPE'
71303640 PropertyNotify - 'WM_NORMAL_HINTS'
71303640 PropertyNotify - 'WM_NORMAL_HINTS'
71303640 PropertyNotify - 'WM_NAME'
71303640 PropertyNotify - 'WM_ICON_NAME'
71303640 PropertyNotify - '_NET_WM_NAME'
71303640 PropertyNotify - '_NET_WM_ICON_NAME'
71303640 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303643 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303643 PropertyNotify - 'WM_PROTOCOLS'
71303643 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303643 PropertyNotify - '_NET_WM_WINDOW_TYPE'
71303643 PropertyNotify - 'WM_NORMAL_HINTS'
71303643 PropertyNotify - 'WM_NORMAL_HINTS'
71303643 PropertyNotify - 'WM_NAME'
71303643 PropertyNotify - 'WM_ICON_NAME'
71303643 PropertyNotify - '_NET_WM_NAME'
71303643 PropertyNotify - '_NET_WM_ICON_NAME'
71303643 PropertyNotify - '_GNUSTEP_WM_ATTR'
71303300 PropertyNotify - 'WM_NORMAL_HINTS'
71303300 PropertyNotify - 'WM_HINTS'
71303300 PropertyNotify - 'WM_PROTOCOLS'
71303300 PropertyNotify - 'WM_NORMAL_HINTS'
71303300 ConfigureNotify x:567 y:686 w:484 h:262 b:0 F
71303300 PropertyNotify - 'WM_NORMAL_HINTS'
71303300 ReparentNotify - offset 0 24
71303300 ConfigureNotify x:568 y:711 w:484 h:262 b:0 T
71303300 ConfigureNotify x:0 y:24 w:484 h:262 b:0 F
71303300 PropertyNotify - 'WM_STATE'
71303408 VisibilityNotify 1
71303300 MapNotify
71303300 VisibilityNotify 0
71303300 Expose
Expose frame 0 0 484 262
71303300 ClientMessage
WM Protocol - WM_TAKE_FOCUS
71303300 PropertyNotify - '_NET_WM_DESKTOP'
71303300 PropertyNotify - '_NET_WM_STATE'
71303300 PropertyNotify - 'WM_STATE'
71303408 FocusOut
71303300 FocusIn
- KeymapNotify
71303300 PropertyNotify - 'WM_NORMAL_HINTS'
71303300 ConfigureNotify x:0 y:24 w:484 h:312 b:0 F
71303300 VisibilityNotify 1
71303300 Expose
Expose frame 0 0 484 262
71303300 VisibilityNotify 0
71303440 VisibilityNotify 1
71303300 Expose
Expose frame 0 262 484 50
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
Send NSEvent type: 15 to window 26
71303300 KeyRelease
send key up event
71303300 KeyRelease
Send NSEvent type: 14 to window 26
- click on the same file viewer window
71303408 ButtonPress: xEvent.xbutton.time 3769548416 timeOfLastClick 3769545024
Send NSEvent type: 0 to window 52
71303408 PropertyNotify - 'WM_NORMAL_HINTS'
71303408 PropertyNotify - 'WM_HINTS'
71303408 PropertyNotify - 'WM_PROTOCOLS'
71303300 FocusOut
71303408 FocusIn
- KeymapNotify
71303408 VisibilityNotify 0
71303300 VisibilityNotify 1
71303408 Expose
Expose frame 255 243 193 39
71303408 ClientMessage
WM Protocol - WM_TAKE_FOCUS
Send NSEvent type: 19 to window 52
Send NSEvent type: 15 to window 52
71303408 ButtonRelease
Send NSEvent type: 1 to window 52
- click on an icon of this window. At this point the Inspector window is probably already broken but this becomes visible only now, selecting the icon, because the new selection causes a bad redraw in some places of the inspector.
71303408 ButtonPress: xEvent.xbutton.time 3769680910 timeOfLastClick 3769674802
Send NSEvent type: 0 to window 52
71303498 PropertyNotify - 'WM_NAME'
71303498 PropertyNotify - 'WM_ICON_NAME'
71303498 PropertyNotify - '_NET_WM_NAME'
71303498 PropertyNotify - '_NET_WM_ICON_NAME'
71303408 ButtonRelease
Send NSEvent type: 1 to window 52
|
Sun 24 Sep 2006 03:33:45 PM UTC, comment #26:
> add and remove search
> options till when the "Search" button disappears and all the
> subviews are drawn in the wrong place
This never happens for me ... it all just works fine.
However. it does give a clue ... since, when I tried it, I noticed that adding or removing search options causes the window to be resized.
Possibly something odd is happening with the events from X telling us about the new window sizing.
It would be interesting if you could run GWorkspace with --GNU-Debug=NSEvent logging on, and perform the operations that cause the display to go wrong ...
If we can pin down the events immediately preceding the display corruption we should be able to see what's going wrong.
|
Sun 24 Sep 2006 12:53:28 PM UTC, comment #25:
> 1) You must have gworkspace with two or more file viewer windows open.
> 2) Open also the Inspector.
> 3) Open the Finder window. If it draws correctly, add and remove search
> options till when the "Search" button disappears and all the
> subviews are drawn in the wrong place. (also this could be used for testing
> because, before these changes, the Finder had no such problems)
> 4) Now select something in a file viewer window; you will see that the
> Inspector doesn't work anymore as expected.
I want only to add that closing and re-opening the Inspector window makes it to work again; (the window is not released; it gets only a -close: and then a -display). Hope that this help...
|
Sun 24 Sep 2006 11:47:02 AM UTC, comment #24:
> I've now got a 32bit version of gnustep running on my machine ... and that
> works fine for me, just like the 64bit version. Your original description of
> how to produce problems in GWorkspace does't produce any problems on either
> system. Of course, if it's a window manager specific issue that might explain
> why my system is OK, as both the 32bit and 64bit versions of gnustep are
> displaying through the same 64bit version of WindowMake/X.
>
> You say that 'Riccardo Mottoloa nd other people' also have the problems ... is
> there a common way to reproduce the problems or something similar about the
> systems/configurations of the people getting problems ... for me to make
> progress on this I really need to be able to reproduce the issue.
This is a way that, for me, works every time I try it:
1) You must have gworkspace with two or more file viewer windows open.
2) Open also the Inspector.
3) Open the Finder window. If it draws correctly, add and remove search options till when the "Search" button disappears and all the subviews are drawn in the wrong place. (also this could be used for testing because, before these changes, the Finder had no such problems)
4) Now select something in a file viewer window; you will see that the Inspector doesn't work anymore as expected.
|
Sun 24 Sep 2006 11:11:27 AM UTC, comment #23:
I've now got a 32bit version of gnustep running on my machine ... and that works fine for me, just like the 64bit version. Your original description of how to produce problems in GWorkspace does't produce any problems on either system. Of course, if it's a window manager specific issue that might explain why my system is OK, as both the 32bit and 64bit versions of gnustep are displaying through the same 64bit version of WindowMake/X.
You say that 'Riccardo Mottoloa nd other people' also have the problems ... is there a common way to reproduce the problems or something similar about the systems/configurations of the people getting problems ... for me to make progress on this I really need to be able to reproduce the issue.
|
Sun 24 Sep 2006 10:17:09 AM UTC, comment #22:
I've never got X errors but the problem regarding the Inspector window starting to draw wrong, the subviews of the Finder window messed up, browser columns not redrawn, etc... (confirmed also by Riccardo Mottola and other people), remains.
|
Sun 24 Sep 2006 09:03:17 AM UTC, comment #21:
OK ... I have changed the backend-gui interaction so that the backend now sends expose events to the gui and the gui then either marks the exposed rectangle for re-draawing, or tells the backend to flush the rectangle (if the window is buffered/retained).
Behavior on my system looks ok ... but as I couldn't reproduce the problem before, that doesn't really tell me anything other than that I don't appear to have broken anything.
Could you (yjchen) please get the latest code from svn and test it to see if it solves that problem with the X error?
|
Mon 18 Sep 2006 02:56:03 PM UTC, comment #20:
It does seem better to have the front-end handle expose - right now each backend is doing a lot of the processing to handle this and call front end methods. That not a clear seperation of tasks - the backend really should just handle communication between the server and the fron-end. I don't know how that would affect performance though.
|
Sun 17 Sep 2006 11:50:51 PM UTC, comment #19:
I am no expert here, but would it help, if we add a flag to the X window structure to mark that a window is currently in the process of being resized and expose events for that window would be handled specifically during that time?
I don't wuite see, ho we could handle resize events themself faster, without running into other problems.
|
Sat 16 Sep 2006 03:52:21 PM UTC, comment #18:
After tracing through the code I think I can see how this can happen ...
When an event arrives from the X server telling us that a window has been resized, we add it to the gui event queue, and the resize is processed when that event is reached by the gui processing the queue.
When an expose event arrives from the X server, it is processed immediately .. which means that it is possible for us to be painting the exposed area using a graphics context which has a shared memory image buffer corresponding to the window before a resize.
I'm not sure whether the correct approach to fix this is:
a. add expose events to the gui event queue as a new event type, and process them when the gui gets to that point in dealing with queued events or,
b. handle resize events (at least as far as renewing the gstate for the window is concerned) immediately when the X event arrives.
Perhaps Fred or Adam (who know the backend/graphics code much better than I) habve a view on this?
|
Fri 15 Sep 2006 05:13:57 AM UTC, comment #17:
That IS very interesting ...
The size of the OpenPanel window is supposed to be 384x426 (this is the size of the content view ... which should be the same as the size of the X window).
So either something is resizing the panel (and the code is not noticing the change and updating the buffer size to match) or the expose event is wrong. The code clips the resize rect to the window frame size ... so for it to send bad coordinates and generate the X error, I guess the frame size must have been increased ... suggesting that the window has been resized for some reason, but the buffer size has not been updated.
It would be nice if you could add an NSLog() to report the frame size when the expose event is cancelled, just to confirm this.
The change in size (6 pixels) is odd though ... with WindowMaker, the title bar of the window is 25 pixels high (including border) and the resize bar is 9 pixels (including border). So there is no obvious relationship between the change in size of the exposed rectangle and the window decoration :-(
|
Thu 14 Sep 2006 08:38:22 PM UTC, comment #16:
I can confirm it is from _addExposedRectangle::.
Here is some information:
For the first expose of open panel:
2006-09-14 13:16:30.068 Ink[7492] Expose 10485799 (cWin->ident 10485799)frame 0 0 384 426
2006-09-14 13:16:30.068 Ink[7492] drawable 10485799
2006-09-14 13:16:30.071 Ink[7492] end of drawable 10485799
2006-09-14 13:16:30.071 Ink[7492] End of _addExposedRectangle: 7
And second expose:
2006-09-14 13:16:35.435 Ink[7492] Expose 10485799 (cWin->ident 10485799)frame 0 0 390 426
2006-09-14 13:16:35.436 Ink[7492] drawable 10485799
2006-09-14 13:16:35.442 Ink[7492] X-Windows error - BadValue (integer parameter out of range for operation)
on display: :0.0
type: 0
serial number: 2267
request code: 143
2006-09-14 13:16:35.442 Ink[7492] end of drawable 10485799
2006-09-14 13:16:35.443 Ink[7492] End of _addExposedRectangle: 7
I think the interesting part is that x, y, w, h goes from
(0, 0, 384, 426) to (0, 0, 390, 426).
Therefore, the buffer is not big enough.
I guess the extra 6 pixel is from title bar.
|
Thu 14 Sep 2006 03:45:48 PM UTC, comment #15:
I will take a look again.
At the beginning, I thought the x, y, w, h is wrong.
After a second thought, maybe the buffer is too small.
I don't understand much about the XWindowBuffer.
But maybe the buffer is created with wrong size after the fix of coordination.
I do remember it is from _addExposedRectangle:: after a ExposeNotify,
then goes into ARTContext +handleExposeRect
and ends in XWindowBuffer.
Anyway, I will try to do it again later.
Maybe Enrico can also try it to be sure.
|
Thu 14 Sep 2006 05:57:02 AM UTC, comment #14:
Can you confirm that the off-by-one error in XShmPutImage comes from _addExposedRectangle:: in XGServerEvent.m line 952 please?
That seems exceedingly strange, since that call is in direct response to an X Expose event, and simply passes the X coordinates from that event ...
So firstly, if we are sending bad coordinates, we are doing so because the X system is passing bad coordinates to us.
And secondly, the _exposerect: merthod (which calls XShmPutImage) constrains the rectangle to be inside the window frame ... so this should also prevent any overstepping of the boundary.
Could it be that the image we are writing to is smaller than the window?
|
Thu 14 Sep 2006 12:55:53 AM UTC, comment #13:
By the way, I can confirm the problem with GWorkspace is the same,
therefore, the fix is the same by decrease w and h by 1.
And it only happens on art backend, not xlib backend.
So to reproduce, you need both art backend and WindowMaker so far.
|
Thu 14 Sep 2006 12:34:37 AM UTC, comment #12:
I tracked down the problem with XSync always true.
The error raises in XWindowBuffer.m line 589:
if (!XShmPutImage(display, drawable, gc, ximage,
x, y, x, y, w, h, 1))
The x, y, w, h is out of range, probably bigger than x window.
I can fix the problem by decrease w, h by 1,
but I guess it is not the correct fix.
I guess the calculation of window size and decoration
is not accurate for some window managers.
That's why it only happens on WindowMaker, but not metacity.
By the way, it is called from XGServerEvent.m line 952:
[self _addExposedRectangle: rectangle : cWin->number];
Hope it help.
|
Wed 13 Sep 2006 11:25:02 PM UTC, comment #11:
I can't produce a backtrace breaking on -raise or XGErrorHandler because I get no exception nor X error. Simply, the Inspector window starts to draw wrong.
|
Wed 13 Sep 2006 11:08:51 PM UTC, comment #10:
Below is the backtrace. Hope it is the correct way to produce it.
What puzzles me is that it only happens to WindowMaker,
but not metacity.
I will try to produce it under metacity and see.
By the way, I wipe out everything and reinstall again.
I sill have this problem.
#0 0x0f66f154 in poll () from /lib/libc.so.6
#1 0x0f6f4510 in ?? () from /lib/libc.so.6
#2 0x0f9f534c in -[NSRunLoop acceptInputForMode:beforeDate:] (
self=0x10187ac8, _cmd=0xfbd1904, mode=0xfbd1e48, limit_date=0x10206230)
at NSRunLoop.m:973
#3 0x0f9f436c in -[NSRunLoop runMode:beforeDate:] (self=0x10187ac8,
_cmd=0xfc02864, mode=0x0, date=0x10202ef8) at NSRunLoop.m:1045
#4 0x0fe9760c in -[GSDisplayServer(EventOps) getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x10173b28, _cmd=<value optimized out>, mask=4294967295,
limit=0x10207608, mode=0x0, flag=0 '\000') at GSDisplayServer.m:917
#5 0x0ea878ac in -[XGServer(X11Ops) getEventMatchingMask:beforeDate:inMode:dequeue:] () at XGServerEvent.m:2069
#6 0x0fd044e8 in -[NSApplication runModalForWindow:] (self=0x1015fcc0,
_cmd=<value optimized out>, theWindow=0x1025a120) at GSDisplayServer.h:187
#7 0x0fe095f4 in -[NSSavePanel runModalForDirectory:file:] (self=0x1025a120,
_cmd=<value optimized out>, path=0x0, filename=0xff82aa4)
at NSSavePanel.m:999
#8 0x0fdd7a74 in -[NSOpenPanel runModalForDirectory:file:types:] (
self=0x1025a120, _cmd=<value optimized out>, path=0x0, name=0xff82aa4,
fileTypes=<value optimized out>) at NSOpenPanel.m:447
#9 0x0fdd7980 in -[NSOpenPanel runModalForTypes:] (self=0x1025a120,
_cmd=<value optimized out>, fileTypes=0x10276820) at NSOpenPanel.m:430
#10 0x0fd755ec in -[NSDocumentController runModalOpenPanel:forTypes:] (
---Type <return> to continue, or q <return> to quit---
self=<value optimized out>, _cmd=<value optimized out>,
openPanel=0x1025a120, openableFileExtensions=0x10276820)
at NSDocumentController.m:375
#11 0x0fd7589c in -[NSDocumentController fileNamesFromRunningOpenPanel] (
self=0x102c99b8, _cmd=<value optimized out>) at NSDocumentController.m:402
#12 0x0fd75bb4 in -[NSDocumentController openDocument:] (
self=<value optimized out>, _cmd=<value optimized out>,
sender=<value optimized out>) at NSDocumentController.m:448
#13 0x0f1d6a64 in __builtin_avcall () from /usr/lib/libavcall.so.0
#14 0x0fa64e28 in GSFFCallInvokeWithTargetAndImp (_inv=0x102c6158,
anObject=0x3, imp=0x4dc7) at GSFFCallInvocation.m:636
#15 0x0fa66d0c in -[GSFFCallInvocation invokeWithTarget:] (self=0x102c6158,
_cmd=0xff392dc, anObject=0x102c99b8) at GSFFCallInvocation.m:706
#16 0x0fd055ec in -[NSApplication sendAction:to:from:] (
self=<value optimized out>, _cmd=<value optimized out>,
aSelector=0x10060860, aTarget=<value optimized out>, sender=0x102bb350)
at NSApplication.m:1980
#17 0x0fdc174c in -[NSMenu performActionForItemAtIndex:] (self=0x102bb2c0,
_cmd=<value optimized out>, index=<value optimized out>) at NSMenu.m:1021
#18 0x0fdcc1e8 in -[NSMenuView trackWithEvent:] (self=0x102bc3a8,
_cmd=<value optimized out>, event=<value optimized out>)
at NSMenuView.m:1490
#19 0x0fdc8fd0 in -[NSMenuView mouseDown:] (self=0x102bc3a8,
---Type <return> to continue, or q <return> to quit---
_cmd=<value optimized out>, theEvent=0x10217b18) at NSMenuView.m:1535
#20 0x0fe86fe0 in -[NSWindow sendEvent:] (self=0x102bb958,
_cmd=<value optimized out>, theEvent=0x10217b18) at NSWindow.m:3182
#21 0x0fd050ec in -[NSApplication sendEvent:] (self=0x1015fcc0,
_cmd=<value optimized out>, theEvent=0x10217b18) at NSApplication.m:1861
#22 0x0fd04064 in -[NSApplication run] (self=0x1015fcc0,
_cmd=<value optimized out>) at NSApplication.m:1371
#23 0x0fcf4974 in NSApplicationMain (argc=<value optimized out>,
argv=<value optimized out>) at Functions.m:72
#24 0x10001c80 in main (argc=4, argv=0x4, env=0x4dc7) at main.m:33
|
Wed 13 Sep 2006 10:13:34 PM UTC, comment #9:
Here's how to get the exact location of the error: Debug the app with this:
debugapp MyApp.app --GNU-Debug=XSynchronize
(make sure the --GNU-Debug=XSynchronize is an argument to the program)
then break on either -raise or XGErrorHandler, run and report the backtrace
|
Wed 13 Sep 2006 09:42:11 PM UTC, comment #8:
I download the latest GNUstep SVN today and install everything clean.
The problem is still there.
And I tried to reproduce the bug from GWorkspace.
On the terminal, I got very similar error:
2006-09-13 14:33:52.722 GWorkspace[23563] X-Windows error - BadValue (integer parameter out of range for operation)
on display: :0.0
type: 0
serial number: 4793
request code: 143
The request code is always 143 for Ink.app and GWorkspace.app.
For GWorkspace.app, the icon in inspector works fine,
but the Finder window has weird decoration.
The border is black, but still works.
I will try to wipe out everything and reinstall again
to see whether I can reproduce it again.
|
Wed 13 Sep 2006 05:33:11 PM UTC, comment #7:
I never build into the SVN directory. I've a separate place where I copy the sources and do the build.
But, to be 100% sure, I've also removed my /usr/GNUstep directory and reinstalled all from scratch. After this I've installed only GWorkspace.
The problem remains.
(fedora-5 linux with gcc 4.1.1)
|
Wed 13 Sep 2006 12:56:32 PM UTC, comment #6:
I can't reproduce the open problem, but the problem mentioned by enrico yes.
GSX11HandlesWindowDecorations seems to influence it, if set to YES it is problematic; if NO it works.
the upper left icon gets drawn wrong, but also, if the inspector is used on an application the buttons that represent the handled document types, get drawn wrongly on click. The highlight only works on the lower part (approximatively a square) while a second click in the upper part can select a part of the upper part left unhighlighted... Sounds like some sizing going wrong.
|
Wed 13 Sep 2006 12:41:38 PM UTC, comment #5:
With the changes to headers in the backend, and all the changes to the make package, I suspect that it would be quite easy for some old file to be left in place and picked up in a build unless a completely clean build is done ... so my first guess would be that the problems would go away after a clean build/reinstall. However, there is also the possibility of some other cause.
Perhaps there is a problem with the compiler ...
I use gcc-4.1.2 with debug=yes
Perhaps there is a system dependent problem ...
I'm running windowmaker on debian unstable em64t
|
Wed 13 Sep 2006 12:33:46 PM UTC, comment #4:
I can't reproduce the Open/Ink problem either. I run linux, latest svn, recompiled Ink, xlib and no themes/camaelon/etoile stuff. During the test I had other gnustep apps open like gworkspace too.
I can't reproduce the gworkspace either.
|
Wed 13 Sep 2006 10:53:49 AM UTC, comment #3:
I can't reproduce the GWorkspace problem either.
I just tried doing a 'make distclean' then 'svn update' then 'make debug=yes install' for make, base, gui and back. After doing that, GWorkspace still appears to be working normally for me.
|
Wed 13 Sep 2006 10:25:11 AM UTC, comment #2:
This is another problem that I think that can be related with the same bug. It has appeared yesterday and exists still now, with the today svn.
To reproduce (windowmaker):
1) open the Inspector window of gworkspace and choose the "Contents" inspector. (This to have the "Edit" button attive)
2) try to select some files: the preview will change, the icon will change and the "Edit" button will be enabled if the selection is editable.
3) now open the Finder window (actually it is a bit messed due of the recent changes in -gui and -back but this is not important in this case).
From this moment the Inspector window will become unusable; select again some files and you will see that only the lower part of the icon is redrawn and the "Edit" button will work only if you click nere its lower border.
These two windows don't have anything in common, the only thing is that both are not resizable windows.
|
Wed 13 Sep 2006 06:10:23 AM UTC, comment #1:
I can't reproduce this.
You say 'with latest svn' ... how recent is that really? I've been working on coordinate transformations in the gui/backend and comitted a lot of changes yesterday. Perhaps there was a problem at some point whch has now gone?
You could try updating gui and back from svn and rebuilding those libraries.
|
Wed 13 Sep 2006 05:42:45 AM UTC, original submission:
With lastest SVN,
if I use "Open..." in Ink.app twice,
I cannot select the item in NSBrowser on the second time
and an X window error shows up in terminal.
It happens on WindowMaker, but not metacity.
I track it down to the -styleoffset:::::: around
PropGetCheckProperty() for _NET_FRAME_EXTENT,
but I cannot figure why this happens.
To reproduce (under WindowMaker with Camaelon if matters):
1. openapp Ink.app
2. select "Open..." menu
3. Choose "Cancel" button
4. select "Open..." menu again
5. An error occurs in terminal and
the item in NSBrowser cannot be selected
|