Re: GDL2 Release for Debian Lenny
Hello David I would like to plan a GDL2 release for Lenny. I'm not sure what the exact deadlines are but they are approaching. Some of the GDL2 prerequisites are I've got an approximate deadline for Lenny here: http://asdfasdf.ethz.ch/~tar/bts/ Days until Lenny release (15 September 2008) 100 -make [current version in Lenny: 2.0.5 Sid: 2.0.5] -base [current version in Lenny: 1.14.1 Sid: 1.14.1] -gui [current version in Lenny: 0.12.0 Sid: 0.12.0] -back [current version in Lenny: 0.12.0 Sid: 0.12.0] Renaissance [current version in Lenny: 0.8.0 Sid: 0.9.0] GORM.app [current version in Lenny: 1.2.2 Sid: 1.2.2] I think having a more up to date GNUstep in Lenny would be very good, that'd also encourage me to udpate the livecd.gnustep.org again. I'd wish someone picked up emacs.app too. The http://www.opentrack.ch/ developer was kinda disappointed when we tried to build his app on Linux, the Windows and GNUstep versions are not in sync so half of his stuff didn't work... I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. If we manage to make new and non memory leaking (timemon.app+gnustep-gui, right bheron?) tarball releases and Hubert can insert them into Lenny, I'm all up to help transition all the GNUstep software in Debian for Lenny. Including GDL2. Yours, Gürkan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
[EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I'm looking forward for a new stable release... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 Release for Debian Lenny
Gürkan Sengün wrote: I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. If we manage to make new and non memory leaking (timemon.app+gnustep-gui, right bheron?) tarball releases and Hubert can insert them into Lenny, I'm all up to help transition all the GNUstep software in Debian for Lenny. Including GDL2. As far as I know all reported memory leaks have been fixed in gui and back for the SVN version. Could you please recheck your application if there is still an issue? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: validateUserInterfaceItem (NSDocumentController implementation)
This method should get called from the user interface to determine
whether an item is to be enabled or disabled. This currently doesn't
happen in GNUstep (as far as I know). What should happen inside this
method is that the object checks whether the action of the item is
currently applicable or not. The object should only check its own action
methods, not that of other classes. When ever we implement this
mechanism, the method on NSDocument will get called for these items
where the document itself is the target of the item.
What the document controller could do is to check if saveAllDocuments:,
newDocument: and openDocument: are currently possible. I think only the
first one make any sense here.
What I cannot remember at the moment is where the calling should happen
and whether it would be worthwhile to implement that.
Hope this helps,
Fred
DELHAISE Thierry wrote:
Hi the list,
I'm developping a Desktop GUI app based on
NSDocumentController/NSDocument implementation.
The current implementation of NSDocumentController (in
gnustep-gui(trunk) revision 26587 ) is :
- (BOOL)validateUserInterfaceItem:(id NSValidatedUserInterfaceItem)anItem
{
// FIXME
return YES;
}
Should the implementation could be :
call NSDocument validateUserInterfaceItem, and return the return value.
Second , how [[NSDocumentController instance]
validateUserInterfaceItem:sender] get called ?
Thanks in advance for suggestions.
Thierry
PS : I quickly checked Apple doc's : no precision. And I don't have any
OSX machines to check.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
I believe we should shoot for this, yes. So you think we should target the end of the month to make the release? Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, June 5, 2008 3:11:34 PM Subject: Next stable release? Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
little fix on autogsdoc
Hi, Is it ok if I apply this little patch ? It simply enclose the methods summary and the abstract in divs, so you can style them. Any reason why the css include line 1119 is disabled ? thanks, -- Nicolas Roard I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams AGSHtml.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 Release for Debian Lenny
Fred Kiefer wrote: Gürkan Sengün wrote: I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. If we manage to make new and non memory leaking (timemon.app+gnustep-gui, right bheron?) tarball releases and Hubert can insert them into Lenny, I'm all up to help transition all the GNUstep software in Debian for Lenny. Including GDL2. As far as I know all reported memory leaks have been fixed in gui and back for the SVN version. Could you please recheck your application if there is still an issue? Not really, but could you build and run TimeMon? It leaked like 500 MB, in half an hour. I am unable to build gnustep myself because building it is so hard. I prefer to use prebuilt binary debian packages of Hubert. Thanks, Gürkan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 6 Jun 2008, at 09:05, Fred Kiefer wrote: Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Hi, There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. Has anybody managed to get GNUstep/Cairo working on Solaris?? Regards, Andreas ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
В Fri, 06 Jun 2008 02:17:10 -0700, Gregory John Casamento написа: So you think we should target the end of the month to make the release? It would be too late for Debian, I'm afraid. According to [1] all libraries will be frozen at the end of this month. Of course we could always ask the release team for exception, but whether they will grant it is questionable. [1] http://lists.debian.org/debian-devel-announce/2008/06/msg0.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 6/6/08, Fred Kiefer [EMAIL PROTECTED] wrote: Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. I just wanted to chime in that these fixes exposed a bug in DBModeler, before things were leaking, the fixes showed that in some implementation of -dealloc we were iterating over an array while a method called from dealloc had been changed to modify the array. after fixing that everything appears to be working fine for it. I did notice an NSTableView bug though, and its reproducable afaict with any editable tableview if you edit a field after editing its row never set as needing display, you have to click a row to get things to redraw. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
I'm not sure, but I defer to Fred's judgement entirely on this. But my opinion is that If we do deprecate it, it should not be removed for a while. The reason is that the xlib/x11 backend is a good fallback position to have when all else fails. Additionally, on older machines, the xlib backend is the only thing that's useful since the art and/or cairo backends may be somewhat slow on them. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: David Chisnall [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Richard Frith-Macdonald [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Friday, June 6, 2008 7:20:33 AM Subject: Re: Next stable release? On 6 Jun 2008, at 09:05, Fred Kiefer wrote: Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] GDL2 Release for Debian Lenny
Hubert Chathi wrote: Until the LGPL3/GPL2 issue is resolved, those are the latest versions that we can have in Debian, or else we'd have to get rid of Terminal.app (and a few other packages) from Debian. It's a judgement call. IMVHO we should not hold a major GNUstep update just for this, especially in the situation now (i.e. what will be shipped in Lenny). The goodness that the new GNUstep brings outweighs the loss, having in mind that this will be GNUstep for some users in the next 1.5-2 years. It would enable us to update Gorm, Project Center, SimpleAgenda and will be better as a whole for stable users. Releasing Lenny with the current versions would leave Project Center out, and will generate the familiar (true in some sense) rants Debian ships an outdated stable release with obsolete GNUstep. Resolving the licensing issue for Debian means updating the meta-package and asking for removal or Terminal, Vindaloo (ViewPDF), PopplerKit, EdenMath and others and rebuilding GWorkspace without the PDF inspector. Of course we will reintroduce these packages when/if the problem is resolved. Sad and rather unfortunate, but that's how it is. We (or more precisely you as the leader and maintainer of the most important parts) have to make a decision and there is no time. Yeah, there are a couple of build failures that I need to look into for Renaissance 0.9.0 on powerpc and hppa. AFAIU the hppa build failure is an ICE, so it's a bug in GCC. The powerpc one smells like that too. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 Release for Debian Lenny
Gürkan Sengün wrote: Fred Kiefer wrote: Gürkan Sengün wrote: I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. If we manage to make new and non memory leaking (timemon.app+gnustep-gui, right bheron?) tarball releases and Hubert can insert them into Lenny, I'm all up to help transition all the GNUstep software in Debian for Lenny. Including GDL2. As far as I know all reported memory leaks have been fixed in gui and back for the SVN version. Could you please recheck your application if there is still an issue? Not really, but could you build and run TimeMon? It leaked like 500 MB, in half an hour. As I wrote, all known memory leaks have been fixed in SVN, this was one of them. As far as I can tell TimeMon is not leaking any memory what so ever. At least not during the first ten minutes, which was the longest I tried up to now. :-) I am unable to build gnustep myself because building it is so hard. I prefer to use prebuilt binary debian packages of Hubert. What is your problem with compiling GNUstep from SVN? We try had to make it easy to build GNUstep, what is stopping you? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
I would prefer not to deprecate xlib. There still are environments where it is better working then the cairo backend. For the moment I would still recomment art as the standard backend while still planing to have cairo as the main backend for the future. The cairo library is still changing too fast to have a stable target to aim at. At the moment I am updating my second (virtual) Linux system to Ubuntu 8.04, this should include the latest cairo and with that I should be able to reproduce the cairo 1.6.4 issue. This would allow for a GNUstep stable release by the end of next week. Leaving some time to test Richards huge change. Fred Gregory John Casamento wrote: I'm not sure, but I defer to Fred's judgement entirely on this. But my opinion is that If we do deprecate it, it should not be removed for a while. The reason is that the xlib/x11 backend is a good fallback position to have when all else fails. Additionally, on older machines, the xlib backend is the only thing that's useful since the art and/or cairo backends may be somewhat slow on them. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: David Chisnall [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Richard Frith-Macdonald [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Friday, June 6, 2008 7:20:33 AM Subject: Re: Next stable release? On 6 Jun 2008, at 09:05, Fred Kiefer wrote: Richard Frith-Macdonald wrote: On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote: Following on David's email, It's been over a year since we last branched a stable release. Should we try to do another one soon? I guess so. I really wanted to get base much more compatible with the latest MacOS-X before doing another stable release, but I just haven't had the time to do any real work on that, so realistically it's not worth waiting. I don't see any reason at all not to make a new stable release of gui/back, but perhaps Fred knows differently. A new stable release is fine for me. I think the current code is far better then the 0.12 release and I don't see any mayor incompatibility change coming up in the near future. There is one thing I should do before a new back release, that is test with cairo 1.6.4 to see how to avoid the black bars that have been reported. I hope to do this on the weekend, after that a release should be possible. Just one more question: Are we all confident that the big changes I made to NSWindow and GSLayoutManager are now stable enough? They work perfectly for me, but that isn't a real test. Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Matt Rice wrote: I did notice an NSTableView bug though, and its reproducable afaict with any editable tableview if you edit a field after editing its row never set as needing display, you have to click a row to get things to redraw. Matt, I did not quite understand this description (Did you mean cell where you wrote row?), but if you have a fix for this, it surely is welcome. Thanks, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] GDL2 Release for Debian Lenny
Hubert Chathi wrote: Perhaps we should take a quick poll. This is an excellent idea, but how do you expect to do it? The lists this discussion is being carried on have limited audience. Of course the opinion of the gnustep-dev subscribers is valuable, and that of the main GNUstep maintainers and contributors matters even more. Theoretically, upgrading to the latest unstable GNUstep libraries would also allow us to update etoile, but I don't know if anyone has time to update the packaging soon enough. Personally, I'm ashamed that etoile in Debian is in such a pathetic state. I've been working on 0.2 packaging for some time, but it has also some bugs and annoyances and is generally unsupported upstream. I think that whatever happens, it is not realistic to bring etoile into shape for Lenny. This package is a huge undertaking, and not trivial even for a skilled Debian maintainer. We should definitely update it in the early Lenny+1 cycle, though. I should add that if we want to upgrade to a newer version of the GNUstep libraries, this could still be vetoed by the Debian Release Managers, if they don't think that we would hold up the release. Exactly. The GNUstep stack has always been a problem for the release team, and the last transition (I'm not blaming GNUstep developers at all) was the most painful in the history. We had to patch/modify literally every package, and this was combined with some bugs exposed by the new dpkg-shlibdeps behavior and other toolchain/infrastructure improvements in Debian that revealed a lot of bugs. [1] IIRC, we would lose ProjectCenter because the old version doesn't build with gnustep-make 2.0, and has incorrect templates for gnustep-make 2.0, Yes, that's right. We can theoretically make the last stable PC version RC-bug free and thus in release state Debian-wise but I would not do that in clear conscience. It would be utterly useless for everyone. Yes, the powerpc one smells like the old build failure that hit gnustep-examples, so I wonder if the same fix would work, Ah, right. It's exactly the same. Even more so, the author of the code is exactly the same -- so Nicola, could you please take a look at this? The user should be able to compile the package with no optimization for testing/debugging purposes (or whatever). The fix applied in Debian is just a workaround, IMO. References: http://buildd.debian.org/fetch.cgi?pkg=renaissancearch=powerpcver=0.9.0-1stamp=1208914375file=logas=raw http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457555 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 Release for Debian Lenny
Fred Kiefer wrote: Gürkan Sengün wrote: Fred Kiefer wrote: Gürkan Sengün wrote: I would like to know which versions (stable/unstable) are to be expected for Lenny so that I can match/remove some of the workarounds and hacks needed. If we manage to make new and non memory leaking (timemon.app+gnustep-gui, right bheron?) tarball releases and Hubert can insert them into Lenny, I'm all up to help transition all the GNUstep software in Debian for Lenny. Including GDL2. As far as I know all reported memory leaks have been fixed in gui and back for the SVN version. Could you please recheck your application if there is still an issue? Not really, but could you build and run TimeMon? It leaked like 500 MB, in half an hour. As I wrote, all known memory leaks have been fixed in SVN, this was one of them. As far as I can tell TimeMon is not leaking any memory what so ever. At least not during the first ten minutes, which was the longest I tried up to now. :-) OK, TimeMon has been running for almost two hours now on my computer, without changing the memory usage as displayed by top. May I stop that stupid application now? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Hi, Can we officially deprecate the x11 back end in this release and recommend Cairo? The OpenBSD package, for example, uses the x11 back end and I don't think this gives people the best impression of GNUstep. I've been using Cairo since AlpenStep last year and after Fred fixed a few bugs about a month later I've had no problems with it at all. I'm, as usual, against that. x11 is a good and efficient backend. It is already deprecated and I dislike that. It works fine although it has some shortcomings, but in a typical X11 environment it can be configured very well (for example, bitmapped fonts without antialias look just gorgeous). Export display is unbeatable. Sure, it has shortcomings in image transformation and scrolling speed, but I'd rather see them solved. I personally build my RPMs with X11, one depdendency less ... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
