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=26621view=diffr1=26621r2=26620p1=libs/base/trunk/Headers/Foundation/NSString.hp2=/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=26621view=diffr1=26621r2=26620p1=libs/base/trunk/Headers/Foundation/NSString.hp2=/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?
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 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?
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?
[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 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
