[CF-Devel] CF Java Editor

Mark Wedel mwedel at scruz.net
Tue Mar 6 01:42:54 CST 2001


Michael Toennies wrote:
>
     
     
     >
     
      I have do some research how we can do a new editor in java.
     
     >
     
     
     >
     
      In my opinion is java a superior language for tools like our editor
     
     >
     
      (and crap for serious programs :).
     
     
 Java has the one advantage is that one editor will work on all platforms. 
We'll ignore the performance issues.

>
     
     
     >
     
      Most menus/parts (combo boxes, tile management) are part of the java
     
     >
     
      gfx&windows system.
     
     
 Not really a big deal in some sense, as there are of course many toolkits for
C.

>
     
     
     >
     
      Now, i have found 2 packages.
     
     >
     
     
     >
     
     
      http://mids.student.utwente.nl/~michtoen/CFJavaEditor
      
      
     >
     
     
     >
     
      Gridder is a open map editor for some game.
     
     >
     
     
     >
     
      Well, it has incuded some source and is exactly the kind of program
     
     >
     
      we want (of course we will change style, screen arangement etc.).
     
     >
     
     
     >
     
      But its a good example and it will give us the whole "skeleton" of the
     
     >
     
      java program.
     
     
 I'm all for code re-use, but there is always the issue of whether is easier to
try and re-use someone elses code that your not familiar with.  It also depends
on how re-usable the code is.

 But I think the big issue really will be whoever (if anyone) decides to make a
new editor.  Basically, the person can pretty much do whatever they want, so if
they want to use java, python, perl, tcl, or whatever, that will probably be up
them.  Now granted, if this person chooses something that no one else likes, the
amount of help given may be limited (from both the perspective of people may not
want to spend much time spending time on something they can't use.  Or if the
language/toolkit is something that others don't know, the best they can give is
theoretical help.

>
     
     
     >
     
      2nd problem is that you need a png lib for java. There are some out,
     
     >
     
      including
     
     >
     
      sets like the jai from sun - but they are all very large.
     
     >
     
     
     >
     
      i found a small, fast and free package (from sixleg). I haf tested it, they
     
     >
     
      works fine and
     
     >
     
      fast.
     
     
 My personal thought is that if there is a well established/standard package for
png support available out there, size of it probably is not especially relevant
(you did not qualify very large.    Is that 1 MB? 10 MB?  )

 Anyways, I say this in the sense that if we choose one that works now but may
not be really well supported, we may run into a problem down the road where due
to changes in the png objects or something it no longer does the task we need,
and then time has to get spent fixing it up for a new api.

>
     
     
     >
     
      Well, thats nearly all we need, its really easy to do.
     
     >
     
      Now, who will?
     
     
 I'm not sure how you quantify it as really easy to do.

 It strikes me that dealing with reading the archetypes and maps, layering of
the maps, meaning of certain fields, etc, is not a trivial amount of work. 
Which is the bright side of going with C - at least all that code is still there
(and if you look at the current crossedit code, it is even more so - depending
on your point of view, all that would need to be done for that is to choose a
more portable library, as except for a few missing features, everything is
already done there).

    
    


More information about the crossfire mailing list