[crossfire] crossedit and the Java editor (was: renaming binaries (was: Moving server towards a modularized system?))

[Alex Schultz]

Yann Chachkoff 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.
>  
>
 From what I have saw, the java editor is very flawed (not impossible to 
fix, however IMHO not very maintainable), largely due to various fixable 
bugs, but more importantly the language being unfamiliar to most of our 
devs, and therefor "bad things happen" such as mistakes that cause it to 
be slow (As I understand, there are lots of slow java programs, not 
necessarily because of the language, but coding mistakes that are common 
in it for C coders and such).
The old crossedit is also very flawed due to a combination of it's 
widget set, and rather messy code (so messy that it's even worse than 
the Java editor likely).
IMHO, what would be BEST (by no means least effort, in fact likely most 
effort), would be a rewrite of crossedit (different toolkit, make sure 
the code is organized), and a big cleanup of the 'common'/'server' 
separation.
I might be willing to do this myself even once I get a bit more time on 
my hands.

>>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.
>  
>
As I understand, his reason is because Java is a non-foss dependency. 
IMHO this is not a worthless point, it doesn't prevent me from using the 
java editor, but it does leave a 'bad taste in my mouth'.

>>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). 
>
I believe the way that it is dependent on the server code is actually a 
rather eloquent thing; why maintain two separate copies of the map 
saving and loading code? Of course, that said, the current state of the 
split between "common" and "server" IS very hackish and somewhat ugly. 
However, I see making the separation more distinct and cleaner, would be 
something that would help with modularization, not so much fo any 
advantage in making features easier, but for making the code more 
maintainable. So if anything, the boundary between "common" and "server" 
shouldn't be removed, but should be fixed/cleaned up and solidified.

Alex Schultz