Update of bug #14497 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #11936 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Reply to this item at:
Update of bug #3956 (project gnustep):
Item Group: Bug = Change Request
Status:None = In Progress
___
Follow-up Comment #6:
I added a bit of
Follow-up Comment #1, bug #13592 (project gnustep):
I am willing to implement a patch here, but based on which data, available to
the backend, should the window class be choosen? Should we change the window
class, when that property changes?
Update of bug #12300 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #2:
Changed the bug category to backend, as this problem seems to show up only
with the art
Update of bug #14803 (project gnustep):
Status:None = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Follow-up Comment #2, bug #14803 (project gnustep):
Tested and verified. This is working properly.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14803
___
I am not sure whether this is a bug, or a difference in
interpretation of the OpenStep spec... I apologize if this has been
discussed before.
In Cocoa Foundation, if I have an NSLock that has not already been
locked, and I do:
[myLock unlock]
it is ignored, and the program continues.
Follow-up Comment #8, bug #14635 (project gnustep):
it works on my NetBSD/ppc system now.
Unfortunately I can't try on sparc for the ffcall reasons you know, but as
you describe the problem your fix should be definitive for current netbsd
versions.
Update of bug #14635 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
10 matches
Mail list logo
