Re: [crossfire] Importing the GTK+ editor in SVN
But so far, all the objections have been from developers involved with Gridarta and saying basically don't work on a new editor. Please, get your facts straight :) Yann didn't work on Gridarta unless I'm mistaken, and I definitely didn't (unless using it or making feature requests makes us developers :)). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
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
Re: [crossfire] Importing the GTK+ editor in SVN
On Sun, 20 Jul 2008 14:14:52 +0200, Lauwenmark [EMAIL PROTECTED] wrote: Le Saturday 19 July 2008 21:57:35 Raphaël Quinet, vous avez écrit : 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). [...] 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 agree and I respect your choices. However, to put this in perspective for this discussion, you could have opted to improve the existing gtk2 client, considering that gtk2 works well on all platforms (including Windows and MacOS X) and the more immersive experience is mostly a matter of how you design the user interface. You could have decided to add a full-screen mode to the existing client, allowing more freedom in the placement of the various elements of the user interface (for comparison, GIMP is also based on gtk2 and supports a full-screen mode for editing). Yet you have decided to start something different. That's fine by me and I wasn't among those who argued against its inclusion in SVN. But please don't claim that importing gcrossedit into SVN is significantly different from what happened back then. 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. The dependency on a non-free version Java has been a problem for me. This is what encouraged me to look at gcrossedit more than a year ago. And then I discovered that it had several features that were better than gridarta (faster painting of maps, especially for the initial layout) and that allowed me to stop using the old X11 crossedit or using gridarta from machines running non-free software, and to switch to gcrossedit instead. So although my initial motivation was to look at something that did not depend on non-free software, it has shifted now to more technical motivations because I saw that some differences in design could improve the workflow. And regarding Java, there is a subtle difference between get rid of Java (I don't remember ever saying that) and I prefer to work on something else (which is my personal opinion). I should also add that I spend many of my days at work writing proprietary code using Java and Eclipse. But when I'm not working and when I'm wearing my free software hat, I prefer to stick to the ideals of free software and avoid anything non-free. And I am passionate about it, as you can see... 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; [...] This is not correct. JRE6 is not available in the main Debian repositories. It is only available in the non-free repositories (for Debian testing/unstable, or as a backport for etch). So installing Sun's JRE6 is still an issue for those who only use free software. [...] 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. It wasn't a purely rhetorical question, although it may be now. There are several arguments that I would have accepted. For example, if Mark (as the official maintainer of crossfire) had said that he would have prefered to see gcrossedit living as a separate project, then I would have accepted that regardless of his reasons. If someone had said that creating a separate project on sourceforge would be better to encourage the usage of gcrossedit by more projects (e.g., daimonin) then I would have considered that as a useful objection. I might have argued that I prefer to focus only on crossfire, but still this would have been a useful comment. Also, if someone had said that there are already too many sub-projects in crossfire SVN and we should focus on removing some of them rather than adding new ones, then I would also have considered that as a valid reason for importing
Re: [crossfire] Importing the GTK+ editor in SVN
On Fri, 18 Jul 2008 22:03:33 +0200, Andreas Kirschbaum [EMAIL PROTECTED] wrote: Hi, I am one of the founders of Gridarta and I still maintain the editor. So expect my viewpoint to be slightly biased ;) 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. And if you argue specifically about 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). Although I have no interest in working on a Java client or editor (because I already write enough Java code at work and I am looking for something different in my spare time), I never argued that the Java client or editor should be somehow banned from crossfire SVN. Also, the argument (as stated in another mail in this thread) that map makers may want to use Debian stable, is not an argument: the gce download page states that libglib2.0-0 version 2.12.6-2 is needed; Debian stable has 2.12.4-2 only. 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. 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). Note that the latest version of gde has added some dependencies on Perl modules that are not part of a default install, but these dependencies are not needed for gcrossedit so they will probably be removed soon. Besides, the code that I will put in SVN is forked from an earlier version of gcrossedit (before the compatibility with crossfire was removed). Just FYI, some of Gridarta's features which I didn't find in gce (and which are not at all hidden but easily accessible though menus in Gridarta): [...] Thanks for the suggestions. It looks like you overlooked at least two of the existing features of gcrossedit, because they are very similar to what you described: multiple pickers that can be customized with lists of frequently used items, map validation and map normalization done by a separate script. But most of them sound interesting so they will be added to the TODO list. The only feature that I would probably not add is the auto-updater because I prefer to have that done via the native packaging system of the target platform. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
Hi, I am one of the founders of Gridarta and I still maintain the editor. So expect my viewpoint to be slightly biased ;) I already mentioned on IRC some of the reasons why I think that this editor [gce] is interesting: it is fast (e.g., drawing walls or other features on a large map is much faster than with gridarta) It is known that Gridarta is quite slow on huge maps. The main reason is a less-than-optimal implementation of the undo stack. Fixing this would need a fair amount of work without having much effect for real maps: Crossfire maps generally should not grow too large; instead tiled maps should be used. Therefore I (still) consider fixing this issue a waste of time since more important features are pending. Besides that, my observation with gce was just the opposite: I did create a map with gce's default size (20x20 tiles). I hardly could edit this map because gce's display updates were sluggish at best: just moving around the mouse cleared the map view when the tooltip moved. I had to stop doing anything (including mouse movements) and wait 3-5(!) seconds until the map view was repainted and I could continue. The test was on the exact same machine that I use for Gridarta development and testing; gce is the version available for download on the Deliantra web site. , it has a nice way to display the properties of all map objects as you move the mouse around Yes, this is a nice feature; I plan to add a similar one to Gridarta. , it has less installation dependencies than gridarta I just can agree with Yann here that this is not correct. Gridarta needs only Java 1.6; no other external libraries are needed. Building from source additionally needs ant. According to the download web site gce needs at least Perl, libgtk2, and libglib2. For the implicit free software meaning: OpenJDK is about to go into Linux distributions. Therefore it is not (anymore) an argument for me. Also, the argument (as stated in another mail in this thread) that map makers may want to use Debian stable, is not an argument: the gce download page states that libglib2.0-0 version 2.12.6-2 is needed; Debian stable has 2.12.4-2 only. Windows users can also use OpenJDK (I guess), or just download and install Sun's JRE to run Gridarta. Not sure how easy it is to get Perl (and GTK2) installed on a Windows machine. FYI: gcj fails to compile Gridarta because gcj does not comply to the Java Language Specification (apart for other issues in the class libraries). I filed a bug report more than four months ago [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410]. It is still in state NEW. , etc. See below for a list of missing features. SCNR ;) However, the current version also has some drawbacks: [...] All these drawbacks are just technical issues that can be fixed. Therefore these issues are not really arguments against the editor (for me). (Without actually having guessed how much work is needed to get them fixed.) If there are no objections against this plan, I would like to import the code in SVN as soon as possible. Given that Gridarta is still in active development (more than 4000 commits since the project start about two years ago), and having invested much time (I did more than half of all commits), I do object. My main reasons are: - We (Crossfire) do not have that many (active) developers. Therefore splitting these few into the maintainance of multiple helper-applications that basically do the same seems just a waste to me. We should rather focus on the game itself. With game I mean: in-game content, a decent client (which runs on Windows, Linux, and hopefully on Macs), and a stable server [roughly in this order], but definitely not the maintainance of redundant helper-applications. Also, the main reason why we (Christian Hujer, Daniel Viegas (both Daimonin developers), and me) did start the Gridarta project was to fight resource splitting: at that time there have been two projects, Crossfire and Daimonin (I'm ignoring Angelion because it did use the unmodified Daimonin editor). Both projects did use and maintain similar editors. Our idea was to join the developers of both projects to get more development power. The intended outcome is a (mostly) unified editor which shares most of the basic functionality but has special features needed by either project. For Crossfire this merge process already did pay off since I could take over many features from Daimonin to Crossfire. Besides that I got quite some (constructive) feedback from Daimonin map makers. That said, I think starting a new editor would basically mean to split off Crossfire from Gridarta: having an editor part of the project (IMO) declares it as the official Crossfire editor. Which in turn means we (the Crossfire developers) are at the same state as two years ago: two editors to maintain (crossedit+CFJavaEditor vs. gce+Gridarta) with just a hand-full of developers. - Gridarta
Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 15:40:32 -0500, Rick Tanner [EMAIL PROTECTED] wrote: A couple of questions: At what state of completion(?) is a user HOWTO manual for the map editor? As I said in a previous message, the current code is not very friendly to first-time users. Although there is a tutorial available on the web (http://www.deliantra.net/editor_tut.html) explaining how to set up the editor and start editing your first maps, I think that some of these instructions should be part of the source tree. So although that web page provides some material that could be used as a starting point for creating a HOWTO, there isn't one yet in the package. I think an install HOWTO is probably the most critical, then followed by ~ a user manual (which is very important as well.) I agree. Like in other free software projects, I am planning to add two files at the top of the source tree: INSTALL (describing how to build and install the stuff) and HACKING (giving recommendations to whoever wants to contribute). Currently, there is not even a README. Note that building it is not very difficult. Basically, you do: perl Makefile.PL make make install You can also add PREFIX=/some/path to change the default installation path. But the INSTALL file should explain more than that: it should list the dependencies and explain how to install them if they are missing, give advice about where to install the editor, etc. Also, building the editor is one thing, but you also have to run it. The current version requires that you set the environment variable CROSSFIRE_LIBDIR at least for the first time you start it. This something that I would like to change so that the initial start would be a bit more user-friendly. What about official releases? Is there a volunteer to manage those? Well, I guess that I will be the first volunteer. Making a source code release is easy. I don't know what to do about the Windows binary releases, though. The Deliantra guys provide a package for Windows users, but currently I don't have the tools for doing that myself. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 21:01:07 -0700, Mark Wedel [EMAIL PROTECTED] wrote: I have no issues with it being added to part of SVN. Thanks! [...] - With that above note, it means that all that crossfire can really limit is if it is in SVN or not. Raphael can continue to work on it in either case. And for that matter, could create another project on sourceforge to hold the editor. Exactly. I was surprised by some of the previous comments questioning if we need a new editor. But this is not a new editor: it has existed since several years (although not very visible due to the tension caused by the CFplus project). The code is only looking for a new home after its current maintainers have confirmed that the only option for restoring the support for the original crossfire (broken a few months ago) is to fork the libraries used by the editor. So question is not about whether it should exist or not, but whether it should be imported in the crossfire SVN tree or if a new project should be started in sourceforge or elsewhere. I think that the first option is much better, that's why I asked. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
*sigh* if only the list could be so lively for content-related stuff... I globally agree with Yann. Also this is code no one here knows, it'll take a while to get into it, bla bla, but you do what you want with your time :) *goes back to his hole* -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
On Wednesday 16 July 2008 Raphaël Quinet wrote: [...] I already mentioned on IRC some of the reasons why I think that this editor is interesting: it is fast (e.g., drawing walls or other features on a large map is much faster than with gridarta), it has a nice way to display the properties of all map objects as you move the mouse around, it has less installation dependencies than gridarta, etc. However, the current version also has some drawbacks: it is likely to fail with a confusing error message the first time you start it, the user interface has many features and shortcuts that are a bit hidden (such as the absence of visible scrollbars), there is no main window, etc. That's why I would like to work a bit on that, and especially improve the experience for first-time users. If there are no objections against this plan, I would like to import the code in SVN as soon as possible. Sounds good to me. Having more editors is not bad as long as there are folks willing to support them. Gene Alexander -- ERA Computers Consulting http://www.eracc.com Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 20:12:15 +0200, Yann Chachkoff [EMAIL PROTECTED] 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 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 21:53:42 +0200 Raphaël Quinet [EMAIL PROTECTED] wrote: 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. Well, I'd like to note that actually, a Free Software Java 6 JRE does exist today in the form of IcedTea6. It is available in Ubuntu (see http://packages.ubuntu.com/hardy/interpreters/openjdk-6-jre) and Fedora. I've been using IcedTea6 myself for little while and have had no issues including in usage with Gridarta (in fact, memory consumption seems slightly lower for some reason but I'm not completely certain). In addition at least the Fedora build does pass Sun's Java Test Compatibility Kit. So in other words, we do actually have Free Java 6 today. As far as bringing another editor in, my stance is mostly neutral however I don't think it would do much good. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple of questions: At what state of completion(?) is a user HOWTO manual for the map editor? I think an install HOWTO is probably the most critical, then followed by ~ a user manual (which is very important as well.) What about official releases? Is there a volunteer to manage those? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIflzAhHyvgBp+vH4RAoVgAJ9xDMmCYwV9SNSdw+hGw6A4snU81gCgpD/7 9/vfgZ3ABvo6YBa1Vgumqus= =vs5q -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
I have no issues with it being added to part of SVN. I won't go over the different points raised in the conversation, but just some quick thoughts: - Within crossfire, there has never really been any standard set of programs that must be supported. So just the fact it gets added to SVN hardly means that all developers need to support it, and in fact, there are various pieces right now where that really is not the case. - If over time/through lack of support it does no longer work, it can always get removed. - It's impossible to force anyone to work on anything when folks are contributing their time freely. While there may be 'better' things to work on (and different people may have different ideas what should be worked on), getting them to do it may not be possible. If the user doesn't have any interest in working on that, it just won't happen. - With that above note, it means that all that crossfire can really limit is if it is in SVN or not. Raphael can continue to work on it in either case. And for that matter, could create another project on sourceforge to hold the editor. It's not clear to me that is any better than having it under the crossfire tree. Documentation stating is current state could be included. If other folks use it, it would seem worthwhile. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
Hi, I would like to contribute several improvements to the GTK+ editor gcrossedit (a.k.a. gce, now gde). Whereas the issue of having parallel clients is to me not a problem, there seems some greater advantage to have a unified editor, but, so long as both are maintained at a high degree of compatibility with the server, I see no reason not to accept CF friendly projects where there is a party interested in maintaining it. There seems little point to me to murmur about diluting efforts. People will always work on what interests them, and not necessarily what someone else wants them to work on. Though my CF development time has dried up at the moment, I'd have more inclination to work on a non-Java editor due to where skills lay - not that I particularly have a problem with Java save that it would be a new learning curve when one has already climbed much of steeper parts of the C/GTK curve. And, in real life, I use C, but Java as yet has not entered my particular work environment, and I prefer to leverage hobby/work cross-pollenation. Also noted that getting the tool chain configured to build Gridarta and JXClient was an ordeal I would not wish on anyone. For the experienced Javanator, I am sure it would not be, but we aren't all in that camp. Besides a client uses GTK and uses a tool chain that is common with this editor, and whatever one feels about perl, it is still a broadly used tool. In all, pulling a hard line on having only one editor is not something I want to do. If there are no objections against this plan, I would like to import the code in SVN as soon as possible. None here, though a nod is given to some of the arguments against. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
