On 12 Oct 2009, at 10:50, Sergii Stoian wrote:
Fred Kiefer wrote:
Sergii Stoian schrieb:
2009/10/9 Riccardo Mottola <mul...@ngi.it>
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