Re: GNUstep and Etoile

[Quentin Mathé]

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.