[bug #11976] Window does not properly miniaturize when GSAppOwnsMiniwindow == YES and GSX11HandlesWindowDecorations == NO
Update of bug #11976 (project gnustep): Status:None = Fixed Assigned to:None = FredKiefer Open/Closed:Open = In Test ___ Follow-up Comment #2: I added a patch by Stefan Bidigaray [EMAIL PROTECTED] to SVN. He claims that this resolves the problem, which I was not able to repoduce. Most likely it is caused by a special window manager or when there is no window manager at all, as in your case. ___ Reply to this item at: http://savannah.gnu.org/bugs/?11976 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #20695] lock problems with applications
Update of bug #20695 (project gnustep): Category:None = Application Item Group:None = Bug ___ Follow-up Comment #1: Assign this to category Application, not sure if this is correct, but bettern then no category. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20695 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #20451] uncontrolled thread creation / crash
Update of bug #20451 (project gnustep): Category:None = Base/Foundation ___ Follow-up Comment #1: Assigned category Base, which may be completely wrong, but better than no category. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20451 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #21229] Gorm cannot load GormDocument.gorm because cairo backend does not implement DPSshfill
URL: http://savannah.gnu.org/bugs/?21229 Summary: Gorm cannot load GormDocument.gorm because cairo backend does not implement DPSshfill Project: GNUstep Submitted by: yjchen Submitted on: Tuesday 10/02/2007 at 18:42 Category: Backend Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Below is the error message with trunk of GNUstep and Gorm. A quick scan on back/Source/cairo/ shows there is no implementation of DPSshfill. Art backend has one, though. 2007-10-02 15:38:22.367 Gorm[4342] Exception occured while loading model: subclass CairoContext(instance) should override DPSshfill: 2007-10-02 15:38:22.368 Gorm[4342] Failed to load Gorm 2007-10-02 15:38:22.369 Gorm[4342] Could not load Gorm file: /usr/local/GNUstep/System/Applications/Gorm.app/Resources/English.lproj/GormDocument.gorm 2007-10-02 15:38:22.369 Gorm[4342] NSWindowController: could not load nib named GormDocument.nib ___ Reply to this item at: http://savannah.gnu.org/bugs/?21229 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #19100] GWorkspace application focussing issues
Update of bug #19100 (project gnustep): Category: Backend = Gui/AppKit Status:None = Confirmed ___ Follow-up Comment #5: This is rather a gui than a back problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19100 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:
Follow-up Comment #2, bug #19352 (project gnustep): Please try once more with the current implementation of PS generation in the cairo backend. The result should be somewhat better. Still no EPS though, but they are discussing the addition of a EPS format on the cairo mailing list. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19352 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #21173] unimplemented overide in XGFontInfo
Update of bug #21173 (project gnustep): Category: Gui/AppKit = Backend ___ Follow-up Comment #2: This is a backend not a gui problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21173 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #14317] Failing in building the gnustep-gui
Update of bug #14317 (project gnustep): Open/Closed:Open = Closed ___ Follow-up Comment #3: Closed as there was no new input from original poster. ___ Reply to this item at: http://savannah.gnu.org/bugs/?14317 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #19974] Some images not handled correctly
Update of bug #19974 (project gnustep): Category: Application = Gui/AppKit ___ Follow-up Comment #4: Change into a GUI problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19974 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:
Follow-up Comment #3, bug #19352 (project gnustep): I'm still struggling with #21203. As soon as I get a handle on that, I'll try PS again. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19352 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #20451] uncontrolled thread creation / crash
Update of bug #20451 (project gnustep): Category: Base/Foundation = Application ___ Follow-up Comment #2: Reassigned category to 'application' for two reasons ... 1. the application probably should not be assuming that frameworks it links with don't use threads. While GNUstep tries to refrain from using threads, the MacOS frameworks use them extensively, so it seems unreasonable for apps to assume they aren't being used 2. the problem can't be directly with the base library anyway ... since it doesn't use threads (unlessthe application asks it to). Possibly the gui or the backend starts a thread (and I don't think they really ought to, because that's one advantage GNUstep has over the Apple frameworks), but even if they do, I think the application probably should work around the NetBSD problem. It seems to me that this is a portability issue in the application code (it's using _res directly itsself). ___ Reply to this item at: http://savannah.gnu.org/bugs/?20451 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #21133] NSKeyedArchiver doesn't encode NSData correctly
Update of bug #21133 (project gnustep): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #1: I think the actual problem was with NSData returning the wrong value in the classForCoder: method. I've corrected that ... please could you test and confirm that it works. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21133 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
