Update of bug #28464 (project gnustep):
Status: Ready For Test = Need Info
Open/Closed: In Test = Open
___
Follow-up Comment #3:
Now I will need
Update of bug #28464 (project gnustep):
Status: Need Info = In Progress
___
Follow-up Comment #5:
With your eyample I could reproduce the problem and solve the issue of the
disappearing images.
Update of bug #28464 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #6:
I finally found the
Update of bug #28552 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #28056 (project gnustep):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #1, bug #28590 (project gnustep):
Does this happen only for images or for paths as well? The difference is that
for images we do a conversion ourselves and this could of course be wrong. If
it happens for paths as well, it is more likely a cairo issue. Or just a
different
Follow-up Comment #6, bug #28590 (project gnustep):
Thank you for your analysis. This really seems to be the cause of the
problem.
You patch is a complete hack and cannot be applied :-)
It would break all cases where we use shared memory in XWindowBuffer. But it
clearly points in the right
Update of bug #28647 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #28647 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #28114 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28114
___
Update of bug #27631 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #11946 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
This has finally
Follow-up Comment #8, bug #28590 (project gnustep):
Looks like I didn't express myself clear enough. Sorry for that.
What I tried to say was that we should put any patch into the file
XWindowBuffer.m. And we only need to change any code in the case where we
don't use shared memory (this is for
Follow-up Comment #10, bug #28590 (project gnustep):
Thank you for the explanation, this new patch of yours sounds like the right
way to solve the issue. Feel free to go ahead.
And you are also right about xlib not using this class at all.
Update of bug #28590 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #28714 (project gnustep):
Item Group: Bug = Change Request
___
Follow-up Comment #1:
Yes, this is true, but this has been that way all the time and was never
intended to be
Update of bug #28632 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #28465 (project gnustep):
Status:None = Duplicate
Open/Closed:Open = Closed
Depends on: = bugs #26438
Update of bug #27620 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #4:
Closed as this
Update of bug #27063 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #4:
I could no longer
Update of bug #26339 (project gnustep):
Status: Confirmed = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #6:
The original author
Follow-up Comment #2, bug #28307 (project gnustep):
You could try to comment out the #include for GSPrivate.h in GSCategory.m, we
never should have included this file and removing the #include will show what
it was needed for. Then this can be defined elsewhere.
Of course, this change wont help
Am 01.02.2010 16:03, schrieb doc0.delp...@voila.fr:
Please find enclosed a zip file containing log files showing that I failed to
build the GNUStep base package under Mac OS X (Snow Leopard - 10.6).
I look forward to hearing from you soon.
Hoping you a good receipt.
Yours sincerely,
Not
Update of bug #15893 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #2:
Fixed by Wolfgang
Follow-up Comment #4, bug #28939 (project gnustep):
Actually I am getting a segmentation fault from this code as well.
I am not able to get a proper back trace for this from gdb.
What I noticed is that in getCString_c we hid this condition
if (externalEncoding != internalEncoding)
(gdb) p
Am 05.03.2010 11:33, schrieb Chia-Yuan Chuang:
I cannot install GNUStep GUI and GNUstep Back. My OS is Ubuntu 9.10. I have
also attached my log. Please tell me what to do
There is something a bit strange in your log files. The checks in
installgnustep.log suggest that the GNUstep installation
Thank you for this patch! I already applied it.
The only way I can explain the current code here is that I tried my best
to work around all the compiler warnings about mismatched types and that
somehow left the extra operator.
Fred
Am 13.03.2010 00:52, schrieb Anibal Rindisbacher:
Hi everyone,
Update of bug #25243 (project gnustep):
Item Group:None = Bug
Status:None = Fixed
Open/Closed:Open = Closed
Update of bug #29013 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #1, bug #29525 (project gnustep):
I think this is caused by us adding the program name to the arguments string.
According to the specification
http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx it sounds
like we either have to leave out the application name
Follow-up Comment #15, bug #27782 (project gnustep):
I like the idea of removing all those isFlipped checks in gui. I always
suspected that they were only compensating for one-another. But then you had
to add one yourself for the NSView -scrollRect:by: method. The rest of the
patch on this
Follow-up Comment #1, bug #26438 (project gnustep):
I tired to figure out how our interaction with Window Maker works and failed
to understand it. How will Window Maker know that we don't provide our own
icons? The flag UseWindowMakerIcons is only used internally, I don't see a way
to tell this
Update of bug #29369 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #2:
Change state to in test.
___
Reply to
Update of bug #29191 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #3:
Change state to in test.
___
Reply to
Update of bug #28900 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #3:
Change state to in test.
___
Reply to
Follow-up Comment #1, bug #29635 (project gnustep):
The aim of this patch looks correct to me. But could you first check what
will be the default modifier mask of a menu item on Cocoa? If this isn't
NSCommandKeyModifierMask, then we should fix this whole issue on a different
level.
In that case
Follow-up Comment #3, bug #29635 (project gnustep):
Sure, go ahead.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29635
___
Nachricht geschickt von/durch Savannah
Update of bug #29633 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
I tried this myself
URL:
http://savannah.gnu.org/bugs/?29718
Summary: Gorm: Segmenation fault after loading NIB file
Project: GNUstep
Submitted by: FredKiefer
Submitted on: Do 29 Apr 2010 20:45:59 GMT
Category: Gorm
Follow-up Comment #2, bug #29633 (project gnustep):
I investigated further and it turns out that I was completely wrong with my
last post. The extra space character is introduced by the writer not the
reader. What the reader does is put this space in front of the image, it got
inserted by the
Update of bug #29633 (project gnustep):
Status: Confirmed = Ready For Test
Assigned to: FredKiefer = None
Open/Closed:Open = In Test
Follow-up Comment #6, bug #29633 (project gnustep):
Committed my RTFProducer changes to resolve this last remaining issue. Could
everybody please check that the generated RTF is at least as usable as before?
___
Reply to this item at:
Update of bug #29706 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #1:
This isn't a GUI issue, rather one of the backend or even of the theme.
Update of bug #28690 (project gnustep):
Category: Gui/AppKit = Backend
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28690
___
Update of bug #28714 (project gnustep):
Category: Gui/AppKit = Backend
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28714
___
Update of bug #29633 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #9:
Thank you for
Update of bug #26900 (project gnustep):
Status: In Progress = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #1:
I think we should
Update of bug #29736 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #1:
I just added the missing NSString method you reported (plus a few similar
ones as well).
I
Update of bug #29755 (project gnustep):
Category: Application = Base/Foundation
Severity: 3 - Normal = 4 - Important
___
Follow-up Comment #1:
Thank you for this
Follow-up Comment #1, bug #29784 (project gnustep):
Could you please explain a bit more in detail which differences you are
referring to? Is it that GNUstep currently doesn't support the keys you are
using? We already support a lot of synonyms here and it wont be hard to add
the current Apple
Follow-up Comment #3, bug #29755 (project gnustep):
I think what you did was a great work around, that removes the obvious
security leak. I wouldn't call this a full fix of the problem as it is still
possible to access information the user isn't allowed to access. She can no
longer view this
Follow-up Comment #2, bug #29718 (project gnustep):
As I wrote in a private mail, I was able to reproduce this issue by loading
the busybox example NIB file from the gormtest project. The files there look
as if they where written on a Mac system, at least the plist doc type points
to Apple.
Follow-up Comment #4, bug #29718 (project gnustep):
I am using a 64 Linux system myself (see bug report below), so this isn't the
difference. Today I had load the busybox.nib files five times to get the
issue. Be sure to have the inspector visible and click on the loaded window
once. This seems
Update of bug #29707 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29707
___
Update of bug #29780 (project gnustep):
Category:None = Gorm
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29780
___
Update of bug #29847 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29847
___
Update of bug #29848 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29848
___
Follow-up Comment #17, bug #27782 (project gnustep):
Now that the release is out, feel free to commit an updated version of this
patch. We will all start to test it and point out any issues :-)
___
Reply to this item at:
Update of bug #25134 (project gnustep):
Category:None = Application
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25134
___
Update of bug #29782 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29782
___
Update of bug #29850 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29850
___
Update of bug #29301 (project gnustep):
Category:None = Libraries
Status:None = Need Info
___
Follow-up Comment #4:
Compiling the
Update of bug #28862 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #29708 (project gnustep):
Category:None = Libraries
___
Follow-up Comment #1:
Moved this bug into the category Libraries, as it works for the standard
theme.
Update of bug #29781 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29781
___
Follow-up Comment #1, bug #29871 (project gnustep):
I just added code to SVN that handles the resizing of the toolbar a lot
better. What we do not is when there isn't any flexible space in the toolbar,
then all the items will be scaled up to there maximum size. (This only works
for items backed
Update of bug #29871 (project gnustep):
Item Group:None = Change Request
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
Update of bug #29899 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
What version of Cocoa are you referring to? For 10.5 Apple has documented the
following:
Note:
Update of bug #29899 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #3:
Should be fixed in
Update of bug #29899 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Great to hear that
Update of bug #29871 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #28632 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #25659 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Closed after not
Update of bug #26339 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #7:
The basic issue is
Update of bug #29892 (project gnustep):
Item Group:None = Bug
___
Follow-up Comment #1:
I think this used to work (more or less), but it looks like Matt Rice removed
this code in
Update of bug #3 (project gnustep):
Severity: 5 - Blocker = 3 - Normal
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
Update of bug #30537 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #30538 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Could you please
Follow-up Comment #1, bug #30539 (project gnustep):
This is another controversial change. When changing the key mapping here we
also need to adjust the mapping in NSInputManager and make sure that all
applications relying on the current behaviour get corrected as well.
As I understand it, you
Am 26.07.2010 00:59, schrieb Derek Fawcus:
On Sun, Jul 25, 2010 at 08:58:48PM +, Fred Kiefer wrote:
Update of bug #30538 (project gnustep):
Status:None = Need Info
Assigned to:None = FredKiefer
equivalents for menu items. These are stored in Gorm
or NIB files and any menu item with a backspace key equivalent may just
no longer work after this change.
Fred
Am 25.07.2010 23:51, schrieb Derek Fawcus:
On Sun, Jul 25, 2010 at 08:58:48PM +, Fred Kiefer wrote:
Update of bug #30538 (project
Update of bug #30439 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #3:
Just changed the
Update of bug #30427 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #4:
Changed state to in
Follow-up Comment #1, bug #30493 (project gnustep):
Sory for taking so long to reply to this item. The whole font issue is
something that would require more attention in GNUstep. And with your change
in place it would seem as if we only ever instantiate flipped fonts. (most
views are flipped or
Update of bug #30069 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #30140 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #30025 (project gnustep):
Status: In Progress = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Am 09.08.2010 06:46, schrieb Mark Houde:
System:
Centos 5.5 (up to date)
Failed here:
This is gnustep-make 2.4.0. Type 'gmake print-gnustep-make-help' for help.
gmake[1]: Entering directory
`/home/mhoude/dev/gnustep-startup-0.25.0/build/gnustep-gui-0.19.0'
Making all in Source ...
Update of bug #30724 (project gnustep):
Status:None = Ready For Test
Assigned to:None = gcasa
Open/Closed:Open = In Test
Update of bug #30025 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #4:
I added calls to synchronizeTitleAndSelectedItem in a few more places. This
should fix the
Update of bug #30766 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
Does this only happen with make_services or are all GNUstep programs
affected? There weren't
Follow-up Comment #6, bug #30172 (project gnustep):
GNUstep is doing the lossy conversion by using the translit flag of iconv.
The documentation for iconv states:
When the string //TRANSLIT is appended to tocode, transliteration is
activated. This means that when a character cannot be
Follow-up Comment #3, bug #30766 (project gnustep):
Not having valgrind is really bad.
The next thing that you could try to do is pin down where the problem comes
from. I think it can only be one of three things, either GNUstep base has some
serious problem (Most likely in NSProcessInfo where we
Follow-up Comment #5, bug #30863 (project gnustep):
Now I understand the problem. Somebody is starting a new thread here and in
the called function relies on an autorelease pool, but there wont be any
available.
We could now either remove the need for an autorelease pool or add one in
this
Update of bug #30766 (project gnustep):
Status:None = Ready For Test
Assigned to: FredKiefer = CaS
Open/Closed:Open = In Test
Hi Georg,
thank you for this patch. It surely is correct and I will add it. But as
you already pointed out there may be a deeper problem here.
I think that we should always clean up the gstate when the window for a
view changes, that is in the method _viewWillMoveToWindow:. Something like:
if
I just committed all four of your patches.
Thank you
Fred
Am 05.09.2010 10:23, schrieb Georg Fleischmann:
Hi,
I am working on getting my applications running with the latest SVN version
of GDL2. It seems that GDL2 is always locking everything now (that was
different in 0.12.0).
The
in Cenon.
It will crash, if there is a _gstate but _window has no graphicsContext,
which seems to be possible here.
If I add an additional test for [_window graphicsContext != nil, then I don't
get any problems.
Georg
On 11.09.2010, at 20:17, Fred Kiefer wrote:
Hi Georg,
thank you
just keep the _allocate_gstate alive.
As the Cenon graphics code runs perfectly on OpenStep 4.2 and Apple, I would
say, the _allocate_gstate flag should be transferred with the view to the new
window.
Best wishes,
Georg
On 15.09.2010, at 16:22, Fred Kiefer wrote:
Should be in SVN now
Update of bug #31237 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
801 - 900 of 1310 matches
Mail list logo
