[bug #17717] Use "open panel" twice make it unusable

URL: Summary: Use "open panel" twice make it unusable Project: GNUstep Submitted by: yjchen Submitted on: Wednesday 09/13/2006 at 01:42 Category: Backend Severity: 3 -

[bug #17717] Use "open panel" twice make it unusable

Update of bug #17717 (project gnustep): Status:None => Works For Me ___ Follow-up Comment #1: I can't reproduce this. You say 'with latest svn' ... how recent is that really? I've been wo

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #2, bug #17717 (project gnustep): 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" ins

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #3, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #4, bug #17717 (project gnustep): 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. __

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #5, bug #17717 (project gnustep): 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 gue

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #6, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #7, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #8, bug #17717 (project gnustep): 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 e

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #9, bug #17717 (project gnustep): 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 a

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #10, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #11, bug #17717 (project gnustep): 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. ___ Reply to this item at:

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #12, bug #17717 (project gnustep): 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 bigge

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #13, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #14, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #15, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #16, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #17, bug #17717 (project gnustep): 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 i

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #18, bug #17717 (project gnustep): 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 reache

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #19, bug #17717 (project gnustep): 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 wui

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #20, bug #17717 (project gnustep): 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 communicat

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #21, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #22, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #23, bug #17717 (project gnustep): 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 cou

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #24, bug #17717 (project gnustep): > 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.

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #25, bug #17717 (project gnustep): > 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 > su

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #26, bug #17717 (project gnustep): > 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 not

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #27, bug #17717 (project gnustep): 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 Def

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #28, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #29, bug #17717 (project gnustep): 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 0 KeymapNotify 8388848 B

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #30, bug #17717 (project gnustep): Now, I can say it is associated with the left-mouse down in the open panel. Still cannot find the bug yet. ___ Reply to this item at: __

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #31, bug #17717 (project gnustep): 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 in

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #32, bug #17717 (project gnustep): 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(@"XSizeHi

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #33, bug #17717 (project gnustep): 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.

[bug #17717] Use "open panel" twice make it unusable

Update of bug #17717 (project gnustep): Assigned to:None => CaS ___ Follow-up Comment #34: I haven't been able to work out as much as I hoped from the trace of GWorkspace events ... One

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #35, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #36, bug #17717 (project gnustep): > ... > 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #37, bug #17717 (project gnustep): 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 befo

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #38, bug #17717 (project gnustep): > 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 offs

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #39, bug #17717 (project gnustep): > 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 tha

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #40, bug #17717 (project gnustep): 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 ... g

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #41, bug #17717 (project gnustep): > 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #42, bug #17717 (project gnustep): 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. ___ Reply to this item at:

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #43, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #44, bug #17717 (project gnustep): > 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 xE

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #45, bug #17717 (project gnustep): 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

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #46, bug #17717 (project gnustep): > 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_EXT

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #47, bug #17717 (project gnustep): 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 manag

[bug #17717] Use "open panel" twice make it unusable

Follow-up Comment #48, bug #17717 (project gnustep): > 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 manage

[bug #17717] Use "open panel" twice make it unusable

Update of bug #17717 (project gnustep): Status:Works For Me => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #49: I beleieve this i

Re: [bug #17717] Use "open panel" twice make it unusable

Yen-Ju Chen schrieb: > Follow-up Comment #43, bug #17717 (project gnustep): > > 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 windo