Stefan Bidigaray wrote:
Not sure if this is my fault or not! I've gotten this quite often in
testing the NSSound stuff... I've attached a copy of the program. I'm
not sure if it's something I'm doing, or what? I'm using SVN r28323
(it's kind of old).
Here's the gdb output:
(gdb) r
As we are about to the the big change to NSSound from Stefan Bidigaray
and new code tends to need a few weeks to get most of the bugs out, I'd
like to propose that we release a new version of gui and back before
that. There already a quite a few bug fixes in both that would justify a
release
Gregory Casamento schrieb:
Author: gcasa
Date: Mon Jul 13 20:12:52 2009
New Revision: 28392
URL: http://svn.gna.org/viewcvs/gnustep?rev=28392view=rev
Log:
* Source/NSAlert.m: Implementation of GSAlertSheet.
* Source/NSApplication.m: Change order in which setWindowParent:
Gregory Casamento schrieb:
Author: gcasa
Date: Mon Jul 13 20:14:42 2009
New Revision: 28393
URL: http://svn.gna.org/viewcvs/gnustep?rev=28393view=rev
Log:
* Headers/Foundation/Foundation.h
* Headers/Foundation/NSOperation.h
* Source/GNUmakefile
*
David Chisnall schrieb:
On 16 Jul 2009, at 18:34, Riccardo Mottola wrote:
Sorry, I just haven't had a chance to look at installing a
new/different compiler and working with that yet, though it really IS
something I'd like to be playing with.
However, it doesn't really have any bearing on
Stef Bidi schrieb:
On Mon, Jul 13, 2009 at 9:20 AM, Adam Fedor fe...@qwestoffice.net wrote:
On Jul 11, 2009, at 6:38 AM, Fred Kiefer wrote:
As we are about to the the big change to NSSound from Stefan Bidigaray
and new code tends to need a few weeks to get most of the bugs out, I'd
like
Fred Kiefer schrieb:
why do you expect the next release to break ABI compatibility? What I
wanted to do is a bug fix release and this is why I restricted myself to
non ABI breaking changes. Looking back through the ChangeLog file I
noticed that Greg has added an attached sheet ivar to NSWindow
Gregory John Casamento schrieb:
I can undo the change. The last email you sent wasn't clear with
respect to whether you wished me to remove it or to fully implement
it. I chose to fully implement it. I can remove it and stub out
the implementation, if we want to do an ABI compatible
Gregory Casamento schrieb:
I have stubbed out the ivar and it's methods. This should have no
impact since no one is actually using the attachedSheet method.
I'll put it back in once we have done the release.
Great, this should make us ready for a bug fix release for gui and back.
Adam, are
Original-Nachricht
Datum: Thu, 30 Jul 2009 20:00:09 -0600
Von: Adam Fedor fe...@qwestoffice.net
An: Fred Kiefer fredkie...@gmx.de
CC: Gregory Casamento greg.casame...@gmail.com, Developer GNUstep
gnustep-dev@gnu.org
Betreff: Re: New gui/back release?
On Jul 27, 2009
Adam Fedor schrieb:
This is version 0.17.1 of the GNUstep GUI library (`gnustep-gui').
Now that the 0.17.1 release of gui and back are out (Many thanks to Adam
for making the release!) we are going to start with ABI incompatible
changes on gui and back. If you have anything that will break ABI
Gregory Casamento schrieb:
Sorry... forgot to reply all... darn google.
Actually you didn't :-)
-- Forwarded message --
I did think it was odd that GSTextStorage encoded itself.The
question now is, since it does, and, probably has, for a while, I'll
need to run some
Fred Kiefer schrieb:
I did think it was odd that GSTextStorage encoded itself.The
question now is, since it does, and, probably has, for a while, I'll
need to run some tests to see if this is encoded in .gorm files or
not. If we simply yank the code it could break compatibility
Committed, plus a few changes to initWithCoder:
Thank you
Fred
Quentin Mathé schrieb:
Hi,
Here is a small patch to make NSView posts both frame and bounds
notifications without having to explicitly invoke
-setPostsBoundsChangedNotifications: and -setPostsFrameChangeNotification:.
Although
Gregory Casamento schrieb:
Author: gcasa
Date: Thu Aug 20 00:25:33 2009
New Revision: 28488
URL: http://svn.gna.org/viewcvs/gnustep?rev=28488view=rev
Log:
Add new branch with corrected revision number.
Added:
libs/gui/branches/testplant_1/
- copied from r28233,
Gregory Casamento schrieb:
I've been taking selected fixes, currently only the deadlock fixes
from NSUserDefaults.
Great.
I'd appreciate any detailed feedback you have on the others before
inclusion into the trunk.
Patches that look ok to me:
28492 GSLayoutManager.m
Patches that will
Stef Bidi schrieb:
I just committed the new NSSound implementation. Keep in mind it's very
rough at this point. A few things, off the top of my head:
* Need to check for libsndfile and libao, and only build SndfileSource and
AudioOutputSink if they exist;
* There's a hack in
Thank you, but the compiler still fails when trying to compile the
bundle in Sounds. Most like we need to check the value of BUILD_SOUNDS
in the GNUmakefile there.
Can anybody explain to me, why the sound bundle no longer is in Tools,
but in Sounds now? I don't seem to understand the benefit of
I committed a slightly different patch, to keep the size of the class
the same. Please check that I didn't break anything.
Fred
Quentin Mathé schrieb:
Hi,
Here is a patch to fix NSSearchFieldCell archiving and keyed archiving.
Non-keyed archiving was crashing because _max_recents ivar was
Yes please, send me the source and I have a look.
Fred
Original-Nachricht
Datum: Thu, 17 Sep 2009 11:34:09 +0100
Von: Derek Fawcus dfaw...@cisco.com
An: gnustep-dev@gnu.org
Betreff: Current status of NSTextStorage/NSLayoutManager/NSTextContainer?
What is the view of the
I just rewrote part of the text converter interface of
NSAttributedString. The new interface should be more powerful, as it
takes another options parameter and has the ability to return NSError
objects. It is also simpler as there is only one method left to
implement for each consumer or producer.
wasn't handling that gracefully. I changed
GNUstep SVN to use the default paragraph style when none is set, now
your example runs correctly for me. You either will have to update to
GNUstep SVN to see this or use an explicit paragraph style in your code.
Cheers
Fred
Fred Kiefer schrieb:
Yes please
I don't think this is a bug in GNUstep, there rather is a problem in
your code. You don't own the attr object as it is created via
dictionaryWithObjectsAndKeys: and still you release it.
I am surprised that this works on Apple.
Cheers
Fred
Derek Fawcus schrieb:
I suspect there is a bug here
Nikolaus Schaller suggested to change the handling of updateWindows in
nextEventMatchingMask:... of NSApplication to redraw less often. This
made me aware that I am not really familiar with the code there and I
would like to discuss a few issues on this mailing list.
- Setting the current event
David Chisnall schrieb:
IMP caching is a bit more complicated. The new runtime supports a means
of invalidating IMP caches, which means that the compiler will be able
to automatically insert (polymorphic) IMP caching and even speculatively
inline methods. Doing this well will require
Sergii Stoian schrieb:
2009/10/9 Riccardo Mottola mul...@ngi.it
Many things you want do not clash with other goals, they only divert
manpower. But keep in consideration that in an opensource project people do
whatever they deem interesting or useful, there isn't a central planning.
Sure,
Richard Frith-Macdonald schrieb:
Begin forwarded message:
From: Richard Frith-Macdonald rich...@tiptree.demon.co.uk
Date: 16 October 2009 07:29:59 GMT+01:00
To: Philippe Roussel p.o.rous...@free.fr
Cc: discuss-gnus...@gnu.org
Subject: Re: Window manager interaction
On 15 Oct 2009,
I Just added the gui part of an implementation of NSGradient. This is
based on code by Nikolaus Schaller and still requires some clean up. If
somebody helps me to remove all the remaining FIXMEs in the code I am
willing to define two backend methods for this class and implement them
at least for
Fred Kiefer schrieb:
I Just added the gui part of an implementation of NSGradient. This is
based on code by Nikolaus Schaller and still requires some clean up. If
somebody helps me to remove all the remaining FIXMEs in the code I am
willing to define two backend methods for this class
Germán Arias schrieb:
Hi Fred, If you are agree I will add the variables
GSUseWindowFrameColorToMenu and GSMenuItemsBordered to GUI, but I don't
know in what file are seated the defaults values of the variables.
And I don't know if you are agree to add GSTaskBar (or whatever you want
call
Fred Kiefer schrieb:
Specifically for the menu item colour I am thinking about making the
system extension colour list, that is already used in GSToolbarView an
official GNUstep mechanism, move the code over to NSColor and to add all
the other colour definitions we have scattered in GNUstep
Hans Baier schrieb:
I already implemented drawing functions
for most widgets (except NSPopUpButton, Menus and Tabs).
Here is a screenshot:
http://stashbox.org/687974/Bildschirmfoto.png
here is the code:
http://github.com/hansfbaier/gnustep-gnome
NOTE: The code is extremely
Hans Baier schrieb:
Apart from that, one thing about GNUstep annoys me very much:
The absence of context menus. I don't know currently how OS X handles that,
but often I would find myself right-clicking on something, but the
application menu pops up.
The behaviour you describe is the one you
Doug Simons schrieb:
Author: dpsimons
Date: Mon Nov 16 23:51:14 2009
New Revision: 29026
URL: http://svn.gna.org/viewcvs/gnustep?rev=29026view=rev
Log:
fix problem with mouse tracking being off in submenus that are shifted to
stay on screen
Modified:
I will be on holidays for the next two weeks and most likely wont get
near a computer during that time.
It would be great if others took care of any question or bug reports on
GNUstep gui or back during that time.
Cheers
Fred
___
Gnustep-dev mailing
Quentin Mathé schrieb:
As explained in my previous mail, I updated NSTableColumn with the
latest Mac OS X additions.
However I'm unsure how to precisely update the archiving code and I
don't want to break Gorm… Apple has the following keys in the xib
format: NSResizingMask (int),
Eric Wasylishen schrieb:
Hey,
On OS X, the methods in NSBitmapImageRep for accessing and setting
pixels use flipped coordinates - i.e. [colorAtX:0 y:0] is the
top-left pixel, whereas on GNUstep that returns the bottom-left pixel.
This patch corrects GNUstep to match OS X, and changes the only
The change to setMinValue: and setMaxValue: surely are correct and the
addition of setObjectValue: is just great. What I don't understand is
why the method setDoubleValue:, setFloatValue: and setIntValue: had to
be implemented. The default behaviour (calling setObjectValue:) should
just do the
Richard Frith-Macdonald schrieb:
Author: rfm
Date: Sun Oct 18 08:28:50 2009
New Revision: 28836
URL: http://svn.gna.org/viewcvs/gnustep?rev=28836view=rev
Log:
code for deminiaturisation
Modified:
libs/back/trunk/ChangeLog
libs/back/trunk/Source/x11/XGServerEvent.m
Am 01.01.2010 20:43, schrieb Germán Arias:
I have translated into Spanish most of the texts in the GUI. But there
are some texts that I don't know how translate. For example in the panel
to open files, I can not translate the word Open if I add this in
Localizable.strings, or the text Cancel
Am 02.01.2010 16:22, schrieb David Chisnall:
Hi Everyone,
With the non-fragile ABI, Apple removed support for class posing. This
makes sense, because it's no longer possible to guarantee that the class
has the same ivar layout.
I'm tempted to do the same thing for our non-fragile ABI.
Am 11.01.2010 09:13, schrieb inet.t...@gmail.com:
can i help the project, i can translate in italian language the doc , i can
find bug in programs and i know object c for porting programs?
Thank you for your interest in GNUstep!
Any help for GNUstep is highly appreciated. One way to start out
Am 20.01.2010 20:52, schrieb Derek Fawcus:
[from bug-gnustep]
On Wed, Jan 20, 2010 at 02:47:38PM +, Fred Kiefer wrote:
And we only need to change any code in the case where we
don't use shared memory (this is for some reason broken on modern X Servers
and I don't have a clue
Am 23.01.2010 01:19, schrieb Eric Wasylishen:
On 2010-01-22, at 3:26 PM, Vincent R. wrote:
Hum Wait. This is exactly what I am working on windows. I have
compiled CoreFoundationLite and now I implement CoreGraphics with
openVG/cairo backend.
Cool, we should combine our efforts if possible!
This in itself is a great change, but do we really want to give up
having ChangeLog entries for something as important as this?
Just a few days ago I was trying to find out where the file
objc-gnu2next.h went and why it was removed. Of course I could dig
through the history of the Source
I thought that we only have the devroom on Sunday. And the official FOSDEM
schedule says so. Maybe we find a quite place somewhere on Saturday, or better
move this talk to Sunday, but then not that later as I will be on my way back
home at 5pm already.
Fred
Original-Nachricht
Am 07.02.2010 21:06, schrieb Nicola Pero:
I implemented having headers in sub-subdirectories.
For example, consider a framework called Beauty. Let's you have headers
Beauty_HEADER_FILES = Beauty.h Vanity.h
then your headers would be in
Beauty/Beauty.h
Beauty/Vanity.h
and end
After the reorganisation of base I get a lot more compiler warnings then
before. It would be great if somebody could look into these. I am using
gcc 4.4.1 on a 64 bit system.
Compiling file GSObjCRuntime.m ...
GSObjCRuntime.m: In function
‘GSObjCMethodNames’:
Am 16.02.2010 15:53, schrieb Richard Frith-Macdonald:
I'd like to standardise include/imports in the core libraries ... as
I've been doing a lot of it in base.
Previously in base, there was really a bit of a mess ...
Lots of #includes from they days when #import was deprecated ...
Am 15.02.2010 15:18, schrieb Richard Frith-Macdonald:
On 15 Feb 2010, at 13:47, Fred Kiefer wrote:
After the reorganisation of base I get a lot more compiler warnings
then before. It would be great if somebody could look into these. I
am using gcc 4.4.1 on a 64 bit system.
I don't actually
Things are worse than I expected. I just ran the test suite for base and
got plenty of FAILs from it:
--- Running tests in base ---
base/coding/basictypes.m:
FAIL: base/coding/basictypes.m
base/coding/decoding.m:
FAIL: decoding version 2 of class NSValue
base/Functions/NSGeometry1.m:
FAIL:
Am 18.02.2010 09:45, schrieb Richard Frith-Macdonald:
On 18 Feb 2010, at 08:06, Fred Kiefer wrote:
Am 15.02.2010 15:18, schrieb Richard Frith-Macdonald:
On 15 Feb 2010, at 13:47, Fred Kiefer wrote:
After the reorganisation of base I get a lot more compiler warnings
then before. It would
Am 18.02.2010 11:47, schrieb Richard Frith-Macdonald:
On 18 Feb 2010, at 10:35, Nicola Pero wrote:
It has a small effect on how we should organize headers in base
too:
I want to clearly separate out non-OSX stuff from OSX stuff, so
that our extensions would all be available to OSX
Am 20.02.2010 11:46, schrieb Fred Kiefer:
Am 20.02.2010 07:09, schrieb Germán Arias:
Currently GUI and Back cant build in my system. With GUI I get the
error:
NSApplication.m:170: aviso: implicit declaration of function
'OBJC_STRINGIFY'
NSApplication.m:170: error: expected identifier before
:
../../Headers/x11/XGServer.h: 52: error: Can not find interface
declaration for 'GSDisplayServer', superclass of 'XGServer'
In both errors, the problem seems to be in GSDisplayServer.h
El sáb, 20-02-2010 a las 17:38 +0100, Fred Kiefer escribió:
Now even 64 bit systems should be able
Google summer of code registration is starting soon
(http://code.google.com/intl/de-DE/soc/). Do we want to try to
participate again this year? After the previous experience I am not
really sure we should. They did not select us last year and we failed to
attract suitable students in the years
I just tried to reproduce this behaviour and failed to.
On which application are you seeing this and probably more important,
which GNUstep backend are you using? Do you have a theme enable?
Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at:
Looks like NSTabView in trunk is currently
current svn trunk. Gorm shows the same broken behaviour on my machine,
screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0.
Thanks
TOM
Zitat von Fred Kiefer fredkie...@gmx.de:
I just tried to reproduce this behaviour and failed to.
On which application are you seeing
header?
Thanks
TOM
Zitat von Fred Kiefer fredkie...@gmx.de:
I just recompiled Gorm and it looks different here :-)
As this is also on a 64bit system the main difference I see is the cairo
version. Could you please try a different backend to confirm that it is
the cairo backend
Am 02.03.2010 09:24, schrieb Wolfgang Lux:
Author: fredkiefer
Date: Sun Feb 8 13:54:21 2009
New Revision: 27812
URL: http://svn.gna.org/viewcvs/gnustep?rev=27812view=rev
Log:
Use KVC call setValue:forKey: to establish the outlet connection.
This will result in ivars being properly
politics.
Fred
Am 27.02.2010 21:53, schrieb Gregory Casamento:
Markus,
On Thu, Feb 25, 2010 at 3:28 AM, Markus Hitter m...@jump-ing.de wrote:
Am 24.02.2010 um 10:42 schrieb Fred Kiefer:
They did not select us last year and we failed to attract suitable
students in the years before
Am 03.03.2010 10:06, schrieb Wolfgang Lux:
Fred Kiefer wrote:
I am not that sure about this.
When I changed to the current code it was to get the Beans application
working with GNUstep. There we had the case the components loaded via
NIB where released to early by GNUstep.
We rather
Am 04.03.2010 12:39, schrieb Richard Frith-Macdonald:
On 1 Mar 2010, at 21:03, Fred Kiefer wrote:
I just recompiled Gorm and it looks different here :-)
As this is also on a 64bit system the main difference I see is the cairo
version. Could you please try a different backend to confirm
Am 07.03.2010 15:09, schrieb ici...@mail.cg.tuwien.ac.at:
Because of my ongoing issues with current GNUstep from svn today I
decided to do a fresh start and removed all GNUstep installation related
files from my hardrive. After that I did a svn update and did a fresh
build of core and gorm.
The non-working palettes are at least something I am able to reproduce
on my system. This doesn't seem to be relate to the selected backend.
It might either be a Gorm or a gui problem. I will look into this.
Fred
Am 07.03.2010 17:20, schrieb Gregory Casamento:
I can confirm that I can't drag
lost in recent rewrites of base :-)
I will fix this and also change all the parameters in GSArray.m to
NSUInteger that are now changed in the super class NSArray.
Fred
Am 07.03.2010 18:46, schrieb Fred Kiefer:
The non-working palettes are at least something I am able to reproduce
on my system
Am 07.03.2010 21:42, schrieb Eric Wasylishen:
Hi, I wonder if the change I made in December to use CAIRO_EXTEND_PAD
when drawing images is responsible for this. I just checked now and
the cairo docs say CAIRO_EXTEND_PAD is only implemented in 1.6 and
later for surface patterns.
Maybe try
Am 08.03.2010 07:22, schrieb Richard Frith-Macdonald:
On 7 Mar 2010, at 19:10, Fred Kiefer wrote:
Just to keep you informed on my current finding. I could follow a mouse
down event that should start a drag into the method [XGDragView
dragImage:at:offset:event:pasteboard:source:slideBack
Am 08.03.2010 10:30, schrieb Richard Frith-Macdonald:
On 8 Mar 2010, at 06:22, Richard Frith-Macdonald wrote:
On 7 Mar 2010, at 19:10, Fred Kiefer wrote:
Just to keep you informed on my current finding. I could follow a
mouse down event that should start a drag into the method
Am 11.03.2010 19:46, schrieb Wolfgang Lux:
Fred Kiefer wrote:
Am 03.03.2010 10:06, schrieb Wolfgang Lux:
Fred Kiefer wrote:
I am not that sure about this.
When I changed to the current code it was to get the Beans application
working with GNUstep. There we had the case the components
Am 12.03.2010 22:29, schrieb Doug Simons:
Author: dpsimons
Date: Fri Mar 12 22:29:37 2010
New Revision: 29912
URL: http://svn.gna.org/viewcvs/gnustep?rev=29912view=rev
Log:
capture the mouse to get mouse moved events outside of window
Modified:
libs/back/trunk/ChangeLog
Am 13.03.2010 00:31, schrieb Wolfgang Lux:
Fred Kiefer wrote:
Thank you for looking into this.
Looks like the basic difference between Cocoa and us is in the window,
window controller and document interaction. And you are the sole expert
we have on this :-)
At the end of the day it looks
Am 02.03.2010 21:15, schrieb David Chisnall:
On 2 Mar 2010, at 19:09, Fred Kiefer wrote:
Get yourself comfortable wit Objective-C first. But then David's
book is a great way to learn about GNUstep as well as Cocoa. The
only problem you will find are the examples. David wrote them on
Apple
I am trying to hunt down a very hard to catch memory issue. It should be
easy to reproduce for anybody interested. Just start up Ink, open the
info panel and start up the memory panel by clicking on the icon. Now
press the update button a few times until things settle down.
If you keep on
and contact TestPlant
via the switchboard on +1 720-890-0211 or via return e-mail. You
should not copy, forward or use any part of the contents in any way.
Any such unauthorised use or disclosure may be unlawful.
On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote:
Am 13.03.2010 00:31, schrieb Wolfgang
Am 17.03.2010 12:34, schrieb Richard Frith-Macdonald:
On 17 Mar 2010, at 09:26, Fred Kiefer wrote:
I am trying to hunt down a very hard to catch memory issue. It
should be easy to reproduce for anybody interested. Just start up
Ink, open the info panel and start up the memory panel
Am 17.03.2010 20:26, schrieb Adam Fedor:
On Mar 17, 2010, at 12:34 PM, Vincent Richomme wrote:
/* Return YES if this looks like a JPEG. */
+ (BOOL) _bitmapIsJPEG: (NSData *)imageData
{
struct jpeg_decompress_struct cinfo;
... BLABLA ...
// establish return context for error handling
Am 17.03.2010 20:25, schrieb Vincent Richomme:
Hi Fred,
On 15 Mar 2010, at 10:57, Fred Kiefer wrote:
I just started a loader for the XIB format. Seems to load the one test
file I tried pretty well, but wont do anything useful with the loaded
data :-)
What's the performance like
Am 17.03.2010 20:21, schrieb David Chisnall:
Hi Fred,
On 15 Mar 2010, at 10:57, Fred Kiefer wrote:
I just started a loader for the XIB format. Seems to load the one
test file I tried pretty well, but wont do anything useful with the
loaded data :-)
What's the performance like
Am 17.03.2010 23:58, schrieb Riccardo Mottola:
Germán Arias wrote:
Currently when you move the cursor to upwards at the color wheel, the
cursor leaves a trail (see attached image.
With today's SVN trunk code it works perfectly for me with the cairo
backend.
I was able to reproduce
.
Fred
Am 17.03.2010 20:16, schrieb Fred Kiefer:
I don't expect to see much differences between Windows and X11 on NIB
loading. If you could provide me with an stripped down example I would
try to have a look at what goes wrong there.
I'm already investigating an issue with the new code when
that tests whether this specific
feature is present in the used JPEG library or not.
Fred
Am 17.03.2010 21:59, schrieb Vincent Richomme:
On Wed, 17 Mar 2010 21:42:21 +0100, Fred Kiefer fredkie...@gmx.de wrote:
Am 17.03.2010 20:26, schrieb Adam Fedor:
On Mar 17, 2010, at 12:34 PM, Vincent
AM, Fred Kiefer wrote:
Just in case my last mail wasn't clear enough on that point: All
you have to do to get your application working again with the
current NIB loading code is to add a setter method that retains its
argument. And for us it would be important to have an example of
how
Am 18.03.2010 23:25, schrieb Stef Bidi:
For some reason I can't check out a r/w copy (I get a permission denied
error). I'm sure this is only a problem for me seeing as there have been
constant changes in svn. Still have to figure this one out.
In any case, can someone apply this corebase
Am 19.03.2010 09:20, schrieb Fred Kiefer:
My current position on NIB loading is that no magic should happen there.
Objects created while loading a NIB file should follow the standard
rules. Nothing will be retained except for the top level objects being
retained in the top level object array
Thank you for pointing out the problem with NSApp. This was caused by a
missing retain in some part of GSNibLoading that I hadn't cleaned up.
Hopefully this is fixed now. If there are any other issues I hope we can
resolve them as quick as that one.
Fred
Am 22.03.2010 18:24, schrieb Doug
No this wasn't caused by the NIB loading fixes, this time it was the
NSTextView change I made :-)
While investigating the NIB problem I noticed that Ink kept on to each
text network it created. I thought that there was no point in fixing NIB
loading when most the same objects get retain just a
This clearly was my fault. In the NIB loading of NSIBObjectData the old
code was looping over the _names map to instantiate the objects. I
changed that to the _objects map which looked better to me. As your
results show this isn't true I changed that code back again. That way
the owner once more
I only had a short look at this patch and was a bit surprised to see how
little these two implementations share. In a normal class cluster you
would expect that most of the code is in the common super class and only
the primitive methods get implemented separately. What was the reason
for doing it
Before FOSDEM we were planing a coordinated release of the GNUstep core
components. In the meantime a lot has happened. Base was completely
rewritten, or so it seems from the outside and gui had to play catch up.
Then I toyed around with the NIB loading and broke a few things.
Now things are
Mhm, I already did all of that yesterday...
But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The code
is a lot cleaner now, but as far as memory leaks are concerned we are
almost back to square one. We now leak
Am 29.03.2010 20:47, schrieb Fred Kiefer:
But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The code
is a lot cleaner now, but as far as memory leaks are concerned we are
almost back to square one. We now leak
Am 30.03.2010 08:45, schrieb Wolfgang Lux:
Mhm, I already did all of that yesterday...
But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The code
is a lot cleaner now, but as far as memory leaks are concerned
Am 01.04.2010 19:00, schrieb Vincent Richomme:
Hi,
I have implemented some part of CoreGraphics using plain C and I wanted to
see
if I could also implement UIkit (iPhone API).
For my purpose I have copied headers from apple(I know it's bad) and I
have
modified them to compile with
I am currently trying to reduce the amount of compiler warnings
generated by GNUstep gui. At the moment I have these left with a gcc
4.4.1 on a 64 bit system:
NSDocumentController.m:105: warning: ‘TypeInfoForHumanReadableName’
defined but not used
NSGraphicsContext.m: In function
While going through the internal GNUstep headers I noticed that we still
have the place holders for CoreGraphics in there that Adam added a few
years ago. Now with an ever more complete implementation of CoreGraphics
in opal these seem obsolete to me. Should we just remove them?
The only drawback
Am 09.04.2010 20:06, schrieb Gregory Casamento:
I propose that we freeze the code to all new features on the trunk
before the release starting next friday (4/17). The freeze should be
in place for a week or two so that we can find bugs and correct them
prior to the release planned for either
Am 10.04.2010 00:26, schrieb David Chisnall:
On 9 Apr 2010, at 22:37, Fred Kiefer wrote:
Looking over the ChangeLog files of base and gui (Yes, another good
use of these files that would be annoying to be replaced with an
SVN command),
Because 'svn log | more' is much more effort to type
Am 12.04.2010 15:48, schrieb Philippe Roussel:
Hi all,
While compiling svn trunk I saw a warning that looked like a real bug.
If I'm not mistaken, here's the fix in its glorious complexity.
Philippe
Index: gui/Source/NSBitmapImageRep+JPEG.m
The only bug that was publicly stated, as far as I am aware of, was
Richards network issue. I am not sure what the state of this is now.
Then there is the open decision, what should be the default theme for
Windows. From what I gather from the mails on that subject, we should
stick to the default
301 - 400 of 1099 matches
Mail list logo
