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
Re: Next stable release?
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Next stable release?
I'd also like to release a gnustep-make v2.0.6. There are some very useful fixes in trunk. I have a fix or two which I still wanted to add, but they could also go in 2.0.7. Thanks ___ 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: 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
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: 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: 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
Re: Next stable release?
On Jun 6, 2008, at 2:05 AM, Fred Kiefer wrote: 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. Works fine for me, but I should probably update my Windows version and test that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Fred Kiefer wrote: 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. The cairo > 1.6.0 issue should be solved now. From my side there is no further known issue that would stop us from making the much needed new release. 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
Re: Next stable release?
On Jun 7, 2008, at 10:52 AM, Fred Kiefer wrote: Fred Kiefer wrote: 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. The cairo > 1.6.0 issue should be solved now. From my side there is no further known issue that would stop us from making the much needed new release. I'm traveling again the last two weeks on June, so we'd have to make the release next week or after July 1. Debian and/or it's derivatives are used by many many people so I'd love to get something out in time for them. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On Fri, Jun 6, 2008 at 12:32 PM, Fred Kiefer <[EMAIL PROTECTED]> wrote: > 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. no, i meant if you double click a cell, then type something and hit enter or tab keys after that the whole row is not redrawn (except for the field editor) and sometimes the whole tableview is blanked out the behaviour changes on different apps. I think we can kind of rule out NSTableView I tested the last known version that I know worked (r24478 of -make,base,gui,back) and that worked still... then i tested the svn head versions of make,base,gui,back with the r24478 version of NSTableView and that produced the same results. NSTableView drawing right now is fairly susceptible to attacks by things setting it as needing display besides itself. see NSTableView.m (-drawRect:) it blanks out the background of the entire rect with [self drawBackgroundInClipRect:aRect]; and highlights the selection then draws the grid. but if you look at -drawRow:clipRect: if (i != _editedColumn || rowIndex != _editedRow) { does drawing stuff.. } this code is fairly old and uncommented what i recall it doing is not drawing the edited row or column because it doesn't want to draw over top of the field editor. anyhow from the same version of NSTableView both working and not working it seems as though NSTableView doesn't set the edited row rect as needing display but either the field editor, or NSTextFieldCell or something else maybe is setting it as needing display that is my guess... anyways i've tried it with the cairo backend and the art backend you can reproduce it with gorm by going document->new application, select NSFirst select 'Classes' from the toolbar in the attributes inspector, select actions add a few actions edit the action name. hit enter ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 7 Jun 2008, at 18:30, Adam Fedor wrote: On Jun 7, 2008, at 10:52 AM, Fred Kiefer wrote: Fred Kiefer wrote: 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. The cairo > 1.6.0 issue should be solved now. From my side there is no further known issue that would stop us from making the much needed new release. I'm traveling again the last two weeks on June, so we'd have to make the release next week or after July 1. Debian and/or it's derivatives are used by many many people so I'd love to get something out in time for them. So ... if we want to do the release for the Debian freeze at the end of the month, we really need to make it by the end of this week! For the base library, reverting the license to LGPLv2 should be easy, but I'd also like the next stable release to mark all non-macosx stuff as deprecated ... on the basis that this would warn developers about the intention to be *highly* macosx compatible. Then we could either remove deprecated features (or move them to the additions library and undeprecate them) at will in the unstable branch after the release. If people are happy with this approach, I will at least try to search out and mark things as deprecated in the next few days, but if anyone wants to help with that I'd appreciate it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 8 Jun 2008, at 12:08, David Ayers wrote: Richard Frith-Macdonald schrieb: For the base library, reverting the license to LGPLv2 should be easy, but I'd also like the next stable release to mark all non-macosx stuff as deprecated ... on the basis that this would warn developers about the intention to be *highly* macosx compatible. Then we could either remove deprecated features (or move them to the additions library and undeprecate them) at will in the unstable branch after the release. If people are happy with this approach, I will at least try to search out and mark things as deprecated in the next few days, but if anyone wants to help with that I'd appreciate it. I would like to voice my opinion that I agree that being *highly* Cocoa compatible /by default/ is a good idea with respect to making it easier to write portable apps. I'm also for moving the GNUstep additions to -baseadd. I'm even for renaming any extensions in the NS namespace to GS. I'm not convinced that deprecating all non Cocoa features is a desirable goal in itself. Yet we really need to make sure that we do not introduce last minute changes which affect applications in non-obvious ways. I think such structural changes are more fit for the beginning of a release cycle. I understand the contention wrt the intended longevity of a stable release so I don't want the to interpreted as a veto... it's just that I think we really need to think about the pros and cons wrt changing the public API (and possibly behavior) at this stage. I have no desire to remove anything from the public API at this stage ... what I want to do is mark anything we might later want to remove (or move to another location) as deprecated, so that the developers using the release will know that their code should not depend on these features. We need to give developers as much warning as possible ... which means that in a new stable release, we really *must* deprecate anything that we might be removing before the following stable release. I'd rather deprecate things that we might later decide we want to retain, than leave undeprecated something we than want to remove. I suppose that, in addition to marking GNUstep'isms as deprecated, we should also deprecate anything that Apple have deprecated. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: > For the base library, reverting the license to LGPLv2 should be easy, > but I'd also like the next stable release to mark all non-macosx stuff > as deprecated ... on the basis that this would warn developers about the > intention to be *highly* macosx compatible. Then we could either remove > deprecated features (or move them to the additions library and > undeprecate them) at will in the unstable branch after the release. > > If people are happy with this approach, I will at least try to search > out and mark things as deprecated in the next few days, but if anyone > wants to help with that I'd appreciate it. I would like to voice my opinion that I agree that being *highly* Cocoa compatible /by default/ is a good idea with respect to making it easier to write portable apps. I'm also for moving the GNUstep additions to -baseadd. I'm even for renaming any extensions in the NS namespace to GS. I'm not convinced that deprecating all non Cocoa features is a desirable goal in itself. Yet we really need to make sure that we do not introduce last minute changes which affect applications in non-obvious ways. I think such structural changes are more fit for the beginning of a release cycle. I understand the contention wrt the intended longevity of a stable release so I don't want the to interpreted as a veto... it's just that I think we really need to think about the pros and cons wrt changing the public API (and possibly behavior) at this stage. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 8 Jun 2008, at 13:30, David Chisnall wrote: On 8 Jun 2008, at 10:30, Richard Frith-Macdonald wrote: For the base library, reverting the license to LGPLv2 should be easy, but I'd also like the next stable release to mark all non- macosx stuff as deprecated ... on the basis that this would warn developers about the intention to be *highly* macosx compatible. Then we could either remove deprecated features (or move them to the additions library and undeprecate them) at will in the unstable branch after the release. If people are happy with this approach, I will at least try to search out and mark things as deprecated in the next few days, but if anyone wants to help with that I'd appreciate it. I'm not sure I see the attraction in this. There are three cases, as I see it: 1) Things that were in NeXT, but are not in OS X. 2) Things that are not exposed by Cocoa and are either impossible or require Carbon on OS X. 3) Things that were added by GNUstep and have since had incompatible, but semantically equivalent, APIs added to Cocoa. For the third case, I agree that we should be deprecating the GNUstep extensions and adding the Cocoa versions if they don't already exist. For the other two, it would be better to set deprecated attributes with a macro that was only defined if MAC_OS_X_VERSION_MIN_REQUIRED is defined. Possibly tag each method with GS_EXTENSION, OPENSTEP_4, or MAC_OS_10_2_EXTENSION (where 2 is an example), and have these expand to __attribute__((deprecated)) based on defines provided in the GNUmakefile. The problem is, we've been using that mechanism for years and it hasn't worked. People either don't bother or forget to set the appropriate macros. I know this because nobody ever complains about errors in the version macro conditionals in the headers ... and there have been a lot of them that I've found and fixed myself. So what I want to do is have the library as OSX compatible as possible *by default* ... but have non OSX stuff available in the Additions library (built into gnustep-base by default, but with separate headers to include). If we have extensions that people find useful, then they should be maintained for people who don't value OS X compatibility. That's what the additions library is for ... with the added advantage that MacOS-X users can use the library (built standalone without the base library) on MacOS-X. If we deprecate features, we are then free to move them to the additions library, make them private within base (if base uses them but nobody else does), or drop them completely if practically nobody is using them. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 8 Jun 2008, at 10:30, Richard Frith-Macdonald wrote: For the base library, reverting the license to LGPLv2 should be easy, but I'd also like the next stable release to mark all non- macosx stuff as deprecated ... on the basis that this would warn developers about the intention to be *highly* macosx compatible. Then we could either remove deprecated features (or move them to the additions library and undeprecate them) at will in the unstable branch after the release. If people are happy with this approach, I will at least try to search out and mark things as deprecated in the next few days, but if anyone wants to help with that I'd appreciate it. I'm not sure I see the attraction in this. There are three cases, as I see it: 1) Things that were in NeXT, but are not in OS X. 2) Things that are not exposed by Cocoa and are either impossible or require Carbon on OS X. 3) Things that were added by GNUstep and have since had incompatible, but semantically equivalent, APIs added to Cocoa. For the third case, I agree that we should be deprecating the GNUstep extensions and adding the Cocoa versions if they don't already exist. For the other two, it would be better to set deprecated attributes with a macro that was only defined if MAC_OS_X_VERSION_MIN_REQUIRED is defined. Possibly tag each method with GS_EXTENSION, OPENSTEP_4, or MAC_OS_10_2_EXTENSION (where 2 is an example), and have these expand to __attribute__((deprecated)) based on defines provided in the GNUmakefile. If we have extensions that people find useful, then they should be maintained for people who don't value OS X compatibility. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 7 Jun 2008, at 18:30, Adam Fedor wrote: On Jun 7, 2008, at 10:52 AM, Fred Kiefer wrote: Fred Kiefer wrote: 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. The cairo > 1.6.0 issue should be solved now. From my side there is no further known issue that would stop us from making the much needed new release. I'm traveling again the last two weeks on June, so we'd have to make the release next week or after July 1. Debian and/or it's derivatives are used by many many people so I'd love to get something out in time for them. When do you want to do the new base release? I think the timeline might be something like this ... monday-wednesday: last chance to deprecate anything we might be wanting to change in the next release cycle thursday: merge trunk into stable branch, adjust version numbers to 1.16.0 (stable) and 1.17.0 (unstable/trunk) friday: update release notes and make release Reasonable? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On Jun 9, 2008, at 1:25 AM, Richard Frith-Macdonald wrote: When do you want to do the new base release? I think the timeline might be something like this ... monday-wednesday: last chance to deprecate anything we might be wanting to change in the next release cycle thursday: merge trunk into stable branch, adjust version numbers to 1.16.0 (stable) and 1.17.0 (unstable/trunk) friday: update release notes and make release Reasonable? That sounds good for me. I'm only afraid of doing something monumentally bad, like releasing something that doesn't compile. I have an extra day or two before I leave to make sure it's tested well. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 10 Jun 2008, at 14:28, David Ayers wrote: Richard Frith-Macdonald schrieb: I believe that marking features that will be merely moved to - additions as deprecated is misleading. To me deprecation means prepare for removal... i.e. adapt all your code. If it just means "we are thinking about this" then deprecation means "follow the commits minutely to see what actually happens". So please... a) reconsider deprecating anything that you are not sure that we need to remove and b) only remove things that pose a real maintenance burden. It really isn't fun updating a hoard of custom applications just because Apple has the resources to churn the API and Runtime as it is currently doing. I understand where you are coming from, but I don't have a good solution. We are rushed to do a new release this week, so we don't have a lot of time to come up with a solution. Where we have methods which are GNUstep specific, they ought to be in the additions library ... so assuming we get round to moving them, anyone using them will need to change their software to include the appropriate headers. A small change, but still one they need to be aware of. I agree that a change like this is hardly as radical as 'prepare for removal', but we still need to let developers know somehow, and we don't have a mechanism for telling them to "follow the commits minutely to see what actually happens". In fact, I guess they would ignore that anyway. What I was thinking of doing was marking things as deprecated (since the version macros let us do that, and autogsdoc will adjust the documentation accordingly), and putting something in the release notes to explain exactly what we mean by deprecated in this release (ie that a few things will go completely, but most will just be moved into the additions library and require different headers to be included). If you have a better idea of how to go about this sort of thing I'm very willing to listen (even time consuming alternatives if you want to volunteer to help out). I just don't want inaction to perpetuate the situation where people complain about lack of Apple compatibility. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 10 Jun 2008, at 15:28, David Ayers wrote: Richard Frith-Macdonald schrieb: Where we have methods which are GNUstep specific, they ought to be in If you have a better idea of how to go about this sort of thing I'm very willing to listen (even time consuming alternatives if you want to volunteer to help out). I just don't want inaction to perpetuate the situation where people complain about lack of Apple compatibility. Well I think the correct solution would be to use the version macros to hide the declarations in the Foundation/*h headers yet to re-declare them unconditionally in a corresponding GNUstepAdditions/*.h header. Perhaps I'm misunderstanding you ... but if you do that, then all existing source code would fail to compile because declarations would not be visible in the headers they are including now, but they wouldnt be including the new header they need. I want current code to continue to compile and work with no changes, but to warn developers that things are going to change before the next stable release. [I'm currently not sure whether GSCategories.h is currently includable by applications using GNUstep proper.] It is, and it's where I would expect most method declarations to move to eventually . ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: > Where we have methods which are GNUstep specific, they ought to be in > the additions library ... so assuming we get round to moving them, > anyone using them will need to change their software to include the > appropriate headers. A small change, but still one they need to be > aware of. Yet, a very different change. > I agree that a change like this is hardly as radical as 'prepare for > removal', but we still need to let developers know somehow, and we don't > have a mechanism for telling them to "follow the commits minutely to see > what actually happens". In fact, I guess they would ignore that anyway. I think the current approach may very well encourage ignoring deprecation warnings. It's not clear what the how the developer should act. > What I was thinking of doing was marking things as deprecated (since the > version macros let us do that, and autogsdoc will adjust the > documentation accordingly), and putting something in the release notes > to explain exactly what we mean by deprecated in this release (ie that a > few things will go completely, but most will just be moved into the > additions library and require different headers to be included). I don't think the release notes are the optimal place... but that may be personal taste... I would prefer the source or the headers. > If you have a better idea of how to go about this sort of thing I'm very > willing to listen (even time consuming alternatives if you want to > volunteer to help out). I just don't want inaction to perpetuate the > situation where people complain about lack of Apple compatibility. Well I think the correct solution would be to use the version macros to hide the declarations in the Foundation/*h headers yet to re-declare them unconditionally in a corresponding GNUstepAdditions/*.h header. [I'm currently not sure whether GSCategories.h is currently includable by applications using GNUstep proper.] Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: > > On 10 Jun 2008, at 15:28, David Ayers wrote: > >> Richard Frith-Macdonald schrieb: >> >>> Where we have methods which are GNUstep specific, they ought to be in >>> If you have a better idea of how to go about this sort of thing I'm very >>> willing to listen (even time consuming alternatives if you want to >>> volunteer to help out). I just don't want inaction to perpetuate the >>> situation where people complain about lack of Apple compatibility. >> >> Well I think the correct solution would be to use the version macros to >> hide the declarations in the Foundation/*h headers yet to re-declare >> them unconditionally in a corresponding GNUstepAdditions/*.h header. > > Perhaps I'm misunderstanding you ... but if you do that, then all > existing source code would fail to compile because declarations would > not be visible in the headers they are including now, but they wouldnt > be including the new header they need. I thought that this commit ... http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Headers/Foundation/NSString.h?rev=26621&view=diff&r1=26621&r2=26620&p1=libs/base/trunk/Headers/Foundation/NSString.h&p2=/libs/base/trunk/Headers/Foundation/NSString.h [http://tinyurl.com/3j3ysu] ... already breaks existing source code. But without providing an alternative header to include. But in fact it seems that many of those declarations already exist in GSCategories.h. Sorry I should have checked earlier. [Yet there are some declarations that are not there... not sure what should happen to them (maybe this is only true for -immutableProxy] So what I'm trying to say, is that we should insure that all those methods are declared in GSCategories.h without the version macros. And maybe add a comment in the Foundation files to indicate where these declarations have moved to. > I want current code to continue to compile and work with no changes, but > to warn developers that things are going to change before the next > stable release. Well if someone is using version macros now, they'll notice that the declarations are hidden. If not, I suppose they can't get warned with the current infrastructure. They'll notice once the declarations are removed from the file which should probably still contain a general comment about where declarations have been moved to. >> [I'm currently not sure whether GSCategories.h is currently includable >> by applications using GNUstep proper.] > > It is, and it's where I would expect most method declarations to move to > eventually ACK. Sorry for the confusion. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 10 Jun 2008, at 18:47, David Ayers wrote: Richard Frith-Macdonald schrieb: On 10 Jun 2008, at 15:28, David Ayers wrote: Richard Frith-Macdonald schrieb: Where we have methods which are GNUstep specific, they ought to be in If you have a better idea of how to go about this sort of thing I'm very willing to listen (even time consuming alternatives if you want to volunteer to help out). I just don't want inaction to perpetuate the situation where people complain about lack of Apple compatibility. Well I think the correct solution would be to use the version macros to hide the declarations in the Foundation/*h headers yet to re-declare them unconditionally in a corresponding GNUstepAdditions/*.h header. Perhaps I'm misunderstanding you ... but if you do that, then all existing source code would fail to compile because declarations would not be visible in the headers they are including now, but they wouldnt be including the new header they need. I thought that this commit ... http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Headers/Foundation/NSString.h?rev=26621&view=diff&r1=26621&r2=26620&p1=libs/base/trunk/Headers/Foundation/NSString.h&p2=/libs/base/trunk/Headers/Foundation/NSString.h [http://tinyurl.com/3j3ysu] ... already breaks existing source code. Thanks ... I made a typo and used the wrong macro name (fixed) With GS_API_VERSION(GS_API_NONE, 011700) it should change the validity of the methods in the GNUstep category from being always valid (no end version), to being valid up to release 1.17.0 Since the current stable/unstable branches are 1.14.x and 1.15.x I expect the next stable release to be 1.16.0 and the next unstable one to be 1.17.0 This should mean that in the next stable release the methods are still valid (usable), but autogsdoc marks them as deprecated, so people shoudl see that if they look at the header files or the documentation. No existing code should break. But without providing an alternative header to include. But in fact it seems that many of those declarations already exist in GSCategories.h. Sorry I should have checked earlier. [Yet there are some declarations that are not there... not sure what should happen to them (maybe this is only true for -immutableProxy] So what I'm trying to say, is that we should insure that all those methods are declared in GSCategories.h without the version macros. And maybe add a comment in the Foundation files to indicate where these declarations have moved to. I don't have time to decide where everything moves to in the next day ... I doubt that I even have time to be sure I find all the methods which are not in MacOS-X I want current code to continue to compile and work with no changes, but to warn developers that things are going to change before the next stable release. Well if someone is using version macros now, they'll notice that the declarations are hidden. If not, I suppose they can't get warned with the current infrastructure. They'll notice once the declarations are removed from the file which should probably still contain a general comment about where declarations have been moved to. autogsdoc parses the version macros to mark methods as deprecated when it knows there is a removal date in the macro. I think we could put more detailed documentation in the next bugfix release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
On 10 Jun 2008, at 19:25, Richard Frith-Macdonald wrote: But without providing an alternative header to include. But in fact it seems that many of those declarations already exist in GSCategories.h. Sorry I should have checked earlier. [Yet there are some declarations that are not there... not sure what should happen to them (maybe this is only true for -immutableProxy] So what I'm trying to say, is that we should insure that all those methods are declared in GSCategories.h without the version macros. And maybe add a comment in the Foundation files to indicate where these declarations have moved to. I don't have time to decide where everything moves to in the next day ... I doubt that I even have time to be sure I find all the methods which are not in MacOS-X But of course, if you want to add comments in the headers that would be great ... I suppose deciding where everything moves to doesn't really matter that much actually ... we can always change our minds later as long as we've warned people. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next stable release?
Richard Frith-Macdonald schrieb: > > On 8 Jun 2008, at 12:08, David Ayers wrote: > >> Richard Frith-Macdonald schrieb: >> >>> For the base library, reverting the license to LGPLv2 should be easy, >>> but I'd also like the next stable release to mark all non-macosx stuff >>> as deprecated ... on the basis that this would warn developers about the >>> intention to be *highly* macosx compatible. Then we could either remove >>> deprecated features (or move them to the additions library and >>> undeprecate them) at will in the unstable branch after the release. >>> >>> If people are happy with this approach, I will at least try to search >>> out and mark things as deprecated in the next few days, but if anyone >>> wants to help with that I'd appreciate it. >> >> I would like to voice my opinion that I agree that being *highly* Cocoa >> compatible /by default/ is a good idea with respect to making it easier >> to write portable apps. I'm also for moving the GNUstep additions to >> -baseadd. I'm even for renaming any extensions in the NS namespace to >> GS. I'm not convinced that deprecating all non Cocoa features is a >> desirable goal in itself. >> >> Yet we really need to make sure that we do not introduce last minute >> changes which affect applications in non-obvious ways. I think such >> structural changes are more fit for the beginning of a release cycle. >> >> I understand the contention wrt the intended longevity of a stable >> release so I don't want the to interpreted as a veto... it's just that I >> think we really need to think about the pros and cons wrt changing the >> public API (and possibly behavior) at this stage. > > I have no desire to remove anything from the public API at this stage > ... what I want to do is mark anything we might later want to remove (or > move to another location) as deprecated, so that the developers using > the release will know that their code should not depend on these > features. We need to give developers as much warning as possible ... > which means that in a new stable release, we really *must* deprecate > anything that we might be removing before the following stable release. > I'd rather deprecate things that we might later decide we want to > retain, than leave undeprecated something we than want to remove. > > I suppose that, in addition to marking GNUstep'isms as deprecated, we > should also deprecate anything that Apple have deprecated. I believe that marking features that will be merely moved to -additions as deprecated is misleading. To me deprecation means prepare for removal... i.e. adapt all your code. If it just means "we are thinking about this" then deprecation means "follow the commits minutely to see what actually happens". So please... a) reconsider deprecating anything that you are not sure that we need to remove and b) only remove things that pose a real maintenance burden. It really isn't fun updating a hoard of custom applications just because Apple has the resources to churn the API and Runtime as it is currently doing. Cheers. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSTableView editing problem [Was: Next stable release?]
Matt Rice wrote: On Fri, Jun 6, 2008 at 12:32 PM, Fred Kiefer <[EMAIL PROTECTED]> wrote: 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. no, i meant if you double click a cell, then type something and hit enter or tab keys after that the whole row is not redrawn (except for the field editor) and sometimes the whole tableview is blanked out the behaviour changes on different apps. I think we can kind of rule out NSTableView I tested the last known version that I know worked (r24478 of -make,base,gui,back) and that worked still... then i tested the svn head versions of make,base,gui,back with the r24478 version of NSTableView and that produced the same results. Thank you Matt that is a very interesting finding. I have spend quite some time now to test this problme, but failed to get down to the bottom of it. It would be best if you put it into our bug system, together with the test application you send me off line and all the findings you have up to now. I only tested with the current version of the NSTableView code, but I agree, what I see there looks right. But then where does the wrong result come from? NSTableView drawing right now is fairly susceptible to attacks by things setting it as needing display besides itself. see NSTableView.m (-drawRect:) it blanks out the background of the entire rect with [self drawBackgroundInClipRect:aRect]; and highlights the selection then draws the grid. but if you look at -drawRow:clipRect: if (i != _editedColumn || rowIndex != _editedRow) { does drawing stuff.. } this code is fairly old and uncommented what i recall it doing is not drawing the edited row or column because it doesn't want to draw over top of the field editor. This mechanism seems to work well, form the output I get, the right cells get redrawn after hitting return. It just doesn't get visible. Are we missing a flush somewhere? anyhow from the same version of NSTableView both working and not working it seems as though NSTableView doesn't set the edited row rect as needing display but either the field editor, or NSTextFieldCell or something else maybe is setting it as needing display that is my guess... anyways When finishing editing, the NSTableView sets the edited cell as needing display. Then the selection changes and both the old and the new selected rows get marked for needing display. All of this is correct. I even tried to hack into the NSView drawing mechanism and now get a report whenever drawRect: gets called and this also seems to be totally correct. Here is what I get after finishing editing cell 5/0 of your test application: 2008-06-08 18:47:05.419 foo[7021] Drawing view rect {x = 0; y = 80; width = 481; height = 32} 2008-06-08 18:47:05.420 foo[7021] Draw cell at row 5 col 0 in rect {x = 4.5; y = 81; width = 91; height = 14} 2008-06-08 18:47:05.420 foo[7021] Draw cell at row 5 col 1 in rect {x = 104.5; y = 81; width = 372; height = 14} 2008-06-08 18:47:05.420 foo[7021] Draw cell at row 6 col 1 in rect {x = 104.5; y = 97; width = 372; height = 14} 2008-06-08 18:47:05.420 foo[7021] Draw cell at row 7 col 0 in rect {x = 4.5; y = 113; width = 91; height = 14} 2008-06-08 18:47:05.420 foo[7021] Draw cell at row 7 col 1 in rect {x = 104.5; y = 113; width = 372; height = 14} 2008-06-08 18:47:05.420 foo[7021] Drawing view rect {x = 0; y = 0; width = 91; height = 14} 2008-06-08 18:47:05.420 foo[7021] Drawing view rect {x = 0; y = 0; width = 91; height = 14} OK, there is no reason to redraw row 7, but this wont do any harm. But all the rest is completely as expected. I will now look into the window flushing, if this is also correct, I am totally clueless. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTableView editing problem [Was: Next stable release?]
I was completely wrong here. The problem is at a totally different place. Look at the code in NSTextFieldsCell that Nicola changed a few months ago: - (void) drawInteriorWithFrame: (NSRect)cellFrame inView: (NSView*)controlView { /* Do nothing if there is already a text editor doing the drawing; * otherwise, we draw everything twice. That is bad if there are * any transparency involved (eg, even an anti-alias font!) because * if the semi-transparent pixels are drawn over themselves they * become less transparent (eg, an anti-alias font becomes darker * and gives the impression of being bold). */ if (([controlView respondsToSelector: @selector(currentEditor)] == NO) || ([(NSTextField *)controlView currentEditor] == nil)) { if (_textfieldcell_draws_background) { if ([self isEnabled]) { [_background_color set]; } else { [[NSColor controlBackgroundColor] set]; } NSRectFill([self drawingRectForBounds: cellFrame]); } [super drawInteriorWithFrame: cellFrame inView: controlView]; } } This basically means that a text field cell will only draw itself, when there is no editor for the containing control view. This is nice and fine, when the text field cell is the only cell of a text field, but in the matrix and table view case this stops all the cells in the controller from drawing themselves while there is an editor. How to get of this trap? We could check if the cell is the selected cell of its control view and only then not draw it in the editing case. This may work as a table view has no clear notion of a selected cell and so all cells will still get drawn, whereas matrix and normal control handle this correctly. Another possibility is to move the "don't draw" check into the control view. This looks better to me. A cell should always draw itself when asked to do so, the decision should be put somewhere else. Any better ideas out there? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTableView editing problem [Was: Next stable release?]
On Sun, Jun 8, 2008 at 10:57 AM, Fred Kiefer <[EMAIL PROTECTED]> wrote: > I was completely wrong here. The problem is at a totally different place. > Look at the code in NSTextFieldsCell that Nicola changed a few months ago: > Ahh, yes changing the below fixes it here i was confused because it is asked to redraw the edited cell frame, but in the case that it is, the code is doing what it should by not redrawing. > > - (void) drawInteriorWithFrame: (NSRect)cellFrame inView: > (NSView*)controlView > { > /* Do nothing if there is already a text editor doing the drawing; > * otherwise, we draw everything twice. That is bad if there are > * any transparency involved (eg, even an anti-alias font!) because > * if the semi-transparent pixels are drawn over themselves they > * become less transparent (eg, an anti-alias font becomes darker > * and gives the impression of being bold). > */ > if (([controlView respondsToSelector: @selector(currentEditor)] == NO) > || ([(NSTextField *)controlView currentEditor] == nil)) >{ > if (_textfieldcell_draws_background) >{ > if ([self isEnabled]) >{ > [_background_color set]; >} > else >{ > [[NSColor controlBackgroundColor] set]; >} > NSRectFill([self drawingRectForBounds: cellFrame]); >} > > [super drawInteriorWithFrame: cellFrame inView: controlView]; >} > } > > This basically means that a text field cell will only draw itself, when > there is no editor for the containing control view. This is nice and fine, > when the text field cell is the only cell of a text field, but in the matrix > and table view case this stops all the cells in the controller from drawing > themselves while there is an editor. > > How to get of this trap? We could check if the cell is the selected cell of > its control view and only then not draw it in the editing case. This may > work as a table view has no clear notion of a selected cell and so all cells > will still get drawn, whereas matrix and normal control handle this > correctly. > > Another possibility is to move the "don't draw" check into the control view. > This looks better to me. A cell should always draw itself when asked to do > so, the decision should be put somewhere else. > that seems alright to me, and appears to be what drawRow:clipRect: in NSTableView is already doing. i've looked at the bug report that code was added for but didn't have any luck reproducing it with the fix disabled... > Any better ideas out there? > no but thanks for looking into this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTableView editing problem [Was: Next stable release?]
Matt Rice wrote: On Sun, Jun 8, 2008 at 10:57 AM, Fred Kiefer <[EMAIL PROTECTED]> wrote: I was completely wrong here. The problem is at a totally different place. Look at the code in NSTextFieldsCell that Nicola changed a few months ago: Ahh, yes changing the below fixes it here i was confused because it is asked to redraw the edited cell frame, but in the case that it is, the code is doing what it should by not redrawing. - (void) drawInteriorWithFrame: (NSRect)cellFrame inView: (NSView*)controlView { /* Do nothing if there is already a text editor doing the drawing; * otherwise, we draw everything twice. That is bad if there are * any transparency involved (eg, even an anti-alias font!) because * if the semi-transparent pixels are drawn over themselves they * become less transparent (eg, an anti-alias font becomes darker * and gives the impression of being bold). */ if (([controlView respondsToSelector: @selector(currentEditor)] == NO) || ([(NSTextField *)controlView currentEditor] == nil)) { if (_textfieldcell_draws_background) { if ([self isEnabled]) { [_background_color set]; } else { [[NSColor controlBackgroundColor] set]; } NSRectFill([self drawingRectForBounds: cellFrame]); } [super drawInteriorWithFrame: cellFrame inView: controlView]; } } This basically means that a text field cell will only draw itself, when there is no editor for the containing control view. This is nice and fine, when the text field cell is the only cell of a text field, but in the matrix and table view case this stops all the cells in the controller from drawing themselves while there is an editor. How to get of this trap? We could check if the cell is the selected cell of its control view and only then not draw it in the editing case. This may work as a table view has no clear notion of a selected cell and so all cells will still get drawn, whereas matrix and normal control handle this correctly. Another possibility is to move the "don't draw" check into the control view. This looks better to me. A cell should always draw itself when asked to do so, the decision should be put somewhere else. that seems alright to me, and appears to be what drawRow:clipRect: in NSTableView is already doing. i've looked at the bug report that code was added for but didn't have any luck reproducing it with the fix disabled... OK, so I submitted this second patch. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
API for next stable release of base library
I'd like us to be able to make a stable release (1.14.0) of the base library early next year (before FOSDEM) and want to make sure that we get any reorganisation needed to keep the base library APIs stable for a long time done by then. Anything we want to deprecate/remove needs to be marked as deprecated by that release, so we can remove it in the next-but one release after it. Any reorganisation and additions of APIs replacing deprecated APIs needs to be in place by then, so that people can move from using deprecated to undeprecated APIs. Changes of instance variable layouts need to be done by then, so that code built against that release will work with later versions of the library (at least until the 1.16.0 release, and preferably longer). The sort of cleanups I'm thinking of are ... 1. Make certain that no private APIs are publicly exposed, so there is absolutely no chance of people using internal APIs accidentally and so that they would have to make a major effort to use them anyway (some people think they can manage changes in private functionality, and attempt to use it as a shortcut for writing portable/reliable code). 2. Audit instance variables in classes to make sure that privagte ivar's are all marked as such, and make sure that there is a way to add extra ivars to each class without changing the overall size of the ivars and/or the layout of the public ivars. 3. Clean up public extension APIs ... probably deprecate any odd bits and pieces such as optimisation hacks and convenience methods which only save a few lines of code ... to keep the API as a whole slim and easily understood. perhaps group together associated functions into class-based APIs, for a cleaner, more organised interface and so that users can extend/ override methods easily and generally stay within the object-oriented programming idiom. perhaps move the additions library GC classes into a separate library. perhaps look at naming conventions and orthogonality of methods in the other additions library classes. 4. Make sure that anything which can be declared 'static' *is* declared' static', to avoid clashes at link time. Do an audit of non-static symbols to help with this. Any ideas about how to do this sort of audit in practice, and minimise the work involved in doing a similar audit for later releases? My best idea at the moment is that using 'nm -g --defined-only' to list symbols will give us a base view of the exposed API, and if we keep a dump of that output we can use standard tools like sort and uniq in a shell script to let us know about changes ... so we can tell if we have accidentally added,changed, or deleted something. What API changes ought to be made? What base library classes still contain extensions which should be moved to the additions library? Which classes need ivar changes (to allow for later extension without having to change the ivar layout again). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev