[Adonthell-general] Adonthell French Meetic Report - GUI, SDL, Clanlib

[Alexandre Courbot]

As you might have noticed, I'm going to post a bit more on the list from
now! ;) Not that our finals are finished (haven't started even!), but I
spend two days at Joël's for university work, and we of course ended
talking about Adonthell and how suck it was that we have no time yet to
code on it. It's going to change soon, however! And anyway, the come of
new developers and the happypenguin awards were too much - we gotta get
back to Adonthell! So here is the report of what we discussed about.

First, 0.4 is going to be a lot of work for everyone. We thought that it
was very important to scale down the implementation time as much as
possible so we get the engine running quickly. This implies, using the
right tools and stopping reinventing the wheel all the time. This is
very true for the GUI - making a GUI is a titan work, with geometry
shit that is a pain to code, and there are plenty of them available. So
at first we looked at some GUIs we could rip from other projects. Since
we are very demanding(we need a complete GUI, with theming capabilities
an so on), we only found two that fits our requirements:
-Paragui (http://www.paragui.org)
-Picogui (http://www.picogui.org)

Unfortunately, both have drawbacks: Paragui is highly dependant on SDL,
and therefore is inapt regarding our politic of having our own wrapper
interface (which would require the GUI to have a backend interface).
Paragui handles backends, but seems to be unable to share the screen
with something else. Moreover, it is driven by a server/client
architecture, which is too much for us. So after looking at these two
candidates, we came to the conclusion that none is realistically
hackable to fit into Adonthell :(

It also came back to our minds that Clanlib has a great GUI componant,
but that would also mean dropping our wrapping policy to make our client
program completely dependant of Clanlib and unportable outside of it.
Which still means supporting main platforms but forcing users to use
Clanlib instead of another library.

So it look like there is a choice to be made here: we could save lot of
time not having to re-implement a GUI, and probably other stuff, if we
decide to stick to a specific library instead of keeping our "all
portable" approach. I'd have some regrets doing so, but considering the
amount of work that would be saved, I'd like to open the discussion
about it.

Which library we would choose, is another problem. I'm starting being
upset about SDL. No major updates sinces ages - and still none planed.
Nothing new on the mailing list, which has become a helping list instead
of a development one. Low performances under X/Linux, very poor hardware
acceleration capabilities. In front of that, stands Clanlib which I'm
re-examinating right now: very clean design, seems to be very well
documented, still under active development(seen a 0.7 around!), OpenGL
backend for Linux, great GUI, wrappers to audio mixers, ogg vorbis,
network, that is, everything we need! The only I'm afraid of being the
size of the beast.:) But still, it's really cool. Maybe Kenneth and Ingo
could relativize what I'm saying (is it *that* cool?), or give their
opinion about that. I'm not advocating in favour of any solution yet -
but I wanted to highligh the problem, and the short and long term
consequences of both choices on the project. Of course, this would only
influence the client side of the game - that is, not that much. And
right now, despite of our claims for portability and
library-independance, we only support SDL and are now having troubles
because of that. So in practise it's just like we were using directly
SDL without our abstraction layer.

So... Opinions? Suggestions?

Alex.
-- 
http://www.gnurou.org