[CF-Devel] CFEditor cleaning up

[Andreas Vogl]

Michael Keuchen wrote:

>
     
      Modifications to the build scripts are no problem.
     
     >
     
      There is only one unchangeable condition for this scripts to work:
     
     >
     
      All source files must be in a root package or a subpackage of it.
     
     >
     
      Source files out of packages (like the old CFJavaEditor class) are
     
     >
     
      not recognized by the build file. 
     
     
I propose the following directory structure (on CVS):
Btw, the latest sixlegs png library works as you've used it.
------
CFJavaEditor/
    CFJavaEditor.jar <- working archive
    ...         <- configuration files like autojoin.txt
    icons/
    HelpFiles/
    system/
    make/
        ...     <- build scripts for various OS
    lib/
        png.jar
    src/
        CFJavaEditor.java
        cfeditor/
            ... <- editor classes
------

Now, I believe there are two issues that we need to discuss:
First, the way jar/non-jar execution and resource files work together
(and somewhat related, the way releases should be made).
Second, the thing about package names.

1. About the resource files

Currently it works like this: First, the editor looks for the
resource (config) files at the default place (this is root).
If any resource file is not found, the editor trys to get it
as system resource from the jar. If that fails too, an
errormessage is written and the file is really missing.

This behaviour has the advantage that the editor can both be
executed as jar package and directly from the java classes.
Besides, it is easy to use modified resource files, no matter
which way you run the editor.

Therefor I don't want to have changes that make it impossible
to run the editor from anything other than a jar package.

Note that your version of the editor contains such changes.
The method "getIcon()" in your CGUIUtils.java fetches icons
only from jar. If the application is not run from jar, it
crashes. This is something I don't want.


2. About package names

First of all, you cannot delete directorys in CVS. Thanks
to Bob Tanner there's already a load of unused empty directorys
on CVS. Moving between directorys in CVS is a royal pain -
so much for flexibility.
I don't want clicking through all those subdirs either.

Second, Crossfire on the whole is not a java project.
If you start using java conventions, you're in fact
alienating from the rest of the project.

Third, what if the used domain-name stops to support Crossfire?
What if the main site switches? Then we have to
move all those directorys again. We're not a company
owning our domain after all.


3. Releases

There can be two releases. The "developer release" which is
effectively a copy from CVS, and the "mapmaker release" which
could have the following structure:

------
CFJavaEditor/
    CFJavaEditor.jar
    icons/
    HelpFiles/
    system/
------

Later, the icons and system dir could also get stuffed into
the jar file. In the end only jar and HelpFiles will remain.


Some misc. answers following...
>
     
      [...] What of the files would be changed by
     
     >
     
      users? Surely not the help files, the icons and the "system"
     
     >
     
      PNG pictures, but what about these four:
     
     >
     
      - autojoin.txt
     
     >
     
      - spells.def
     
     >
     
      - typenumbers.def
     
     >
     
      - types.txt
     
     >
     
      Are they meant to be changed by a user?
     
     
Yes - meant to be changed by users. Also updated more often.
They are very important files.

>
     
      > > - Separating the PNG support from the CFEditor code.
     
     >
     
     
     >
     
      O.K., please check it.
     
     >
     
      (BTW: That's the typical outcome of forking development.)
     
     
Checked your stuff and it works. I'm not sure what you mean
with your comment, but the fork was unavoidable.
And since the png code is marginally small, there was
absolutely no need to hurry with changing that.
In fact, it even made things easier as you could run the
whole editor with "javac" without much hassle.

>
     
      There's one more thing I have to tell you.
     
     >
     
      My first intention for changing the editor was to have an
     
     >
     
      editor for Tabacha. [...] I turned back the changes and
     
     >
     
      made the version you see. Two changes, that make sense, remain:
     
     >
     
      The image size is now a constant (in IGUIConstants:
     
     >
     
      TILE_XLEN, TILE_YLEN) and some code in ArchObjectStack is
     
     >
     
      moved to a separate private method "generateFaceName".
     
     
These two changes are fine.


Andreas

-- 
GMX - Die Kommunikationsplattform im Internet.
     
     http://www.gmx.net