Re: Changes I've been thinking of...

[Richard Frith-Macdonald]

On 12 Oct 2009, at 10:50, Sergii Stoian wrote:

> Fred Kiefer wrote:
> > Sergii Stoian schrieb:
> > > 2009/10/9 Riccardo Mottola <address@hidden>
> > > > 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.