Hi Fred,
Le 21 nov. 08 à 10:29, Fred Kiefer a écrit :
What is worrying me more than this accidental things is the feeling
of a
growing split between our two projects. To start of with a personal
opinion, I think that Etoile is by far the more interesting project.
In
GNUstep we only try to reimplement concepts defined by Next and Apple
whereas Etoile seeks to come up with concepts for the future. So I
really understand why you are working on Etoile and not GNUstep,
although I choose differently.
Now what are the signs I see for a split?
- Etoile people stopped to contribute to GNUstep (code and bug
reports).
This may be due to GNUstep offering everything they need or because
they
prefer to fix problems in their own code and keep the changes there.
I think we wanted to get this release out quickly, since the previous
one was 15 months ago, and we also lacked some manpower as explained
by David and Nicolas.
In my case, the result is that I haven't followed GNUstep development
very closely this year. Even if it's true I haven't contributed
directly to GNUstep, I haven't stopped to submit bug reports and
patches. The problem is that I failed to give regular feedback for
these bug reports and I haven't updated my patch submissions to match
the comments you made. That's entirely my fault, I'll remedy to that.
We really depend on GNUstep, keeping changes as workarounds in Étoilé
can only be done as a temporary solution. Moreover some changes cannot
even be patched in categories. For example, NSOutlineView drag and
drop isn't fixed in Étoilé, because the fix involves static variables
and the only way to get it fixed is that I resubmit my patch.
There may be other areas where the code from the two
projects would need some more integration, but I am most ignorant of
that. (another bad sign)
Aside of Camaelon and WildMenus, I'll probably have some requests for
EtoileUI. For now, I'm not entirely clear on what the final needs will
be, that's why I haven't made any requests in this sense. I haven't
really worked on this framework since September. I'm going to be
working on it again it and take this opportunity to eliminate the
existing workarounds. In the next months, I'll also get a clearer
picture of what can eventually be done at GNUstep level to better
integrate EtoileUI and AppKit.
I think this drifting apart is bad for both projects. It has drained
GNUstep from some of its most active developers and contributes to the
stand still of GNUstep's theming interface. And for Etoile it leads to
problems when users try to install Etoile on a different version of
GNUstep than the one the code was tested with. It also results in
users
not getting bug fixes from GNUstep because of Etoile methods
overriding
that code not being adjusted.
Yes.
If we put aside Camaelon and WildMenus, the overriden code is really
limited though. The only few patched methods I'm aware are in EtoileUI
and may be two or three others in EtoileFoundation.
What about a shared review of code and concepts in Etoile that
proved to
be valuable and of interest in GNUstep and then an effort to
incorporate
the relevant parts of that back into GNUstep? Setting up once more a
clean interface between our projects.
Yes, I agree we should do that.
This would be better discussed on gnustep lists I think, but just to
raise the topic… it would be nice if we could synchronize some of our
next releases with the gui/back releases. What would be even better
would be to have some changes (such as NSOutlineView patch I
mentionned or Camaelon ones) merged as quickly as possible into
gnustep-gui stable version once they get accepted. I don't know if
that's possible because the changes are quite substantial. But this
would allow us to get next Étoilé releases packaged for package system
where only GNUstep stable versions are offered as packages.
May be we can come up with some transitory solution over six months or
so. Once Camaelon/WildMenus are almost fully merged back into GNUstep
and EtoileUI is stabilized, the situation will be better, we should be
able to rely on GNUstep stable rather than unstable.
In the more-long term, we might encounter similar troubles with the
text system when we start using advanced features. This could require
a lot of changes to it or even a rewrite, hence to rely on GNUstep
unstable to get Étoilé features work as expected. May be I'm wrong on
this one though.
Cheers,
Quentin.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev