Follow-up Comment #6, bug #25943 (project gnustep):
Doug,
could you please comment whether this bug report is still open? If I wont
here from you I will close it again.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25943
Follow-up Comment #12, bug #25505 (project gnustep):
It feels great to no longer be alone with this problem :-)
As we are all using completely different environments and have different
hardware I suspect that cairo = 1.8.0 is the common point that causes the
problem. Is anybody using such a
Update of bug #24083 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
david hill wrote:
After ensuring all required modules were present (except fficall which I
was instructed would be loaded during the installation process) I
attempted installation -- having su'd to root -- but after seemingly
come near completion, the installation failed, and instructed me to
Update of bug #26535 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Hi Scott,
this is
Update of bug #26717 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #26766 (project gnustep):
Status:None = Need Info
___
Follow-up Comment #1:
We will need a bit more information than this to resolve the issue. There is
no sign that the
Update of bug #26766 (project gnustep):
Category: Gui/AppKit = Base/Foundation
Status: Need Info = None
Summary: Segfault when falling back to Ximage =
Segfault when connecting to
Update of bug #26080 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #25943 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
Closed as there was
Update of bug #14866 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
Adam, I changed the
Update of bug #25363 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Closed as there was
Hi Andy,
thank you for the bug report and the analysis you did yourself. In
general it really helps to have the source code and of course the NIB
files to dig into such a problem.
The decoding code for NSUserDefaultsController is rather simple:
- (id) initWithCoder: (NSCoder *)aDecoder
{
if
seem to be read-only; if there is data in the model
objects, it is displayed, but any changes I make in the text fields are
not reflected in the model.
Here's a sample data file too:
Andy Balholm
(509) 276-9718
a...@balholm.com
On Jun 18, 2009, at 12:37 PM, Fred Kiefer wrote
0xb7c99dcd in NSApplicationMain (argc=1, argv=0xbfffe044) at
Functions.m:74
#8 0x0804ac12 in main (argc=Cannot access memory at address 0x170001
) at main.m:13
Fred Kiefer wrote:
On my system the segmenation fault happens a bit earlier. I get it when
closing the company window.
Program
With your preparation the rest was easy, as you suggested it was a
problem in the initWithCoder: method of NSUserDefaultsController. I had
forgotten to retain the shared object before returning it from this method.
Thank you once more for your great bug report.
Fred
Fred Kiefer wrote:
After
Hu, Lehong wrote:
Hi,
I tried to install GNUstep in a mac os x10.5/i386 Darwin 9.7. I followed
steps in the file README.Darwin
(http://www.gnustep.org/resources/documentation/User/GNUstep/README.Darwin).
I have got errors as the following when make GNUStep-GUI-0.16.0:
Andy Balholm wrote:
The bindings in my Company Info window are supposed to be read-write,
but they can only read the data from the model. Changes to the text in
the fields do not change the model. I tried taking the bindings out of
the NIB and binding the fields programmatically instead, and
Update of bug #26895 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
I don't think that scattering a fee RETAINs in the code will resolve the
underlying problem.
The process of building up the text network is rather complicated and
the new code in initWithCoder: definitely breaks the previous code
structure. There are a few places in that class, where comments try
Update of bug #26949 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Thank you for this
Update of bug #26950 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Committed. Thank
Update of bug #26950 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
I added a hopefully
Update of bug #26958 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #26949 (project gnustep):
Status: Confirmed = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #4:
I think I found the
Follow-up Comment #5, bug #26950 (project gnustep):
Based on you feedback on bug #26949 I changed the code here once more. Please
give it another try, tabbing into a different view should work again now.
___
Reply to this item at:
Update of bug #24859 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24859
___
Update of bug #25999 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #26414 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #26717 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26717
___
Update of bug #26949 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #6:
Thank you once more
Update of bug #25505 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #14:
Thank you! This really helps, maybe it isn't cairo that is broken but the way
we compute the
Update of bug #25505 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #15:
After this great
Georg Fleischmann schrieb:
here is a small fix for printing of more than the first page. A MIN
needs to be turned into a MAX.
Best Wishes,
Georg Fleischmann
*** Source/NSPrintOperation.m.old2009-03-13 14:31:29.0 +0800
--- Source/NSPrintOperation.m2009-07-14
Update of bug #27030 (project gnustep):
Status:None = Works For Me
Open/Closed:Open = Declined
___
Follow-up Comment #1:
I just tried on my
Update of bug #26973 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #27040 (project gnustep):
Item Group:None = Bug
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
Update of bug #25505 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #25620 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #25346 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Time is up :-)
Update of bug #25046 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Closed as there
URL:
http://savannah.gnu.org/bugs/?27063
Summary: Segmentation fault loading page in SWKBrowser
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Mo 20 Jul 2009 22:09:16 GMT
Category: Gui/AppKit
Update of bug #27063 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #1, bug #27099 (project gnustep):
Yes, this method plus a few others are not properly implemented for font
descriptors. Doing this correctly will require a bunch of changes in the back
end as well.
There is a proper mapping from the font descriptor to the concept of a font
Follow-up Comment #1, bug #27101 (project gnustep):
The name of the method you are referring to is fileName, not filePath.
And before we correct this, could you please confirm what the actual
behaviour on Cocoa is? Quite often the documented behaviour doesn't match the
implemented one.
Follow-up Comment #2, bug #26339 (project gnustep):
There hasn't been any reply to my questions. If this continues I will have to
close this bug as invalid.
We can only resolve bugs for which we have sufficient information otherwise
we end up chasing after application problems that aren't
Update of bug #27101 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #3:
I applied you patch
Follow-up Comment #4, bug #26339 (project gnustep):
Thank you for the reply, now I can see the problem even without looking at
your code.
The code in [GSToolbarView _takeInAccountFlexibleSpaces] only checks for the
GNUstep private Method _isFlexibleSpace, instead it should sum up the minimum
One problem here could be that you use an NSNumber. This should worl but
currently we are using a horrible conversion here. We convert the
NSNumber into an NSDecimalNumber via an NSString and then use
NSDecimalNumber for the formating. I wouldn't be too surprised to learn
that this conversion is
Update of bug #26339 (project gnustep):
Status: Need Info = Confirmed
___
Follow-up Comment #5:
I rearranged some of the code for NSToolbarItem, at least now your own item
will try to rescale
Follow-up Comment #1, bug #27233 (project gnustep):
I am not sure that I understand this problem correctly, but looking at your
code I notice that you are setting self as the result of the invocation even
in the case where a boolean result is expected.
From my point of view this rather looks
Update of bug #24923 (project gnustep):
Status: Need Info = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #6:
I just added a fix
Update of bug #25908 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #1:
Made this a backend bug, as it only happens on Windows.
Update of bug #25907 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #1:
Made this a backend bug as it only happens on Windows.
Update of bug #25843 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #1:
This definitely is a backend bug, if one at all.
Follow-up Comment #3, bug #18838 (project gnustep):
Is this problem still present after the NSToolbar reimplementation?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18838
___
Update of bug #26109 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Closed as Greg marked it as fixed.
___
Follow-up Comment #2, bug #27099 (project gnustep):
I just added a better support for font descriptors to GNUstep in SVN. Could
you please give this a try?
I also looked at the code of Emacs to see, which parts of font descriptors
actually get used there and noticed that it doesn't rely on the
Update of bug #27311 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Follow-up Comment #1, bug #27309 (project gnustep):
This could be resolved by not calling activateIgnoringOtherApps: in
[NSApplication finishLaunching] when the parameter autolaunch is given. We
probably should think a bit more about the pre-conditions, though.
Update of bug #27099 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
___
Reply to this item at:
Follow-up Comment #3, bug #27309 (project gnustep):
Hmm, this sounds to me as if we just should only call
activateIgnoringOtherApps: in finishLaunching when the application isn't
hidden. What we also need to take care of is to create the application with
_app_is_hidden set to NO for this to
Update of bug #27613 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
I tried to
Update of bug #27613 (project gnustep):
Status: Confirmed = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
I just submitted a
Follow-up Comment #2, bug #27635 (project gnustep):
I made the GSStandardWindowDecorationView react to theme changes, it should
now redraw itself. I also moved the whole drawing code over to GSTheme to make
it easier to write different drawing code. And removed the caching of the
title
Follow-up Comment #10, bug #25356 (project gnustep):
Sorry, not at the moment. Since NSLock was changed to require pthreads I am
unable to work with GNUstep on Windows. I know that David send a link to the
pthread code for Windows, but I haven't figured out, which bits I need and
where to put
Update of bug #27613 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Follow-up Comment #4, bug #27635 (project gnustep):
I had forgotten to remove the connection to the notification centre in the
dealloc method. Just added this, please give it another try.
___
Reply to this item at:
Update of bug #27631 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #27636 (project gnustep):
Category: Backend = Gui/AppKit
___
Follow-up Comment #1:
A screen shot really would help. I tried to reproduce this behaviour with
Ink, but could not
Follow-up Comment #2, bug #27636 (project gnustep):
One more question: Which backend are you using? Riccardo has reported a small
offset between art and other backends. I still haven't found time to look into
that.
If your problem goes away when switching to cairo, then it is most likely
that
Update of bug #27635 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #27637 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #2, bug #27638 (project gnustep):
I changed the code so that it no longer tracks the knob after the initial
move. What we still don't do is keep on moving in the same direction until the
mouse goes up.
___
Reply to this
Update of bug #27635 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #27637 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #26843 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26843
___
Update of bug #27101 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #24923 (project gnustep):
Status: Ready For Test = In Progress
Open/Closed: In Test = Open
___
Reply to this item at:
Update of bug #24707 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Follow-up Comment #1, bug #2 (project gnustep):
Is it possible that you are using the new UX Theme for Windows that Riccardo
just published? In that theme the plist defines that the window decoration
should be drawn by Windows and not GNUstep. Try switching to the default
theme, restart your
Follow-up Comment #1, bug #27782 (project gnustep):
Hi Quentin,
first to your test code. It shows agaon your old point that we handle the
flipped attribute differently from Cocoa. It should be enough to define a
method isFlipped that return YES on both platforms. But currently GNUstep
caches
Follow-up Comment #5, bug #27782 (project gnustep):
I wont have time to look at the patch until next week, but removing the
doublication in the different drawing methods is surely agood thing. I had the
code in place for a long time, but never dared to switch to it.
Could you please check that
Update of patch #3487 (project gnustep):
Status:None = Done
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
After adding
Update of patch #3487 (project gnustep):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/patch/?3487
___
Follow-up Comment #2, bug #27882 (project gnustep):
I am currently not working on my Windows virtual machine, but I hacked donw
the following code based on Microsoft examples and other code in the windows
backend. I don't expect it to work out of the box, but it should provide you
with a
Follow-up Comment #6, bug #27782 (project gnustep):
Find attached the old test application I was talking about.
I also committed the part of your patch that just changed over to the newer
shared composite and dissolve code. This makes the remaining of your patch a
lot smaller.
Follow-up Comment #8, bug #27782 (project gnustep):
One more try in uploading the old test code.
The cairo drawing bug you noticed seems to be unrelated to you change. I
noticed it today myself, when working with Gorm.
What you report back on your test results looks great.
There is one thing
Follow-up Comment #9, bug #27782 (project gnustep):
Looks like the file was to big. I repackaged it and hopefully it is now small
enough.
(file #18980)
___
Additional Item Attachment:
File name: gui_test3.tgz Size:26 KB
Follow-up Comment #3, bug #27927 (project gnustep):
OK, try once more with my recent changes.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27927
___
Nachricht geschickt
Follow-up Comment #5, bug #27636 (project gnustep):
I checked this and the layout is the same for the cairo and the xlib backend.
Next I looked into the NSScroller code and there the difference is even
documented in a comment:
/* We use the button offset if we in the NeXTstep interface style.
Follow-up Comment #1, bug #27337 (project gnustep):
What about the details you promised?
I often get normal windows created behind other KDE windows when starting up
an application, but never when an application is already active. This is
caused by KDE's stupid strategy to not change the active
Update of bug #27620 (project gnustep):
Severity: 5 - Blocker = 2 - Minor
___
Follow-up Comment #3:
I was able to open this image on my Mac with the QuickTime application. This
looks like it is
Update of patch #6839 (project gnustep):
Status:None = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #3, bug #27882 (project gnustep):
Richard, what is the state of this bug report. You added the code below and
improved it a lot. Does it work now?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27882
Update of bug #28114 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #27882 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
I closed this bug
Update of bug #27309 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #28415 (project gnustep):
Status:None = Invalid
Assigned to:None = FredKiefer
Open/Closed:Open = Declined
Update of bug #28464 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
701 - 800 of 1310 matches
Mail list logo
