Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/29/06, Yann Chachkoff [EMAIL PROTECTED] wrote: But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). I believe that the random map generator also needs the same seperation of common and server, at least the way it is compiled at the moment. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
On 1/29/06, Mark Wedel [EMAIL PROTECTED] wrote: I would suggest the following mappings (for both binaries and package names) crossedit - crossedit Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). The problem is that at the moment there is no real replacement for crossedit (CFJavaEditor doesn't work well enough, it doesn't even have undo support). I don't think that crossedit needs to be abandoned though, splitting it out into a separately distributed tarball/CVS module would suffice, if the functions that it uses from the server code are well documented/commented, then any changes to these functions in the server module should backport to crossedit as and when that is needed. Meanwhile, the server/ common/ distinction could go, and everything be rearranged more logically. (this would also have the advantage of allowing crossedit to be ported to a modern toolkit without breaking the server). gcfclient - crossfire-client gcfclient2 - crossfire-client2 (or crossfire-client-gtk2) cfclient - crossfire-client-x I don't know if there is any official standard on this, but if anything, it would seem the standard is that it be toolkitname-program name. Eg, gnome-terminal, xterm, etc. It is a little unclear to me where gtk ends and gnome begins - on my system, I see a lot of gnome-* programs, but not many gtk-* programs But given that, I'd suggest gtk-crossfire-client, gtkv2-..., x-crossfire-client, etc to keep that naming convention. The thing with this is that currently all distro packages are called crossfire-client or crossfire-client-gtk. If I am on a debian (or similar) system and install a program, I always try and run it using the name of the package, only if that fails do I bother to grep the filelist for bin/, sometimes if it is something I don't care about, then I ignore it and find something else to do the job instead. having the binary being tab-completable from the start of the package name is a good thing, especially when the .desktop files aren't installed properly. of course, should there ever be a KDE client, then the rules change somewhat, the name krossfire-klient would be obligatory. Perhaps have a generic crossfire-client script that looks for the different programs and tries to run the 'best' one available. I'd be interested to know how 'best' would be determined there. CFJavaEditor - jcrossedit See note above about naming. That said, I'd be a little less concerned about this one, as I doubt there is as much confusion in this (at least on the unix side, you don't run it directly anyways - you're going to use ant or have to do the java command by hand, so that is sort of hidden). java -jar CFJavaEditor.jar I don't in fact know if this can be reasonably assembled into a package or installed. But once again, making a script called jcrossedit that runs the JVM with the needed flags (I recall the default memory sizes really aren't big enough) may be the way to really go here. The default memory size is ok if you only open a couple of maps, and is a lot better than it used to be since tchize fixed it a while back. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff [EMAIL PROTECTED] wrote: I am not opposed to porting crossedit to gtk however. The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was yes, because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be no - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the common and server subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). How about not removing things from the game, a novel idea, no? How about proposing an alternative to let's keep everything unchanged forever - a novel idea for you, wouldn't it ? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
I am not opposed to porting crossedit to gtk however. But if my favorite editor is removed outright... java is not an option. However crossedit works great (IMHO) now, so there really is no reason to change it. All this constant talk of removing things is displeasurable, thus my retirement for a time. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I am also waiting on some new features aswell. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. How about not removing things from the game, a novel idea, no? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] renaming binaries (was: Moving server towards a modularized system?)
If crossedit dissappears then I dissapear. I guess that is what you all want though. Should CF fork? --- Mark Wedel [EMAIL PROTECTED] wrote: Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
