[Top][All Lists]
[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...