Follow-up Comment #2, bug #24054 (project gnustep):
Strange this may be due to system differences. I am working on a 32 bit
system and you are most likely using your 64 bit one.
Greg gets similar errors from art on his 64 bit system but I havent't been
able to reproduce this.
I will recompile
Follow-up Comment #6, bug #24083 (project gnustep):
It really would be best to split of this bug report into two. Otherwise we
always need to state, which of the two issues (xmonad, cairo) we are talking
about.
Cairo:
In back 0.14 the check for cairo 1.6 is a compile time check, since then I
Follow-up Comment #5, bug #24054 (project gnustep):
I recompiled GNUstep from SVN, but the problem persists.
Could you please try it yourself in a32 bit environment?
Or do you have any idea, how I could get more meaningful debugging
information?
Follow-up Comment #7, bug #24054 (project gnustep):
Thank you for this additional information. Looks like I will have to do the
dirty debugging myself. :-)
From what you wrote I think I will start with some debug statements in the
NSAutoreleasePool release or dealloc method.
Now that I looked
Follow-up Comment #8, bug #24054 (project gnustep):
My comment about two threads requesting the same pool was of course nonsense.
The pool cache is thread specific.
I added the following line to dealloc on NSAutoreleasePool:
printf(release an autorelease pool %p thread %p count %d n, self,
Follow-up Comment #9, bug #24054 (project gnustep):
I changed my printf statement and moved it to different places. This is what
I get now:
end thread pool cache 0x823ad04 current thread 0x823ace0 ended thread
0xb40004c0 count 1
push pool 0x823b330 thread 0x823ace0 count 2
pop pool 0x823b330
Update of bug #24054 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #24167 (project gnustep):
Category:Gorm = Backend
___
Follow-up Comment #1:
Which window manager are you using? I tried to reproduce this behaviour on
KDE 4, but faield to
Just a few weeks ago I made a change to the art backend that should help
with 16 bit graphics between machines with different endianess. Could
you please try to get GNUstep from SVN and compile it yourself to see if
this change fixes the problem?
I only have i86 processors, so I am not able
format?
Fred
Stephane Gourichon wrote:
Fred Kiefer wrote:
Just a few weeks ago I made a change to the art backend that should
help with 16 bit graphics between machines with different endianess.
Do you mean that vnc encodes data big-endian ? All my machines (vnc
server and client) have little
Thank you for testing all the different combination. But the last two
failure you got were to be expected. The art backend doesn't work with 8
bit graphic (for strange reasons the xlib backend also doesn't work well
here, only the cairo backend of GNUstep is working in that setup at the
Follow-up Comment #1, bug #24200 (project gnustep):
The line [GSCurrentContext() flushGraphics]; is used in the NSSavePanel to
display progress information on big directories.
This only happends when explicitly requested by setting the property
GSSavePanelShowProgress to YES. So the simplest
Update of bug #20453 (project gnustep):
Status: Confirmed = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #11:
Closed as
Update of bug #24054 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24054
___
Follow-up Comment #1, patch #6630 (project gnustep):
Your patch removes only two usages of this flag from the code. I am not sure,
whether this approach would create even more problems in the long run.
Shouldn't we remove this optimisation completely?
Nicola, what is your opinion here, if I
Follow-up Comment #1, bug #24153 (project gnustep):
There are different ways to resolve this issue. The simplest would be to make
this function non-inlined, the next to put the code in the header. But I don't
like either of them. I would prefer to remove this function completely, at
least from
Follow-up Comment #3, patch #6630 (project gnustep):
Good point. I would expect that the optimisation is used less then five times
per drawing request on each view. But it will be hard to count.
A grep on flipped_view shows that this mostly is used for NSScrollView and
there is another hack in
Update of bug #24153 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #24200 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #24083 (project gnustep):
Summary: Offset issues with the xmonad WM; blank windows
with the cairo backend = Offset issues with the xmonad WM
___
Follow-up Comment #10:
Removed the cairo part from the
Update of bug #23831 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Change Request
Status:None = Ready For Test
Assigned to:
Update of bug #23854 (project gnustep):
Category: Application = Gui/AppKit
___
Follow-up Comment #1:
I changed this report to the gui category, as this in something that could be
of interest for
Follow-up Comment #1, bug #24601 (project gnustep):
Just some idea, would it be a better solution to move the handling of the
toolbar into the GSWindowDecorationView?
That way the content view of the window would be just that and everything
else that also is displayed in the same window gets
Update of bug #24345 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #1:
I implemented some basic image scaling and improved other parts of the
Windows image handling
Update of bug #24601 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #2:
I just implemented the first half of my proposal. What is left to do is to
move the toolbar
Update of bug #24345 (project gnustep):
Open/Closed:Open = Closed
Depends on: = bugs #15778
___
Follow-up Comment #2:
Duplicate of #15778
Follow-up Comment #1, bug #24708 (project gnustep):
I am not able to reproduce this issue. I tried Terminal and apart from the
horrible font it started up it works quite nicely and fast.
Could you please specify, which of the different GNUstep drawing backends
(xlib, art, cairo) is showing this
Follow-up Comment #1, bug #24707 (project gnustep):
It looks like this change may be causing this problem:
2008-05-08 21:04-EDT Gregory John Casamento [EMAIL PROTECTED]
* Source/NSWindow.m: (-(void)miniaturize: (id)sender):
Change to prevent miniwindow from disappearing.
Follow-up Comment #4, bug #24707 (project gnustep):
Not sure, whether reverting the old change is the right solution. You most
likely had a pretty good reason for that change and we could move the hidding
of the window into the backend and only call it, when there is no window
manager handling
Follow-up Comment #2, bug #24729 (project gnustep):
When doing a resize while the window manager handles the windows borders we
actually try to redraw the content of the window, when the border dragging
leaves us time for that. So most likely it should also be possible, when we
handle the window
Update of bug #24709 (project gnustep):
Category:None = Gui/AppKit
Severity: 3 - Normal = 2 - Minor
___
Follow-up Comment #1:
Would you mind to
Update of bug #24728 (project gnustep):
Category:None = Application
___
Follow-up Comment #1:
Imade this an application bug, as I really don't understand what is happening
here and there
Follow-up Comment #1, bug #24758 (project gnustep):
Is it possible that you did forget to submit the change? The bug is set to
fixed here, but no change was done in SVN.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24758
Follow-up Comment #1, bug #24782 (project gnustep):
Could you please add an example NIB file showing this behaviour?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24782
___
Follow-up Comment #9, bug #20057 (project gnustep):
Last summer I made some more progress not documented here an I was even able
to reproduce the behaviour cited below. Still more complex combination of
rotation and translation where still wrong.
Now I am trying to get an application working
Follow-up Comment #10, bug #20057 (project gnustep):
I put in an improved version of the code below, this should now correct all
combinations of bounds trnaslation and bounds rotation. Still setting bounds
in rotated view is not correct and the relationship of bounds and frames in
the rotated
Update of bug #24709 (project gnustep):
Category: Gui/AppKit = Backend
Status: Fixed = None
Open/Closed: Closed = Open
Follow-up Comment #2, bug #24845 (project gnustep):
Does Gorm override any of these methods? If so, the implementation may need
some adjustment. I hope to have time to inspect this later today.
If the code in gui turns out to be wrong, could you please add a test in the
testsuit? I am trying to
Follow-up Comment #4, bug #24845 (project gnustep):
Could you please hint me to the Gorm code involved? What I found is
GormViewEditor with calls like:
[self setFrame: [_editedObject frame]];
[self setBounds: [_editedObject frame]];
Is this what you are talking about? In that case, I will
Update of bug #24845 (project gnustep):
Category:Gorm = Gui/AppKit
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:
Follow-up Comment #2, bug #24785 (project gnustep):
Some more information from the mailing list. Sadly I never did get a reply to
my last mail.
Gregory Weston wrote:
In article [EMAIL PROTECTED],
Marko Riedel [EMAIL PROTECTED] wrote:
the environment is KDE 3.5 (sorry, I had no choice
Update of bug #24859 (project gnustep):
Item Group:None = Change Request
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:
Update of bug #24886 (project gnustep):
Category:Gorm = Gui/AppKit
___
Follow-up Comment #1:
I think this is rather a gui or back problem, as I get the same problem with
other applications
Follow-up Comment #3, bug #24785 (project gnustep):
I still cannot reproduce this with SystemPreferences. Looking at the code I
noticed that this application does not use the normal main loop. Could this be
a common property of all applications showing this behaviour? (Is there any
appart from
Update of bug #24900 (project gnustep):
Status:None = Works For Me
Open/Closed:Open = Declined
___
Follow-up Comment #1:
At least for two
Update of bug #20057 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #11:
Changed this bug
Follow-up Comment #1, bug #24919 (project gnustep):
Could you please provide a back trace for this or even better an example to
reproduce this behaviour?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24919
Update of bug #24923 (project gnustep):
Category:None = Gui/AppKit
___
Follow-up Comment #1:
This definitly is a gui issue, as the code is located there.
There may be endianness problems,
Update of bug #24956 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
URL:
http://savannah.gnu.org/bugs/?24958
Summary: NIB loading of FlexiSheet broken
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Fr 28 Nov 2008 09:18:35 GMT
Category: Gui/AppKit
Severity: 3 -
Follow-up Comment #4, bug #24958 (project gnustep):
Thanks now it works again.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24958
___
Nachricht geschickt von/durch Savannah
Update of bug #21229 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21229
___
Update of bug #21301 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21301
___
Update of bug #23454 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Actually I had changed that to a run time check later on. As nobody commented
on this any more
Update of bug #24153 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #24200 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #23678 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?23678
___
Update of bug #22496 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?22496
___
Update of bug #21696 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #22409 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #21695 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #21681 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?21681
___
Update of bug #13708 (project gnustep):
Status:None = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
No reply for some
Follow-up Comment #7, bug #24785 (project gnustep):
Thank you for this information. Now at least we ahve an idea why this strange
behaviour could happen.
I am not sure whether this is related, but after Richards patch to better
report exceptions I did get the following when closing a process:
Follow-up Comment #12, bug #24083 (project gnustep):
Does the border issue for xmonad still persist? There was another change to
the way we handle window offsets and perhaps this solves this problem was
well. Could you get your user to try it with GNUstep gui from SVN trunk?
Follow-up Comment #3, bug #14967 (project gnustep):
Does this problem still exist? In the meantime I changed some of the image
handling, especially for the art backend and perhaps this improved this
scaling artefact.
To reproduce the problem locally I would need your full application code, at
Follow-up Comment #9, bug #24785 (project gnustep):
Not very likely, athough it might be releated. You were testing on a 64-bit
machine and your problem was with the did launch notification. I am getting
a problem on the terminate notification and am using a 32-bit machine. Most of
all, I
Follow-up Comment #1, bug #24979 (project gnustep):
Are you sure that what you report as the expected behaviour is what is
happening in Cocoa?
I am very sure that nibinstantiate gets called a lot later there. I can see
how the behaviour you describe is a lot easier to implement correctly and
Follow-up Comment #2, bug #24994 (project gnustep):
I second this request. Yes, the new way of compiling isn't that complicated,
but I am very lazy and I recompile GNUstep about twice a day.
I vote for make sysinstall.
___
Reply to this
Follow-up Comment #11, bug #24785 (project gnustep):
Did you check that your double conversion also works with a return value of
NSTerminateLater?
You see, I am too unsure what a conversion to BOOL actually does. (Being
spoiled by Java day time programming, I mistrust a compiler) Most likely it
URL:
http://savannah.gnu.org/bugs/?24995
Summary: NSURLProtocol uses wrong alloc prototype
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Mi 03 Dez 2008 07:45:52 GMT
Category: Base/Foundation
Follow-up Comment #5, bug #22282 (project gnustep):
The back trace you get is unrelated to the backend, it is caused by a hack in
put into gui to better support image drawing on scaled views. In your specific
case the image seems to have a zero sized extend and we should just ignore the
draw
Update of bug #25004 (project gnustep):
Category:None = Base/Foundation
___
Follow-up Comment #1:
I justed fixed the first part of this bug report. NSWindowContoller
initWithCoder: should now
Update of bug #24984 (project gnustep):
Status:None = Need Info
___
Follow-up Comment #1:
This already happens for text fields (actually it is implemented on NSCell)
that are set to
Update of bug #25040 (project gnustep):
Category: Application = Base/Foundation
___
Follow-up Comment #2:
This definitily is no application bug, as the problem doesn't happen in Ink
itself. It is
Follow-up Comment #4, bug #25040 (project gnustep):
Sorry, for not expressing myself clear enough. I was refering to the list of
platforms supported by libffi:
http://sources.redhat.com/libffi/
I don't think that we have anybody in GNUstep that supports specific
platforms. It is more that we
Follow-up Comment #1, bug #25005 (project gnustep):
The problem here is that we don't use TranslateMessage() in the message loop,
that way we only get the raw key up and down events, not that translated char
events. But if we change to that we have no way of handling non-character key
events
Update of bug #25046 (project gnustep):
Category:None = Backend
Item Group:None = Bug
Status:None = Need Info
Assigned to:
Update of bug #24981 (project gnustep):
Category:None = Backend
Status:None = Works For Me
Open/Closed:Open = Closed
Update of bug #24994 (project gnustep):
Category:None = Makefiles
Item Group:None = Change Request
___
Follow-up Comment #10:
Even if the
Update of bug #25034 (project gnustep):
Category:None = Application
___
Follow-up Comment #1:
Put this bug down to the application until we know differently.
Update of bug #22373 (project gnustep):
Category:None = Base/Foundation
Item Group:None = Bug
___
Follow-up Comment #3:
Turned this into a
Follow-up Comment #10, bug #24709 (project gnustep):
Perhaps it isn't the image that is off, but the surrounding path is? Could
you please try this with stroke adjustment turned off for the cairo backend?
(Changing line 495 in CairoGState.m to _strokeadjust = 0; should do)
Update of bug #15778 (project gnustep):
Status: Confirmed = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #1, bug #25064 (project gnustep):
Thank you for this bug report.
The art backend is still the default backend for GNUstep on X, therfore it
will get used even when cairo is available.
The bug you got with FTFontInfo is rather unusual, we will need more
information to track it
Update of bug #24872 (project gnustep):
Status: In Progress = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #11:
Closed as the
Follow-up Comment #1, bug #25079 (project gnustep):
I don't think that this is the cause of your problem. When NSUserDefaults
outputs this warning it will just keep on working.
And if gpbs gets this warning, every other application and tool should get it
as well.
Could it be that you have more
Follow-up Comment #3, bug #25064 (project gnustep):
As for the cairo problem you see (black bar), this is caused by an old cairo
bug that GNUstep had to work around. After cairo fixed that problem in 1.6.0 I
adopted GNUstep back to that but this correction was itself corrected
immediately after
Update of bug #25037 (project gnustep):
Status: In Progress = Duplicate
Depends on: = bugs #25033
___
Follow-up Comment #9:
Marked this bug
Update of bug #19097 (project gnustep):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?19097
___
Follow-up Comment #6, bug #25064 (project gnustep):
I looked through your configuration and make files and cannot see any problem
there. Sorry, but now I am totally clueless.
No idea, where this problem might come from.
___
Reply to this
Update of bug #25040 (project gnustep):
Status:None = Duplicate
Depends on: = bugs #25033
___
Follow-up Comment #6:
Most likely this is
Update of bug #25104 (project gnustep):
Category: Gui/AppKit = Application
___
Follow-up Comment #1:
I think this bug report is invalid. By setting a break point in TilesBox
drawRect: I can
Update of bug #25105 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
To make the
Update of bug #25105 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
After that change
Update of bug #24923 (project gnustep):
Severity: 4 - Important = 3 - Normal
___
Follow-up Comment #3:
You wrote that this fails on Windows, could you please provide the icon file
that causes this,
Update of bug #25116 (project gnustep):
Summary: NSDocument should handle loading of known
types = NSDocument should not ignore readFromFileWrapper:ofType:error:
___
Follow-up Comment #1:
The original topic of the
Update of bug #25116 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
I looked through the documentation and our code to see how we should proceed
here. The main
Update of bug #25162 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
This is an interesting bug report, as I am currently working on this class.
It is clear that
Update of bug #24994 (project gnustep):
Status:None = Fixed
Assigned to:None = nico
Open/Closed:Open = Closed
501 - 600 of 1310 matches
Mail list logo
