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 _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
