[Adonthell-devel] On editors and their GUI

[Alexandre Courbot]

Ok, now I can't stand anymore, I have to get your thoughts about this
problem.

Eventually I've decided to make proper editors. That is, editors with a
GUI (heresy!). And a real one! :)

This means no more using Adonthell's own GUI, which will remain simple &
efficient for the game input, but using an external library like GTK.

First, I assume that soon we'll put the editors in separated packages,
and split the game engine into libraries (one per module). That way the
editors can actually be distributed separately and there will be much
less code redundancy.

As for the GUI, I first thought about doing just like Kai: GTK and C++.
But I'd like to do them as far as possible (while keeping them
user-friendly and so on), so I can then switch to other tasks. So after
a look at all the GUI that exists extensive testing, I think I'll use
WxWindows and Python, that is, WxPython (http://www.wxpython.org)

WxWindows is a great cross platform GUI that implements anything you'd
need. Moreover it's very easy to program.

Python allows great development speed - I realized it while doing my
university projects in Python. Editors aren't critical when it comes to
speed, and after testing some apps written in wxpython I really couldn't
tell the difference with a C/GTK one.

One could argue that the Windows deployment of apps written in wxPython
could be a problem: we can't require all our artists who use Windows to
install Python and all the shit to get their Python apps to work.
Fortunately, there is a great deployment utility called py2exe which
packs any Python application into a single Python-independant, self
containing Windows executable.

So if nothings speaks against it, I think I'll work with WxPython.

On to the "real" issue now, that would happen anyway regardless of the
GUI and the language: display of Adonthell objects in non-Adonthell
visuals. What I mean is that, we're fine as long as we want to draw to a
SDL surface, but if I want to display, say, the frames of an animation,
I'll have to draw them to a WxImage.

The "worst" solution would be to "shadow" our editable classes (that is,
animation, object/character model, map) into classes that would be used
for the editors only and that would display to WxImages. That is,
rewrite them. I won't insist on all the mess it'd be.

Another way, recompiling the different Adonthell modules several times:
the first time for SDL, and another time including another image.h file
that targets WxImages instead of SDL_Surfaces. But, ouchie, that's not
good: that'd mean having several libraries, one libgfx for SDL, one
libgfx for WxWindow, and so on for the mapobjects, ... Kinda sucks.

The "best" way: if we could load at runtime the "backend" to use, and
have our modules (gfx, map, ...) function with whatever backend we load.
Having something similar to what is done in Clanlib for instance: in
Debian, you can install the Clanlib backends you want, and the core of
the library doesn't rely on one in particular. Problem is, when you
compile high-level files, like animation.cc, the SDL include files are
always parsed, so I don't see how we could get the independancy.

As you can see this issue is closely related to the backend feature we
discussed some time ago. Might be a design issue actually.

Anyway - I haven't thought much about this issue. Comments and ideas are
welcome, as usual! :)

See ya,
Alex.
-- 
http://www.gnurou.org