Re: Changes I've been thinking of...
Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); - move general code 'back' to 'gui' (gsc if I remember correctly); - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Gregory Casamento wrote: On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian wrote: Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... Forking would be bad for the project in general. In my opinion a fork would only cause confusion. If what you're referring to here is a branch within the GNUstep repo, then that's fine... but I fork of the project isn't really going to be productive. Sure, this time it's better to say as branch not fork. Also, I'm wondering what the reason for the fork would be. See my mail to Fred. GC -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 12 Oct 2009, at 10:50, Sergii Stoian wrote: Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I understand the frustration with having to deal with breakage like that, but I'm going to ask you to think about it a bit more before deciding to branch. Where I work we had the problem with changes to the gnustep code breaking our production code, so we took a stable snapshot and worked with that for a long time. This was all OK until we wanted to use some new features, so we updated to using a more recent version, and used that version on our test system from some weeks before making a release and rolling out to live systems. But then on the live systems our customers managed to find/trigger bugs which had been missed on our test system ... so I'm now thinking that it's probably actually a lot safer to update the test/development systems as frequently as possible so that we maximise the amount of time during which any bugs can be discovered and fixed. My current feeling is that it makes sense to branch, and work with the branch to make big changes, but the aim should be to merge that branch back into trunk as quickly as possible (and I mean within days or at most a couple of weeks, not several weeks or months). That way, your branch doesn't end up depending on behaviors which have changed (usually been fixed) in trunk, and you don't get to a state where it's a horrible job to merge again. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); Sounds good. - move general code 'back' to 'gui' (gsc if I remember correctly); Or perhaps into a library that the backends can link with if they need it? - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). That's really great X and window manager interaction are the biggest technical problem areas I see in GNUstep. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. I don't think you need to worry about that ... frankly, whatever people say about appearance is largely irrelevant since it doesn't really effect the coding you do. The only impact is that we want to design/implement things so that theming is possible, but as far as the backend code goes, that really just means following good design principles of making code modular, clean, and simple .. and that's clearly what you want to do anyway. Certainly nobody is going to try to force you to work on changing the appearance of the GUI when you want to work on improving the backend. I, for one, am very glad to know that you want to work on the backend code as I think the lack of polish in the X interaction (focus, fonts, clipping, cut and paste, drag and drop, menu handling, etc) is the main technical issue making GNUstep apps look bad in comparison with Gnome apps for instance. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Richard Frith-Macdonald wrote: On 12 Oct 2009, at 10:50, Sergii Stoian wrote: Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I understand the frustration with having to deal with breakage like that, but I'm going to ask you to think about it a bit more before deciding to branch. Where I work we had the problem with changes to the gnustep code breaking our production code, so we took a stable snapshot and worked with that for a long time. This was all OK until we wanted to use some new features, so we updated to using a more recent version, and used that version on our test system from some weeks before making a release and rolling out to live systems. But then on the live systems our customers managed to find/trigger bugs which had been missed on our test system ... so I'm now thinking that it's probably actually a lot safer to update the test/development systems as frequently as possible so that we maximise the amount of time during which any bugs can be discovered and fixed. My current feeling is that it makes sense to branch, and work with the branch to make big changes, but the aim should be to merge that branch back into trunk as quickly as possible (and I mean within days or at most a couple of weeks, not several weeks or months). That way, your branch doesn't end up depending on behaviors which have changed (usually been fixed) in trunk, and you don't get to a state where it's a horrible job to merge again. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); Sounds good. - move general code 'back' to 'gui' (gsc if I remember correctly); Or perhaps into a library that the backends can link with if they need it? Backends already linked against gui library, why we need another? Do you mean separating all GS* classes (from back and gui) into separate library? If so it may have sense to separate AppKit code from GNUstep specific one. - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). That's really great X and window manager interaction are the biggest technical problem areas I see in GNUstep. ...and no documentation for how it works. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. I don't think you need to worry about that ... frankly, whatever people say about appearance is largely irrelevant since it doesn't really effect the coding you do. The only impact is that we want to design/implement things so that theming is possible, but as far as the backend code goes, that really just means following good design principles of making code modular, clean, and simple .. and that's clearly what you want to do anyway. Certainly nobody is going to try to force you to work on changing the appearance of the GUI when you want to work on improving the backend. I, for one, am very glad to know that you want to work on the backend code as I think the lack of polish in the X interaction (focus, fonts, clipping, cut and paste, drag and drop, menu handling, etc) is the main te
Re: Changes I've been thinking of...
Hey, I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. To achieve what you want, ou can jsut install the latest release instead of tracking SVN trunk for svn. Since I have several computers, I arrange to have one with stable release and one with the latest stuff. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); xlib is far from unused, so leave it in. xdps can indeed be removed, since the X11 extension never worked... I read that it was removed, but it is still there. But inany case Fred should look at that and do things correctly not to break anything. - move general code 'back' to 'gui' (gsc if I remember correctly); Discuss that with Fred, which is the maintainer. - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). I give you 100% reason here. Things should work well and reliable on WindowMaker, so that you have a reference implementation. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. Understandable. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
A fork is pointless. All of the points you made are things that would be welcome changes in GNUstep. On Mon, Oct 12, 2009 at 5:52 AM, Sergii Stoian wrote: > Gregory Casamento wrote: >> >> On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian wrote: >> >>> >>> Sure, you're right! I'm start thinking that fork of gui+back for some >>> period >>> of time is not such silly thing... >> >> Forking would be bad for the project in general. In my opinion a fork >> would only cause confusion. If what you're referring to here is a >> branch within the GNUstep repo, then that's fine... but I fork of the >> project isn't really going to be productive. > > Sure, this time it's better to say as branch not fork. > >> Also, I'm wondering what the reason for the fork would be. > > See my mail to Fred. > >> GC > > -- > Sergii Stoian > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
