gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Etoile-discuss] GNUstep and Etoile


From: David Chisnall
Subject: Re: [Etoile-discuss] GNUstep and Etoile
Date: Fri, 21 Nov 2008 13:21:40 +0000

On 21 Nov 2008, at 09:29, Fred Kiefer wrote:

I don' want to make too much fuzz about Etoile people not posting their
new release on the GNUstep mailing lists.

This one is entirely my fault - I completely forgot.  Sorry!

Nor about not waiting for the
next GNUstep gui and base release, which is due in a few days and could
even have been brought forward a bit, if requested by Etoile.

The main issue here was twofold:

Firstly, our release was originally scheduled earlier, but then pushed back because we needed LLVM 2.4 to build some key components (and LLVM is horrendously bad at maintaining API compatibility between versions, so, unfortunately, we have to sync to their releases). The new release of GNUstep was not proposed until after we had intended to have already shipped.

Secondly, I am using a really old version of GNUstep trunk and was under the impression that the latest stable release roughly corresponded to what I was using. I was told that our release had been tested on the latest GNUstep release, and mentally inserted the word 'stable' into this, not realising until afterwards that there were some significant issues (such as not compiling with the latest GCC in C99 mode) that remained in the most recent GNUstep stable release.

For future releases, I will set up a test environment with the most recent GNUstep stable and make sure that we can work with that.

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.

Étoilé is only possible because of the strong foundation we inherit from GNUstep, and I would like to see more co-operation between the projects.

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.

The reason I'm running an old version of GNUstep trunk is that I haven't encountered any limitations in GNUstep recently. There are a few places where I've added categories on GNUstep-provided objects adding or fixing things, but:

1) I have always sent copies of these categories to the GNUstep team when I have written them. 2) They have always been #ifdef'd around so that they are not used when a more recent GNUstep is used.

I see this as a strength of Objective-C, rather than a limitation. If GNUstep had been using C or C++ then we wouldn't have the opportunity to push out quick fixes like this, we'd have to wait for the next stable release.

- Etoile not adopting to changes in GNUstep. Here I may be looking on
the wrong source code, but at least in Etoile trunk Camaelon and Wild
Menus ignore many of the changes made to GNUstep drawing code over the
last two years. 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)

We talked about the menu issue recently. In the run-up to Étoilé 0.5, our implementation needs a lot of polishing, and I think the best way of doing this is to get all of the horizontal menu support code merged with GNUstep and draw on the whole width of the screen by default or in the rectangle provided by the menu server if one is running. My hope is that the EtoileMenus bundle will be removed by 0.5 and only EtoileMenuServer will be needed.

Camaelon is a known issue, caused largely by Nicolas not having any time for GNUstep or Étoilé while writing his thesis. Unfortunately, no one else really knows Camaelon well enough to make major changes, so this code has been largely untouched for about a year. Looking in subversion, the last person to touch Camaelon was me, three months ago. I just reordered a couple of lines to try to eliminate some artefacts. Before then, 8 months ago, Quentin updated it to match your changes to flipped view behaviour in -gui. All other changes were 14 or more months ago.

I hope Nicolas will have time to work more on Camaelon soon, now he has finished his thesis[1]. I keep meaning to look at the code and see why it isn't caching the pixmaps on the server, since this means I usually have to turn Camaelon off when I use remote X11.

The long-term plan for Camaelon has always been to push as much as possible back up to GNUstep and only include parts that don't match the goals of GNUstep remain in Étoilé.

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.

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.

I think that would be great. We are having a hackathon around Easter (current suggestions are May and March, exact date still to be finalised) and it would be really great if we could have a decent GNUstep presence there. Lars is also trying to get a FOSDEM dev room for GNUstep, Étoilé, and OpenGroupware, so there will be lots of opportunities in the first half of next year for GNUstep and Étoilé developers to spend some time hacking together.

One thing I would like to see in GNUstep is some way of redirecting a view to an off-screen surface so that we can then use something like XRenderComposite or OpenGL to display it. This would allow us to write something like CoreAnimation easily. We can currently do something hackish getting an NSImage from a view (I think Quentin does this in EtoileUI), but having it supported natively by -back would be much better, since (on X11) we could keep the images server-side instead of doing expensive copies (on other platforms we might be able at least to keep them in VRAM).

David

[1] I also hope he will have time to port WebKit and write a Smalltalk IDE...



reply via email to

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