Follow-up Comment #7, bug #21200 (project gnustep):
Yes, this issue was introduced into GNUstep when Nicolas Roads extended the
cairo backend to use 32 bit drawing depth, when available on the computer.
This in itself is something good, as this will allow us to implement
transparent window
Follow-up Comment #6, bug #19352 (project gnustep):
I had a look at the cairo PS file. It surely isn't a bitmap format. If you
have a closer look you will see a the lineto and moveto commands you would
expect. The whole file is incorrectly scaled and the font looks ugly. As far
as I can see from
Update of bug #21262 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Closed as it was
Update of bug #21273 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
The behaviour I get
Update of bug #21301 (project gnustep):
Category:None = Base/Foundation
Item Group:None = Bug
Status:None = Fixed
Assigned to:
Update of bug #21229 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #3, bug #21173 (project gnustep):
Added a cairo implementation for this method.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21173
___
Nachricht geschickt
Update of bug #18128 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as requested by initiator. The problem that the art backend has an
issue with 16 bit
Update of bug #13721 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as there was no further input from originator.
Update of bug #16262 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #4:
Changed category to backend
___
Reply
Follow-up Comment #1, bug #12374 (project gnustep):
Could ypu please try again with a recent version of GNUstep?
This issue should be resolved.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?12374
Update of bug #13592 (project gnustep):
Status:None = Wont Fix
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Follow-up Comment #2, bug #16302 (project gnustep):
This combination used to work. It was the original one I implemented :-)
I think it should be sufficient to change this method to just call callback:
in the Cygwin case. That is, put the usage of ET_WINMSG into
#ifndef__CYGWIN__
#endif
Update of bug #17020 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #17021 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #21279 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21279
___
Update of bug #21203 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21203
___
Update of bug #11976 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?11976
___
Follow-up Comment #10, bug #19352 (project gnustep):
I wrote a small test program and this shows that the problem with the clip
copying is completely within cairo. Here is the code:
#include stddef.h
#include cairo.h
#include cairo-ps.h
int
main (int argc, const char *argv[])
{
Follow-up Comment #15, bug #19352 (project gnustep):
On the cairo mailing list I got the following reply:
This is already in TODO:
• cairo_copy_clip() and cairo_copy_clip_flat()
http://lists.freedesktop.org/archives/cairo/2007-April/010520.html
Lets hope they implement it soon.
Update of bug #21446 (project gnustep):
Status:None = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #1:
Should be fixed in
Follow-up Comment #4, bug #21478 (project gnustep):
Thank you for explaining this. Still I don't see, why most of these methods
just duplicate code from the super implementation, but most likely this is not
important for the current issue.
Did you make any progress? As I said, I would like to
Update of patch #6286 (project gnustep):
Priority:7 - High = 5 - Normal
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Thank you for the
Follow-up Comment #4, patch #6286 (project gnustep):
First I have to apologize as I didn't find the time to test keyed encoding of
NSBezierPath on the Apple. If we really try to support keyed encoding here, it
should be compatible.
As for your latest problem, I just don't see the issue. What is
Follow-up Comment #4, bug #21571 (project gnustep):
style = 15 means NSTitledWindowMask | NSClosableWindowMask |
NSMiniaturizableWindowMask | NSResizableWindowMask
that is a normal window with a title frame.
I still need to find the place where we treat these values as signed numbers,
they
Follow-up Comment #2, bug #21723 (project gnustep):
Which window level is the window using? Is this the correct one and what
behaviour would be expected for that window level?
___
Reply to this item at:
Update of bug #21724 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #1:
I had a short look at the Price code and from that I would say it is a Gorm
decoding problem.
Update of bug #21766 (project gnustep):
Item Group:None = Bug
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:
Follow-up Comment #1, bug #21815 (project gnustep):
Could you please add a hint which application you are talking about? I don't
have a glue about it.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21815
Update of bug #21815 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #3:
From your comment I
Follow-up Comment #1, bug #21817 (project gnustep):
Was this the recursion bug we exchanged mails about? If so, could you please
close the bug report, as that problem was caused by the way simple web kit
inserted horizontal rules.
If not, could you please add some information on how to
Follow-up Comment #1, bug #21696 (project gnustep):
I spend some time tracking down this problem and as far as I can tell it is
caused by GSHorizontalTypesetter. There in the method layoutLineNewParagraph:
we get a rectangle for the next set of glyphs and this is already limited by
the text
Follow-up Comment #1, bug #21913 (project gnustep):
I don't quite understand what you are saying. There are of course plenty of
ways to change the default font size. The setting NSFontSize shoudl for
example affect the system font. But I have no idea whether Gorm will respect
this or if Gorm is
Update of bug #21912 (project gnustep):
Status:None = Duplicate
Depends on: = bugs #21625
___
Follow-up Comment #1:
Duplicate of #21625
Update of bug #21625 (project gnustep):
Category: Gui/AppKit = Backend
Status:None = Confirmed
___
Follow-up Comment #1:
As this bug report
Follow-up Comment #4, bug #21724 (project gnustep):
Could you please report on how to reproduce this problem with your demo
applications? I tried to open the panel, close it, open it again and so on,
but it just keeps on working. Even when pressing that nice button in between
it still reopens
Update of bug #21912 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #2:
No idea how to hide duplicates, at least put it in the correct category.
Update of bug #21695 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #21571 (project gnustep):
Category: Gui/AppKit = Backend
Assigned to:None = FredKiefer
___
Follow-up Comment #5:
Could you please
Follow-up Comment #3, bug #20453 (project gnustep):
I had a close look at the back trace and this looks rather normal to me. A
window gets displayed from the main thread redisplay mechanism. Here I can't
even tell whether a second thread is involved. What I don't see in you back
trace is the
Follow-up Comment #1, bug #12151 (project gnustep):
Is this still the case? In the mean time we have added code to support the
EWMH, which should result in some of our windows being excluded from the task
bar.
Could you please retest?
___
Update of bug #16302 (project gnustep):
Status: In Progress = Ready For Test
Assigned to: fedor = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #5, bug #21914 (project gnustep):
Could you please provide the used test application? Otherwise it is hard to
say for sure, if you are printing out the correct value.
From you comment I understand that the value you are looking for is the
amount of free space.
Could you please
Update of patch #6153 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as there was no further comment.
Update of patch #6286 (project gnustep):
Status:None = Done
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Most of this
Update of bug #21273 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21273
___
Update of bug #20884 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20884
___
Update of bug #21912 (project gnustep):
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #6, bug #20453 (project gnustep):
Does this problme still persist? If so, could you please add some more
information?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20453
Update of bug #22129 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #22230 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
We had a discussion about mini windows on the GNUstep mailing list just
about a month ago.
URL:
http://savannah.gnu.org/bugs/?22246
Summary: problem with key value observation
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Donnerstag 07.02.2008 um 08:42
Category: Base/Foundation
Update of bug #22247 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #1:
The first part of this change, mostly in gui, is done now. For TIFF and PNG
images we now set
Follow-up Comment #2, bug #22410 (project gnustep):
Just one more tip to get more output. Could you please restart the failing
application with the option --GNU-Debug=dflt
___
Reply to this item at:
http://savannah.gnu.org/bugs/?22410
Update of bug #22410 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Follow-up Comment #2, bug #22246 (project gnustep):
Added a small test program to show the problem. This has a GNUmakefile as
well as a XCode project file.
The behaviour is as described, when switching on the check box it switches
off immediately. This happens only on GNUstep on Apple it
Follow-up Comment #3, bug #22246 (project gnustep):
I was able to work around the problem with the checkbox being switched off
immediately. It turns out that this was caused by a call to
observeValueForKeyPath:ofObject:change:context: with an empty change
information.
This happens as the same
Follow-up Comment #6, bug #22246 (project gnustep):
Your change reduced the amount of get calls from three to two. What happens
shouldn't be too hard to understand. Instead of calling three overriden
methods the code now calls two, setValue:forKey and the real setter method.
As we have two
Update of bug #22246 (project gnustep):
Assigned to:None = CaS
Open/Closed: In Test = Closed
___
Follow-up Comment #8:
Great, my example
Update of bug #21979 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #6:
As the original
Update of bug #20453 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #8:
Yes, this looks like a background thread is trying to draw. The error message
that you did not
URL:
http://savannah.gnu.org/bugs/?22479
Summary: Wrong include in NSPage.m
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Dienstag 04.03.2008 um 18:45
Category: Base/Foundation
Severity: 2 -
Follow-up Comment #2, bug #22473 (project gnustep):
I don't know what the real reason for this problem is, but a simple way to
work around it should be to move the line
path = [path stringByStandardizingPath];
in [NSBundle initWithPath:] up before the isAbsolutePath check. In most cases
we
Update of bug #21571 (project gnustep):
Status: Ready For Test = In Progress
Open/Closed: In Test = Open
___
Follow-up Comment #12:
I reopened this
Follow-up Comment #14, bug #21571 (project gnustep):
Thank you for your feedback.
Again the values have wrapped around. We need to find out how this could
happen.
Could you please replace the line 1058 in XGServerWindow.m with the
following:
if (r window-xframe.size.width + l)
Update of bug #21571 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #18:
Closed as this is
Follow-up Comment #2, bug #19728 (project gnustep):
I have never used rigs myself, but the frist problem that you reported, the
issue with _gnu_process_args should only show up, when there is no proper way
to get the arguments of the applications. As this wont be the case in all
modern OS, your
Follow-up Comment #12, bug #22278 (project gnustep):
Anyway, I believe this is something to be solved/decided in
the theme, not in -gui per se. -gui only have to handle the
different style and delegate the drawing.
Just to make this point clear: This is already decided in the theme not in
Follow-up Comment #2, bug #22247 (project gnustep):
Moved the unpre-multiplication in the art backend one step down. The code was
already there for one format (RGB, 8 bit without clipping) and is now used in
all cases.
A next step would be to remove this unpre-multiply completely and adopt the
Follow-up Comment #3, bug #22247 (project gnustep):
Added a conversion to pre-multiplied in the draw method of NSBitmapImageRep.
This does not catch all cases, but most.
I failed to find a way of removing the obsolete division of alpha and later
multiplication in the render_alpha drawing path.
Update of bug #22247 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Closed this bug as
Update of bug #23233 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
Assigned to:None = FredKiefer
Follow-up Comment #1, bug #22677 (project gnustep):
Didn't you fix that yourself right after you found the problem?
Otherwise I will look into it.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?22677
Update of bug #23233 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #2:
I did some analysis and it turns out that this is really caused by the fix I
made to NSWindow.
Update of bug #23233 (project gnustep):
Status: Confirmed = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?23307
Summary: Potential problem in NSRunLoop
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Dienstag 20.05.2008 um 23:23
Category: Base/Foundation
Severity: 2
Update of bug #23454 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #21142 (project gnustep):
Depends on: = bugs #19720
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21142
___
Follow-up Comment #3, bug #23603 (project gnustep):
Could you please report the gdb bug to the Debian or gdb bug trackern?
Debugging with a broken gdb really is no fun. I know that from MinGW on Win32,
where no gdb has full Objective-C support.
As for your font problem I expexct that you are
Follow-up Comment #1, bug #23661 (project gnustep):
Could you please specify your cairo version and your screen resolution?
I am able to reproduce this behaviour on cairo 1.4.10, but cannot see any
issues in our code. We request a 12 pixel font and get back one with 14. Maybe
that cairo version
Follow-up Comment #2, bug #23661 (project gnustep):
I checked on Ubuntu 8.04 with cairo 1.6.0 (It works as long as I don't use
ffcall). There the height of the same font looks the same for both backends.
There is a difference in the width of the menu though, not sure what is
causing this.
If I
Update of bug #2 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #3:
Changed into a backend bug. I hope this is correct as there was no further
feedback.
Follow-up Comment #2, bug #23776 (project gnustep):
Could you please check which back versions those two release shipped with?
That way we can try to find out what changes in back that could result in
these differnces. As it works fine for XP it is most likely that we now use
some more advanced
Kevin Trieu wrote:
error building gnustep gui
log file attached
Looks like your JPEG library doesn't have a field progressive_mode in
the struct jpeg_decompress_struct. This means it must be either very old
or very new, although I doubt the later. Could you please check the
version and
Follow-up Comment #2, bug #23740 (project gnustep):
This is a integer number with just 7 of the upper bits set.
I don't see where this number should be comming from. The code in path.m
looks correct to me. Do you get any warnings from it? Theonly difference I see
here to other NSBezier code is
Update of bug #23968 (project gnustep):
Item Group:None = Bug
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
URL:
http://savannah.gnu.org/bugs/?24054
Summary: Segmentation fault in GSTest
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Dienstag 12.08.2008 um 20:40
Category: Base/Foundation
Severity: 3 -
Follow-up Comment #1, bug #23836 (project gnustep):
The displayed screenshot would be a valid result for clicking on the first
item of the selection and then scrolling down the mouse while keeping the
button down.
Are you sure you aren't doing anything similar to that?
Follow-up Comment #1, bug #22323 (project gnustep):
Did you test this on MacOSX, what is happening there?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?22323
___
Nachricht
Follow-up Comment #1, bug #24083 (project gnustep):
The log file looks like xmonad does not reparent windows, that way GNUstep
fails to compute any window border size and guesses them (wrongly of course).
Most likely they should all be 0.
But this should not result in an all black (or gray, as
Follow-up Comment #4, bug #23954 (project gnustep):
Sorry, my fault. I change a sentence I wrote around, but didn't adjust the
words. What I wanted to say was, NSTextView (and the abstract class NSText)
both support setFont: in GNustep. For the class NSTextStorage this method is
only provided as
Follow-up Comment #4, bug #23661 (project gnustep):
I checked through the cairo commit log, but couldn't find anything related to
the problem. Not sure, when it got fixed and how. That makes it harder to add
a work around for older cairo libraries.
When I commited some changes to
Follow-up Comment #3, bug #21690 (project gnustep):
Could you please try again with the latest cairo release and a newer GNUstep?
I would like to ge this bug report closed as we surely cannot resilve it from
our side.
___
Reply to this
Follow-up Comment #3, bug #24083 (project gnustep):
So there are two issues. One with the cairo backend and one with the xmonad
interaction.
For the cairo backend issue I will need to know which version of cairo and of
GNUstep are being used.
For the other problem I may need to explain first,
Update of bug #23854 (project gnustep):
Item Group:None = Change Request
___
Reply to this item at:
http://savannah.gnu.org/bugs/?23854
___
Update of bug #21690 (project gnustep):
Status:None = Works For Me
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #20632 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
I tried to improve
Update of bug #12478 (project gnustep):
Status:None = Wont Fix
Open/Closed:Open = Declined
___
Follow-up Comment #4:
As you found out
Follow-up Comment #1, bug #22476 (project gnustep):
All of this is caused by the missing alpha handling for bitmaps on windows.
There isn't much we can do about it. Perhaps a GDI+ based drawing system could
improve this, but there is nobody working on that.
Update of bug #12374 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
401 - 500 of 1310 matches
Mail list logo
