[crossfire] Importing the GTK+ editor in SVN
Raphaël Quinet
raphael at gimp.org
Wed Jul 16 14:53:42 CDT 2008
On Wed, 16 Jul 2008 20:12:15 +0200, Yann Chachkoff <lauwenmark at ailesse.com> wrote:
> > it is fast (e.g., drawing walls or other features on a large map is much
> faster than with gridarta)
> >
> Wouldn't it be more productive to work on improving Gridarta's speed where it
> is perceived as an issue, instead of importing a whole new project and having
> to learn and maintain another large chunk of code ?
Well, there are two things that I can reply to that:
- A part of the speed difference is probably due to coding issues and
it may be possible to improve gridarta from that point of view. But
another part is due to a different design of the user interface. So
it's a difference in the process of editing the map, and I am not
sure that those who are familiar with gridarta now would like to
have the user interface redesigned. For instance, gcrossedit has
different editing modes that control what the mouse pointer does.
When you are in "Place" mode (to add some items to the map), you can
"paint" the map with walls very quickly. With gridarta, you use
keyboard modifiers or mouse buttons to select the action that you
want to perform, instead of having a concept of "modes" or "tools".
This is useful in some cases, but in the end you need many more
mouse clicks to place a large number of walls or floors in a map.
- Nobody is forced to "learn and maintain another large chunk of code".
Those who are interested in it are welcome to contribute, but those
who aren't interested can focus on other parts of crossfire. I will
be the initial maintainer. If I am hit by a truck tomorrow and
nobody else wants to work with that code, then that's fine: it will
slowly rot and maybe become irrelevant after a while, but it will
still be usable by those who want to use it, just like the old X11
crossedit has survived for many years.
Hmm... and a third thing: the code for gcrossedit is probably smaller
than you think. The support libraries have a total of about 10k lines
of code, and we could probably remove half of them if we don't want to
support the client-server protocol or the deliantra extensions. The
editor itself is less than 5k lines of code. For comparison, the
current crossfire server has 30k lines of C code in the "common"
directory, 50k lines in the "server" directory, and so on for a total
of more than 160k lines of C code, Python code, Perl code and Makefiles.
So the code for gcrossedit is relatively small.
> > it has a nice way to display the properties of all map objects as you move
> the mouse around
> >
> Again, any reason why this couldn't be implemented in Gridarta ?
That could be a nice addition to Gridarta. I never said that it
could not be implemented also in Gridarta. I was simply pointing out
that this feature is nice and it exists today in gcrossedit.
> > it has less installation dependencies than gridarta,
> >
> Wrong. It depends on GTK and Perl. Gridarta depends on 1.6 JRE. I don't see
> how it would in any way imply "less dependencies".
Sorry, I should have said "it has less dependencies for Free Software
users". Gridarta depends on the Sun JRE 6, which is currently
non-free. I know that many users do not care about the details of the
license, but I do. Fortunately, the JRE will soon be really free, but
we still have to wait a bit. Also, regarding version 6, there is no
package for it in the default Debian stable distribution (etch), only
in testing or unstable. This is the same for most Linux distributions
released last year (not all users run the latest and greatest).
Or to put it simply: if you consider the most popular Linux
distribution (Ubuntu) and install its default selection of packages,
you will have Perl and GTK+, but you will not have a version of Java
that can run Gridarta.
Anyway, maybe we are both right regarding the dependencies - but we
have different sets of users in mind.
> Besides that, it introduces yet another language (Perl) which is by far not
> the easiest one to maintain (Does "Write-Only Language" sound familiar ? :) ).
I agree that Perl can be a nightmare to maintain if the code is not
well structured. But it is not a new language for Crossfire. There
is still more than a dozen Perl scripts in the server code, including
the often used 'collect.pl' script. On the other hand, Java is not
used anywhere in Crossfire, so it could be argued that Gridarta is the
one using "yet another language". But I don't want to argue about
languages. As I said above, those who are not interested in
maintaining that editor do not even have to look at it.
-Raphaël
More information about the crossfire
mailing list