Update of bug #25236 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #3:
The change that the window is no longer resized when a toolbar is added was
done on purpose. I
Update of bug #25236 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #6:
I changed the code in GSWindowDecorationView back to resize the window.
(Keeping the top of the
Follow-up Comment #8, bug #25236 (project gnustep):
You did beat me by quarter of an hour, I just did the same test (with the
same problem) and wanted to report them :-(
I also checked the new code in SVN on KDE and it almost behave the same
(apart from some very, very strange window movements
Update of bug #25116 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #3:
The code for all
Update of bug #25243 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
Looks liek this bug is rather similar to #25064. And for that bug I already
failed to find out
Update of bug #25236 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #10:
I close this bug
URL:
http://savannah.gnu.org/bugs/?25266
Summary: NSNibOutletConnector not freed after loading a NIB
file
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Mi 07 Jan 2009 18:10:14 GMT
Category: Gui/AppKit
Update of bug #25266 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Greg,
I think your
Update of bug #25266 (project gnustep):
Assigned to:None = gcasa
___
Follow-up Comment #1:
Finding the root cause was easy, the following line in GSNibLoading.m was
leaking the copied
Update of bug #24886 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Are you sure this
Follow-up Comment #3, bug #25266 (project gnustep):
With re-work I just meant that my current bug fixing approach to the problem
may not be sufficient, but perhaps I just gave up one patch too early?
You see, I am very sure that both my patches are correct, but currently
things get worse when
Update of bug #24601 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #7:
I think that the
Update of bug #24709 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #13:
I played with the line:
y = floorf(aPoint.y);
at CairoGState.m:1280 and replacing it with
Update of bug #25286 (project gnustep):
Privacy: Any = Public
___
Follow-up Comment #1:
Could you please provide a sample NIB file or even better a sample
application to show this
URL:
http://savannah.gnu.org/bugs/?25327
Summary: NSAnimation no longer works
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Do 15 Jan 2009 09:49:45 GMT
Category: Base/Foundation
Severity: 3 -
Follow-up Comment #4, bug #25243 (project gnustep):
Looks like you only have the default font for the art backend installed
(Helvetica). Perhaps we should advertise better that there are additional
fonts available as a separate package.
Did you again get a segmentation fault?
Follow-up Comment #4, bug #25327 (project gnustep):
Great, I would even say better then ever before.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25327
___
Nachricht geschickt
Update of bug #25346 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #1:
I rsolved the first retain cycle and cleaned up the code in GSAnimator a bit.
There still might
Follow-up Comment #6, bug #25243 (project gnustep):
Could you please add the back trace for the new segmentation fault as well?
It might just be the same as before, but how should I know...
___
Reply to this item at:
Update of bug #25343 (project gnustep):
Status:None = Works For Me
___
Follow-up Comment #3:
Same here, I also recompiled all of GNUstep on MS Windows today and it
worked.
What I noticed
Follow-up Comment #2, bug #25346 (project gnustep):
More information by Benhur Stein:
Thanks.
It was more than a year ago, I do not recall exactly, but it had somthing to
do with the way the animator used timers, there was a retain cycle in there
too, but the nsanimator code was too complicated
Follow-up Comment #2, bug #25356 (project gnustep):
I get the same behaviour with todays SVN code. The only thing that looks
strange in the ./configure output is that all sub-invocations have the
parameter --prefix=/GNUstep/Local.
___
Pedro Alves wrote:
I am getting this error when I am running GNUstep application on FreeBSD
7.0, and Xorg 7.3. The error is recurrent since many updates of the
system.
GNUstep applications run, but do not present any characters in the menus
or in the windows related to the aplications.
Update of bug #25411 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
As far as I know
Follow-up Comment #3, bug #25411 (project gnustep):
Hmm, this is a possible interpretation of the required behaviour. Could
anybody please test this on Apple to see what they are doing?
I found that Apple seems to disregard that mask when doing a drop, so I am
not sure what they are doing with
Follow-up Comment #2, bug #25397 (project gnustep):
Could you please explain once more what you are suggesting?
Should we just set the NSAlternateKeyMask on Windows when we get an AltGr
key? (Treating AltGr as Alt-R) Aren't we loosing informations about modifiers
that way?
Another problem with
Update of bug #25346 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #4:
Changed this to
Update of bug #25046 (project gnustep):
Status: Need Info = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
Change the bug
Update of bug #24709 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #14:
I added my
Update of bug #24083 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #16:
Changed the state
Follow-up Comment #9, bug #25243 (project gnustep):
The new back trace is about the same as the old one, but this
time the frames on the stack aren't corrupted.
I really don't understand what is going on. Just a few lines before this
segmentation fault we are testing the value of face and at
Follow-up Comment #11, bug #25243 (project gnustep):
Now getting the backtrace is the hard bit and you managed that already :-)
To get gdb to print out the value of a locally visible variable you just type
p and the name of that variable. In your case
p face
If you want to print the value of
Update of bug #25395 (project gnustep):
Severity: 3 - Normal = 1 - Wish
Item Group: Bug = Change Request
___
Follow-up Comment #4:
Made this report a
Update of bug #25448 (project gnustep):
Status: Need Info = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #5, bug #25397 (project gnustep):
Sorry, I forgot that I cannot test it on that virtual machine, an Apple
keyboard just doesn't have an AltGr key :-(
As soon as compilation on Windows works again for me, I will hack that code
in and somebody else needs to test it.
Update of bug #25472 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
With which
Matt Rice wrote:
so to me it looks like you should be getting that log output, not sure
what to say beyond that, but if you could check the windows event
viewer (not sure how to get there) just to make sure there isn't
anything useful in it. :/
Not sure what you are discussing about, I just
Update of bug #25472 (project gnustep):
Status: Need Info = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #5:
So we have reached
Follow-up Comment #1, bug #25484 (project gnustep):
On GNUstep an NSImageView is a dragging source as soon as it is editable. By
default objects of that class are editable. This results in NSImageView being
a dragging source by default.
Now which of the two assumptions we make is different from
Follow-up Comment #6, bug #25356 (project gnustep):
The problem with applications was due to base not getting compiled correctly.
And this was caused by pathconfig. For some reason this seems to ignore the
settings in the installation domain file instead it guesses the domain as
Local and then
URL:
http://savannah.gnu.org/bugs/?25505
Summary: cairo backend scrolling broken with recent cairo
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Fr 06 Feb 2009 10:18:52 GMT
Category: Backend
Follow-up Comment #1, bug #25505 (project gnustep):
I just found another potential cause of this problem. My X server doesn't
support shared memory pixmaps.
GNUstep reports:
XShm pixmaps not supported by X server.
Could it be that scrolling in our cairo backend never worked without XShm
Follow-up Comment #10, bug #25343 (project gnustep):
Did you update GNUstep from SVN and rebuild make?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25343
___
Nachricht
Matt Rice wrote:
using the CopyFromParent can lead to BadMatch if the parent window's
depth isn't supported by the visual provided.
Thank you, works great! I commit your patch.
Fred
___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
Follow-up Comment #1, bug #25528 (project gnustep):
Could you please be a bit more specific. On which platform is this happening
and which backend are you using?
Does this problem go away when you disable the new image proxy code?
Why do you think it is an application bug, if so which
Matt Rice wrote:
using class as a variable name doesn't fly in headers when using objc++.
(sorry, at the moment all i've got is an anonymous checkout).
Done.
___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
Follow-up Comment #8, bug #25397 (project gnustep):
Just to make it clear. Riccardo is suggesting to ignore any AltGr+LeftControl
(and RightALt+LeftControl) combination and treat that as Alt.
___
Reply to this item at:
Follow-up Comment #1, bug #25534 (project gnustep):
I noticed the negative view size in your output. I don't get that when
starting up ProjectCenter. Did you do anything special or is this already
reported when the menu gets shown?
It could well be that your problem is less due to the remote
Follow-up Comment #6, bug #25534 (project gnustep):
My problem with missing SHM support seems to be completely unrelated to yours
(it is just a drawing glitch with cairo).
The setting for window decoration is GSBackHandlesWindowDecorations. You
should also try to switch off GSFontAntiAlias, I
Looks like you are creating an OpenGL context and a view without a
corresponding window. This wont work in GNUstep (it might on MacOSX, I
don't know) and it would be useless anyway, as you wont be able to see
anything in that view.
You better start off by copying one of the OpenGL example
Follow-up Comment #3, bug #25505 (project gnustep):
Thank you for testimng this! The way I noticed the difference was by starting
up that memory debugging panel (open the About panel and click on the icon
there) and scrolling in that.
If it isn't the SHM setting then it has to do with the cairo
Follow-up Comment #1, bug #25572 (project gnustep):
GNUstep really should be doing more copying when setting or returning
instance variables. This is out of question. Your specific solution may not
the the most efficient one. I will probably replace
return [NSString
Ulrich Engelmann wrote:
I tried to use GNUstep. During installation ( .. Building GNUstep Base ..)
an error arised. Therefore the log-file.
Looks like your sparc system neither has ffi nor ffcall installed. One
of these (ffi being prefered) is needed to support invocations in
GNUstep. You
Follow-up Comment #1, bug #25592 (project gnustep):
Does the setting of the window decoration influence the problem? The code
that computes the sub-window rectangle looks wrong to me both here and in
x11.
The change at revision 26243 was mostly about setting the correct window
style and
Follow-up Comment #3, bug #25552 (project gnustep):
This sounds exactly like the behaviour on Windows. Could there be a common
source?
Now that I looked at the output you get, I can see a difference.
___
Reply to this item at:
Follow-up Comment #10, bug #25534 (project gnustep):
Somehow you ended up with negative coordinates in your settings. Of course
this cannot work. If you have a reproducable way of getting that error, we
could try to avoid it.
The idea of saving the resolution in the defaults file is to adjust
Follow-up Comment #5, bug #25505 (project gnustep):
And what is your cairo release? Maybe I just need to change that.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25505
___
Ricardo Strausz wrote:
error 2 (from macports):
Fermat:~ sa$ sudo port -v install gnustep-gui
--- Building gnustep-gui
Error: Target org.macports.build returned: shell command cd
Follow-up Comment #7, bug #25505 (project gnustep):
My nvidia driver is version 180.22 and my cairo 1.8.0. This could be enought
to explain the difference. Or it may even be the X server (Suse 11.1 comes
with 7.4).
At least we can now rule out the missing SHM as the only reason for my
problem.
Update of bug #25603 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #25528 (project gnustep):
Status: Need Info = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #16:
I close this bug
Update of bug #24923 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #4:
Still waiting for
Update of bug #7900 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #4:
I think the last
Update of bug #25484 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #1, bug #25612 (project gnustep):
That's an interesting problem. How could the selected cell be set without the
two seletion indexes pointing at the same cell?
I went through all code that sets the ivar _selectedCell and I would say that
all of them are correct, whenever we
Julien Isorce wrote:
Hi,
I can read in NSApplication's documentation that it must be called in
the main thread.
I am in a case where there is an other main loop (in C) that I cannot
managed.
The code I can access is an interface and its implementation that leads
to a shared library
Follow-up Comment #3, bug #25612 (project gnustep):
Your change highlights the similarities between the code in the two methods
_selectCell:atRow:column: and setState:atRow:column:. These methods surely
should share more code as in some cases they do almost the same thing.
I would say that your
Update of bug #25620 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #25612 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #4, bug #25643 (project gnustep):
I think the change that Matt pointed to is really the cause of the problem.
Looks like Richard made that change in responce to some change by Greg. And I
have problems understanding that first change.
To me it looks like we are restricting
Update of bug #11946 (project gnustep):
Status: In Progress = Ready For Test
Assigned to: qmathe = FredKiefer
Open/Closed:Open = In Test
Update of bug #22323 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
I tried your test code and it turns out that it isn't the call to
setAlignment: that changes
Update of bug #25659 (project gnustep):
Category: Gui/AppKit = Backend
Item Group:None = Bug
Status:None = Confirmed
Update of bug #25659 (project gnustep):
Status: Confirmed = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #25625 (project gnustep):
Severity: 4 - Important = 3 - Normal
Status:None = Need Info
___
Follow-up Comment #1:
I just tried with
Follow-up Comment #3, bug #25625 (project gnustep):
Sorry, perhaps I wasn't explicit enough in my last posting. I know about the
problem when the popup is to big to fit on the screeen and I also know the
issue when the popup gets moved when bringing it on screen. What I wanted to
see in an
Follow-up Comment #1, bug #25740 (project gnustep):
I was able to reproduce the described behaviour one time, but after that it
worked perfectly for me. Could it be that this is somehow releated to the
gpbs? That application is already causing some delays when starting drag and
drop or selection
Update of bug #25698 (project gnustep):
Status:None = Need Info
___
Follow-up Comment #2:
You promised to send that test application :-)
URL:
http://savannah.gnu.org/bugs/?25793
Summary: [NSImage imageNamed: @GNUstep] broken
Project: GNUstep
Submitted by: FredKiefer
Submitted on: So 08 Mär 2009 21:16:38 GMT
Category: Gui/AppKit
Severity: 3
Follow-up Comment #1, bug #25793 (project gnustep):
Looks like I was wrong in claiming that the theme changes is responcible for
this problem. In a very simple case the code would work without the theme
proxy, but more compilcated cases will face teh issue that any image may only
have one name.
Update of bug #25793 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #25870 (project gnustep):
Item Group:None = Bug
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:
Follow-up Comment #1, bug #25943 (project gnustep):
Your great debugging session shows quite clear where the problem is. It is
the call to [NSGraphicsContext saveGraphicsState], as this happens on a
secondary thread there is no previous graphics context (GSCurrentContext()
return nil).
Update of bug #25943 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #25943 (project gnustep):
Status: Ready For Test = In Progress
Open/Closed: In Test = Open
___
Follow-up Comment #4:
It would be better
Follow-up Comment #5, bug #25943 (project gnustep):
I fixed that memory issue with XWindowBuffer, please give it another try and
if it still fails, use the tips I provided to pin down the cause.
___
Reply to this item at:
Update of bug #25979 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Update of bug #25909 (project gnustep):
Status: Need Info = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Closed as requested
Update of bug #25534 (project gnustep):
Category:None = Backend
___
Follow-up Comment #13:
To me this looks like you get the wrong window border computation when
working on the remote
Follow-up Comment #3, bug #26046 (project gnustep):
I tried to reproduce this problem, but failed long before getting there. When
I compile gormtest I get the following warnings:
Warning: English.lproj/urltest.gorm not found - ignoring
Warning: English.lproj/testmatrix.nib not found - ignoring
Update of bug #26101 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Reported as being
Update of bug #24709 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #25162 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #25116 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #4:
Closed as the
Update of bug #26233 (project gnustep):
Item Group:None = Change Request
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:
Follow-up Comment #4, bug #26233 (project gnustep):
https://savannah.gnu.org/patch/?group=gnustep
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26233
___
Nachricht geschickt
Update of bug #26339 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Which versions of
Follow-up Comment #1, bug #26414 (project gnustep):
I just searched for this error message and I cannot find it anywhere in the
GNustep source code. (Am I looking in the wrong places?)
Perhaps it would help, if you run the same progam on a Unix system first and
investigate the issue there? That
Update of bug #26414 (project gnustep):
Category: Base/Foundation = Gui/AppKit
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26414
___
Update of bug #26414 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
601 - 700 of 1310 matches
Mail list logo
