[crossfire] Importing the GTK+ editor in SVN

[Lauwenmark]

Le Saturday 19 July 2008 21:57:35 Raphaël Quinet, vous avez écrit :

> Slightly, yes. :-)  I don't think that it is necessary for me to
> reply to each sentence in detail.  I will just say this: do you realize
> that what you have written can be summarized as "I have worked on
> solution X and it works, and there is already a lot of code written
> for it so I do not want to let others work on solution Y"?  Of course,
> I am deliberately exagerating what you said, but it could be interpreted
> like that.
>
> By the same reasoning, Gridarta should not have existed, because there
> was already the old X11 crossedit. 
>
Yes, you are exagerating a bit. The Athena-based editor was unsatisfying at 
the technical level - one very good point raised back then was that it was 
impossible to easily port to Windows.

> using crossfire SVN, then again the same reasoning would have prevented
> jxclient from being included.  Why include jxclient which had less
> features than the existing clients, especially when a lot of code was
> already written for the existing clients and they were actively
> maintained?  Well, because some developers were interested in working
> on something different (in that case, a Java client).
>
No, not at all (and I'm well placed to know what I'm speaking about, since *I* 
was the one who initially wrote JXClient). The goal was not write a "Java 
client" - there was already such a project somewhere else on SourceForge. The 
long-term goal was to provide a client that was (1) portable and (2) provided 
a more immersive gaming experience without sacrificing playability.

In fact, early work was actually performed towards an C, SDL-based client, 
which would have used the common codebase of the current C clients. This 
changed when it became obvious that the codebase was unnecessarily complex and 
cluttered; it was then easier for me to rewrite a possibly cleaner base from 
scratch than tackling the daunting task of cleaning up the mess.

Back then, I cannot say that the clients were "actively maintained" - 
gcfclient had quite a lot of bugs, and the intend was clearly not to solve 
them, but rather to develop a GTK2/Gnome client to replace it. Moreover, the 
switch to Java came at about the time when work towards CF 2.0 started - so, 
it seemed rather logical to take the opportunity to break the historical 
continuity with the old clients, and propose a single solution based on a 
cleaner code base. That's why JXClient aimed at supporting only trunk, and I 
made no effort to make it work with branch.

So no, the purpose was not to work on a "Java client" - the purpose was to 
work on "a better client", regardless of the technology used behind it. Use of 
a specific language never was part of the initial design requirements.

I also question the goals pursued by the new editor - so far, the only solid 
one advanced seems to be: "get rid of Java". What makes me think so is that 
all the possible UI advantages it comes from were obviously never discussed 
with the Gridarta developers before this discussion (Ragnor may need to 
correct me on this); if they were the real, most important reason for the 
change, then I admit I'm quite surprized nobody ever asked for such important 
features to be included in Gridarta.

> I never argued that the Java client or editor should
> be somehow banned from crossfire SVN.
>
The Java editor is not part of the Crossfire SVN, so it is a question that has 
no meaning.
Regarding the Java client, I again can answer: there was quite a strong 
opposition to it at first; however, I finally did include it in the SVN anyway. 
Why ? There are two main reasons for this:

(1) Most of the critics summarized as: "I don't like Java";
(2) Nobody had anything better to put on the table.

(1) was (and still is) an interesting philosophical point to discuss. However, 
Crossfire is not a philosophical project - it is a game one. Real, base 
questions are not things like: "Where do I stand on the metaphysical level", 
but rather: "Is the technology up to the task ?", "Is there any advantage 
using it ?", "Is there anything playing against using that ?". Back in the 
day, apart the all too predictable "Java is slow" (which has been proven false 
in the case of JXClient), no other technical point was underlined.

(2) Adresses the "duplication" question - would have it been duplicated effort 
? Was it sane to work in parallel with the "mainstream" client line ? The 
answer is that back then, there were no other development attempt to provide a 
different user interface, and nobody was very interested on working on this. 
The only other new client project at that time was the Gnome2 client, which 
was mostly developed without much - if any - dialog with the community 
regarding design decisions. So there was IMHO no duplication of efforts, since 
nobody else was ready to improve the UI of the existing client. Add to this 
that it was roughly the time when branch and trunk got separate, which further 
strengthened the idea of "making something new for the new game version", so 
to speak.

> I never argued that the Java client or editor should
> be somehow banned from crossfire SVN.
>
Yes, but you asked if there was any objection to your plan, while I never did, 
for the reasons stated above.

> Despite what is written on the gde download page, the version of
> gcrossedit that I have been using since last year works fine on Debian
> stable.
>
So does Gridarta, as Sun's JDK/JRE works fine with Debian stable.
As a side note, the JRE6 is available in the official etch backports, so 
installing it is not really an issue; actually, maybe I should document this 
on the ailesse web page for the sake of completeness.
For the record: the ailesse Gridarta daily builds are created on a 
Debian/Etch-powered system.

> Also, at least for the stable versions of the distributions
> that I use or have access to (Debian, Ubuntu, OpenSUSE, Novell SUSE
> Linux Enterprise Desktop and Fedora), the default installation of each
> of these distributions included Perl, glib and gtk+ as part of the pre-
> installed packages (no additional download or selection of non-standard
> packages).
>
Yet neither OSX nor Windows have those installed by default, so the default 
availability of dependencies works both for Java and GTK/Perl.

***

At the risk of sounding rude (but I've a Registered Evil Lad(tm) reputation to 
defend), I really wonder why you asked if there was any objection, since you 
obviously already made up your mind. If you plan to include it in the SVN 
regardless of any counter-opinion given, then by all means do so, and stop 
wasting time in what appears to be a purely rhetorical question by now.

(Yes, once more I sound overly negative and bashing - I guess somebody has to 
play the role of the bad guy in every discussion :))

Y. Chachkoff