Update of bug #17735 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Could we try to reach a common understanding of this problem first and of how
this situation
Follow-up Comment #5, bug #17059 (project gnustep):
For the xlib backend this is a well known limitation. There was some mail
exchange a while ago on it. As far as I remember the solutution was as simple
as to extend the switch statement on bits_per_sample in _bitmap_combine_alpha
to handle 16
Update of bug #17059 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #6:
Changed category to backend, as this only fails on xlib.
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 window (the
Follow-up Comment #1, patch #5434 (project gnustep):
Sorry, I don't quite get the purpose of this patch. What is the intended
result? And is there a way to determine which window managers will support
this behaviour?
We already have different level of icon support build into GNUstep for
Hi Mark,
these changes look great. I will be away for the weekend, if nobody
beats me on integrating your stuff I will do so on Monday.
Thank you and keep the good work up
Fred
Mark Tracy schrieb:
I have fixed several bugs related to printing and PostScript generation.
After that, I could
implementation, with a FIXME added to this code.
Thank you
Fred
Matt Rice schrieb:
--- Fred Kiefer [EMAIL PROTECTED] wrote:
Hi Matt,
- There are already functions in NSWindow.m, e.g.
NSWindowList(), which
are supposed to return the windows in front to back
order. Perhaps it
would be possible
Follow-up Comment #2, bug #18080 (project gnustep):
To add some information to this bug report:
After some Suse updates my 10.1 this messages from the compiler are gone. So
there is hope :-)
___
Reply to this item at:
Mike Stathopoulos schrieb:
I’m running Fedora Core 6 through VPC and I tried to install GNUstep in
the environment but I get errors that I don’t have the right version of
gcc (see attached).
Looks like you don't have an Objective-C compiler installed. Most likely
this can be found in an
Chris Vetter schrieb:
when an email contains an URL and you happen to move the mouse over it,
the cursor changes to a 'pointing hand'. Nothing new here.
However, I just noticed that when the mouse pointer 'leaves' the content
rect, it doesn't change back to a normal 'pointer' anymore.
Update of bug #17702 (project gnustep):
Category:None = Gui/AppKit
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17702
___
Update of bug #18649 (project gnustep):
Category:None = Gorm
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18649
___
Update of bug #13721 (project gnustep):
Category:None = Backend
___
Follow-up Comment #1:
Could you please retest, if this problem still exists with current GNUstep
code.
Update of bug #18646 (project gnustep):
Category: Application = Backend
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18646
___
Update of bug #13593 (project gnustep):
Category: Application = Backend
___
Reply to this item at:
http://savannah.gnu.org/bugs/?13593
___
Update of bug #16436 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Should be fixed in
Update of bug #17735 (project gnustep):
Status:None = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #2:
Could you please
Update of bug #19031 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #1, bug #18199 (project gnustep):
Not sure if this is a valid request. In most cases the app icon gets
suppressed because there is another way to reactivate the application when it
looses focus. I don't see how we could know inside of GNUstep, if this is the
case or if we need
Follow-up Comment #1, bug #17030 (project gnustep):
I don't see, why this should be a GNUstep bug not an libungif one. Could you
please provide the offending image plus a back trace from GNUstep?
___
Reply to this item at:
Update of bug #17007 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Update of bug #17004 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Follow-up Comment #2, bug #15903 (project gnustep):
Last warning!
If you don't add an example, I will close this bug report next year :-)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?15903
Update of bug #17007 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17007
___
Update of bug #17004 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17004
___
Update of bug #11936 (project gnustep):
Open/Closed:Declined = Closed
___
Follow-up Comment #5:
Closed as there was no further answer from the original poster for two years
Update of bug #17096 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Closed as there was
Update of bug #17377 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #23:
Closed as there
Update of bug #5871 (project gnustep):
Status: In Progress = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #14:
The last fix
Update of bug #17735 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17735
___
Update of bug #18483 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed as no follow up was send.
___
Update of bug #13583 (project gnustep):
Status:None = Invalid
Open/Closed:Declined = Closed
___
Follow-up Comment #4:
Changed to closed
Update of bug #17112 (project gnustep):
Category: Gui/AppKit = Base/Foundation
Assigned to: gcasa = CaS
___
Follow-up Comment #6:
Changed to a base
Update of bug #4730 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Closed as there was
Update of bug #8335 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as this was
Update of bug #17003 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Harmless compiler
Update of bug #17002 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Harmless compiler
Follow-up Comment #3, bug #19031 (project gnustep):
Not sure, if you are correct. I would expect that, if you don't want the
standard accessory view for your document, you override the
shouldRunSavePanelWithAccessoryView method to return NO. Why would you want
any other accessory view to be
Follow-up Comment #5, bug #19031 (project gnustep):
The text there is not as clear to me as it seems to be for you:
You can control whether the default accessory view (which contains a pop-up
menu allowing the user to choose what type to save) appears in the Save panel
by overriding
Update of bug #18313 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #19301 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #18128 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as requested
Update of bug #19350 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #19351 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #19301 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #19352 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #1:
Yes, this about fonts. In the art backend it seems like fonts are stored with
the Postscript
Follow-up Comment #4, bug #18313 (project gnustep):
Fine for me, if you add XdndActionList support. Seems like it has become a
standard extension to the Xdnd protocol.
I leave this bug in the testing state until you have finished this.
Putting a comment on the limitation into NSDraggingInfo.h
Follow-up Comment #3, bug #18494 (project gnustep):
Thank you for analysing this bug. Now even I understand wh this is going
wrong :-)
I think for the standard use of an alert this is a great solution. If you
want top put up an alert it should be started by the main thread. We might
even want
Update of patch #5836 (project gnustep):
Status:None = Done
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
This is not related to the reported problem, but shouldn't the code in
rigs be moved over to use [NSProcessInfo initializeWithArguments:count:
environment:] instead of _gnu_process_args()?
Fred
Friedrich wrote:
URL:
http://savannah.gnu.org/bugs/?19728
Summary: librigs
Update of bug #19804 (project gnustep):
Severity: 3 - Normal = 1 - Wish
Item Group:None = Change Request
___
Follow-up Comment #1:
The # character is
Update of bug #19764 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
Did this problem persist after doing a make clean? I am using the cairo
backend regularly and
Update of bug #19764 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Reported as being
Follow-up Comment #3, bug #19804 (project gnustep):
What about moving the actual string into a resource? We could use something
like _(@Cmd-Shortcut), _(@Alt-Shortcut) and _(@Shift-Shortcut) in the
code and have the lines
Cmd-Shortcut=Cmd+
Alt-Shortcut=Alt+
Shift-Shortcut=Sft+
in the
Follow-up Comment #2, bug #19974 (project gnustep):
I had a look at the two images that you send along with the original post to
the mailing list (test.png and test.tiff). These were both 48 bpp images. I
am a bit surprised that GNUstep supports that format at all. Was this with
the standart art
Update of bug #20274 (project gnustep):
Category: Gui/AppKit = Gorm
Item Group:None = Bug
Status:None = Confirmed
Follow-up Comment #5, bug #20057 (project gnustep):
I made some tests myself and the whole mechanism of doing frame and bounds
transformation in GNUstep seems to be wrong, not just the rotation case. For
example even a simple translate on bounds produces a wrong result.
Looking at the code I
Update of bug #20057 (project gnustep):
Status: Confirmed = In Progress
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #20057 (project gnustep):
Open/Closed: In Test = Open
___
Follow-up Comment #7:
OK, even after a hack to get rotated text working for the cairo backend there
is still a lot to
Update of bug #19351 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed
___
Reply to this item at:
Update of bug #19350 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed
___
Reply to this item at:
Update of bug #19878 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #1:
The class
Follow-up Comment #8, bug #20057 (project gnustep):
I made some progress here. With the text field now flipped as on MacOSX the
bounds rotation works in the same direction, but the mixing of rotation and
translation of bounds is still broken.
I must admit I am a bit glueless what goes on here.
Update of bug #20434 (project gnustep):
Item Group:None = Change Request
___
Follow-up Comment #2:
I'm not sure if we should follow OpenStep here. The method setStringValue: is
clearly defined
Update of bug #11569 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #11557 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #10825 (project gnustep):
Category: Gui/AppKit = Backend
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
I moved this over
Update of bug #16592 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #3:
There has been another set of window frame hanling patches by Richard. The
original problem
Update of bug #13708 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #1:
Could you please retest this behaviour again? It should be fixed by Richards
window frame
Update of bug #20453 (project gnustep):
Item Group:None = Bug
___
Follow-up Comment #1:
Could you please run the application with the --debug option and report back
the full back
Update of bug #20473 (project gnustep):
Category:None = Base/Foundation
___
Follow-up Comment #1:
I take it from your stack dump that you are using GNUstep on MS Windows with
Msys. What I don't
Update of bug #20632 (project gnustep):
Item Group:None = Bug
___
Follow-up Comment #1:
It looks like the byte swapping for the colour mask produced a nonsensical
result in your case.
Update of bug #18412 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of patch #6159 (project gnustep):
Status:None = Done
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Applied the patch
Update of patch #6153 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
It is true that
Update of patch #5962 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #2:
I closed this
Update of bug #20884 (project gnustep):
Severity: 5 - Blocker = 4 - Important
Item Group:None = Bug
Assigned to:None = FredKiefer
Follow-up Comment #3, bug #20884 (project gnustep):
Sorry, but I was hoping to get the full application code from you. With that
it should be rather simple to see, where the problem comes from.
During the last month there have been only a few changes to NSCell and
NSButtonCell or other files
Update of bug #20884 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #5:
Back at my computer it was easy to find out what caused this trouble, fixing
it will be a bit
URL:
http://savannah.gnu.org/bugs/?20955
Summary: NSNotificationCenter does not ignore exceptions
during notification sending
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Samstag 01.09.2007 um 21:15
Category:
Update of bug #20884 (project gnustep):
Status: Confirmed = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #6:
Should be fixed in
Update of bug #20956 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #13608 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #20966 (project gnustep):
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
___
Follow-up Comment #1:
Here the code for
Follow-up Comment #1, bug #20965 (project gnustep):
First, thank you for testing cairo!
Nicolas has done a few more changes to the cairo code, so please give it
another try. Your X server doesn't support 32 bits, in that case it should
fall back to the old code and use a 24 bits visual. If the
Update of bug #20965 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #21200 (project gnustep):
Category:None = Backend
Severity: 3 - Normal = 2 - Minor
Item Group:None = Change Request
Assigned to:
Update of bug #21173 (project gnustep):
Item Group:None = Change Request
___
Follow-up Comment #1:
It is just not possible to implement this method properly for XGFontInfo. It
should be possible
Update of bug #21203 (project gnustep):
Category:None = Backend
Item Group:None = Bug
___
Follow-up Comment #1:
No idea, where the
Update of bug #21201 (project gnustep):
Category:None = Backend
Item Group:None = Bug
Status:None = Fixed
Assigned to:
Update of bug #11976 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #20695 (project gnustep):
Category:None = Application
Item Group:None = Bug
___
Follow-up Comment #1:
Assign this to
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.
Update of bug #19100 (project gnustep):
Category: Backend = Gui/AppKit
Status:None = Confirmed
___
Follow-up Comment #5:
This is rather a
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.
Update of bug #21173 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #2:
This is a backend not a gui problem.
Update of bug #14317 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Closed as there was no new input from original poster.
Update of bug #19974 (project gnustep):
Category: Application = Gui/AppKit
___
Follow-up Comment #4:
Change into a GUI problem.
___
Reply
Follow-up Comment #5, bug #21200 (project gnustep):
You problem does not belong to this bug report, but into #21203 :-)
If you are using the latest SVN then changing the assignement in
XGCairoXImageSurface may make a difference. Please try the values 24 and 32
and also report the depth that is
Update of bug #21229 (project gnustep):
Item Group: Bug = Change Request
___
Follow-up Comment #1:
I don't quite understand what you are complaining about. Is it that the cairo
(as well as the
301 - 400 of 1310 matches
Mail list logo
