Update of bug #17377 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #23:
Closed as there
Follow-up Comment #22, bug #17377 (project gnustep):
I believe this is now fixed in gui and for the xlib and art backends.
I've just comitted some changes for flushing data to screen and everything
seems to be working correctly for them now.
All passing of coordinates between frontend and
Follow-up Comment #20, bug #17377 (project gnustep):
Just confirm that everything looks fine now after a reinstallation of GNUstep
SVN version. Popup menu and drag-and-drop behave as expected. Test with Azalea
and Metacity.
___
Reply to
Follow-up Comment #18, bug #17377 (project gnustep):
If a view is in a window with a title bar, it gets dragging events not in its
frame but in a rect that is shifted down by about the size of the tile bar.
This is visible in GWorkspace, in GNUMail moving a message in another mailbox
and in Gorm
Follow-up Comment #19, bug #17377 (project gnustep):
Confirmed in Gorm.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17377
___
Message sent via/by Savannah
Update of bug #17377 (project gnustep):
Status: In Progress = Ready For Test
___
Follow-up Comment #9:
I have reworked a lot of the frame handling code in the gui to correct the
methods mapping
Follow-up Comment #10, bug #17377 (project gnustep):
Something seems odd with this fix please see the attached pics.
The frames seem off, more than before.One of them is with X11
decorations, the other is with GS decorations.
GJC
Additional Item Attachment, bug #17377 (project gnustep):
File name: GSDecorations.jpg Size:353 KB
GNUstep drawing the decorations
http://savannah.gnu.org/bugs/download.php?file_id=10700
___
Reply to this item at:
Follow-up Comment #11, bug #17377 (project gnustep):
I made a small fix to setting hints ... seems to correct problem with frame
growing (though I'd like to understand why it works).
Other than that, I'm not sure what problem you are seeing ... I don't know
what either jpeg is expected to look
Follow-up Comment #12, bug #17377 (project gnustep):
On Metacity (Gnome) and Azalea, the Ink and Gorm work fine.
In GWorkspace, the content view of NSWindow is shifted
and a black space is left. Even the standard NSAlertPanel
in GWorkspace has this problem, but not in Gorm.
But menu looks fine.
Follow-up Comment #13, bug #17377 (project gnustep):
Here *ALL* the apps have the black space between the title bar and the
contents.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17377
Follow-up Comment #14, bug #17377 (project gnustep):
Just attach a screenshot. The left side is Gorm, which looks normal. The
right side is GWorkspace, which has the black shadow.
___
Additional Item Attachment:
File name: GUI-bug.png
Follow-up Comment #15, bug #17377 (project gnustep):
Just attach a screenshot. The left side is Gorm, which looks normal. The
right side is GWorkspace, which has the black shadow.
I can only confirm that all the applications, Gorm included, have the black
space. This with WindowMaker-0.92 and
Follow-up Comment #16, bug #17377 (project gnustep):
After recent changes, this seems to work perfectly. :) The frames look the
same with both X11 and GS drawing the decorations.
Sorry for the terse description earlier, I was leaving, but noticed a
problem, so I just wrote it down so that
Update of bug #17377 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #17:
Okay, found one minor issue. When opening a pop up buttons, the menu items
are not aligned
Update of bug #17377 (project gnustep):
Status:None = In Progress
Assigned to:None = CaS
___
Reply to this item at:
Follow-up Comment #8, bug #17377 (project gnustep):
Is anyone working on this?
It seems to me that the _frame ivar should be fixed to contain the proper
window frame (ie the rectangle occupied by the entire window incuding
decorations) on the screen. Currently the _frame ivar varies depending
Follow-up Comment #6, bug #17377 (project gnustep):
I finally found Alexander's documentation in NSWindow.h:
/*
A window really has three interesting frames:
The screen frame. This is the frame of the _entire_ window on the screen,
including all decorations and borders (regardless of
Le 15 août 06 à 19:20, Richard Frith-Macdonald a écrit :
On 11 Aug 2006, at 13:37, Fred Kiefer wrote:
Follow-up Comment #5, bug #17377 (project gnustep):
The code we have there in the different decorators is there on
purpose. When
Alexander Malmberg implemented the window decoration
Follow-up Comment #7, bug #17377 (project gnustep):
In my previous entry, I wrote incorrect statements about frameRect and
contentRect, I thought windowFrame and frameRect were totally unrelated by
reading the following method name.
/*
Internal helpers.
Returns the internal window frame rect
On 11 Aug 2006, at 13:37, Fred Kiefer wrote:
Follow-up Comment #5, bug #17377 (project gnustep):
The code we have there in the different decorators is there on
purpose. When
Alexander Malmberg implemented the window decoration handling
inside of
GNUstep gui he wanted to end up with
Follow-up Comment #5, bug #17377 (project gnustep):
The code we have there in the different decorators is there on purpose. When
Alexander Malmberg implemented the window decoration handling inside of
GNUstep gui he wanted to end up with things right the way they are now.
I remember there was
Follow-up Comment #1, bug #17377 (project gnustep):
Just to make sure I understand this correctly, would you say the the GNUstep
behaviour for the case GSX11HandlesWindowDecorations=YES is totally correct?
If not, which problem did I overlook for this case?
For the case
Follow-up Comment #2, bug #17377 (project gnustep):
Hi Fred,
I have done more tests today. It's more complicated than what I thought
initially.
My output test results were done with Azalea (Etoile WM derived from
OpenBox), it seems to have extra issues related to resize handling. So I
decided
Follow-up Comment #3, bug #17377 (project gnustep):
I think I have found where the bug is located at least when backend
decorations are used.
In GSWindowDecorationView.m, there are the two following methods called by
their NSWindow counterparts.
+ (NSRect) contentRectForFrameRect:
Follow-up Comment #4, bug #17377 (project gnustep):
When GNUstep draws its own decorations (GSX11HandlesWindowDecorations=NO),
these methods work properly. The problem comes, as you pointed out when
GNUstep DOESN'T draw the decorations (GSX11HandlesWindowDecorations=YES) and
it is left up to
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=17377
Summary: Various frame related methods in NSWindow return
wrong results
Project: GNUstep
Submitted by: qmathe
Submitted on: mardi 08.08.2006 à 21:41
27 matches
Mail list logo
