[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sergii Stoian
Subject: Re: Changes I've been thinking of...
Date: Mon, 12 Oct 2009 15:12:55 +0300
User-agent: Thunderbird (Windows/20090812)

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 <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?

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 technical issue making GNUstep apps look bad in comparison with Gnome apps for instance.

Don't get me wrong, Richard. I'm not willing to split GNUstep project efforts. I'm just want to minimize discussion of what should I change and get closer to 'Stop talking start coding' principle. The most easiest way to do this is making step aside and try to implement these sort of things mentioned above as I think it should work/look (for example, make good gui interaction with WindowMaker and not discuss should it or not have good interaction with GNOME). That's why I'm talking about fork/branch.

As for branch I'm afraid this task is not so simple and will take more time then I guess (assuming real life work, family and so on). Anyway if I'll have good results in the near future it's better then nothing.

Sergii Stoian

reply via email to

[Prev in Thread] Current Thread [Next in Thread]