[CF-Devel] CFEditor cleaning up

[Andreas Vogl]

in reply to Mark W.:

>
     
      > An editor version run from jar must either write the changes
     
     >
     
      > directly into the jar archive, or the editor must read a
     
     >
     
      > possibly changed extracted file version always before opening
     
     >
     
      > the one out of the jar (The latter is currently the case).
     
     >
     
     
     >
     
      New spells are not added very often, so [...] having these
     
     >
     
      files in the jar file itself (for the binary distribution) 
     
     >
     
      isn't a big deal I don't think.
     
     
That's true, but the problem is kind of a general one:
What if the editor wants to write to a resource file?

I think writing into the jar is kinda impossible. So it
will be better to keep the scheme with extracted (non-jar)
resource files being read first, if not available we look
in the jar.

This kind of policy won't affect the user a lot, but
it affects the way resources are managed internally and
how editor releases can and should be made.

>
     
      The 'easiest' thing would be to make a binary distribution 
     
     >
     
      the same time a server release is done.
     
     
Yes, I agree. It's simply the most work-efficient way,
presuming the process of packing the editor release is
trivial.

>
     
      > My vision [...] is that the "types.txt"
     
     >
     
      > file could become an inofficial documentation-standard
     
     >
     
      > for the Crossfire arch sysntax.
     
     >
     
     
     >
     
      I think I actually wrote some docs about adding fields to 
     
     >
     
      objects in the server (step of things to do). Something to
     
     >
     
      add to that is probably 'update the  types.txt in the java
     
     >
     
      editor'.
     
     
That would be cool. I looked in crossfire/doc and
couldn't find it though.

>
     
      The problem of course is there might be some cases where 
     
     >
     
      the developer still forgets to do this.  If they are still
     
     >
     
      using crossedit, they may not think about the java editor.
     
     >
     
      Hard to make it completely fullproof.
     
     
I'm completely aware that nothing is foolproof, especially
when it comes to stuff like documentation. ;-)
It would already be good if developers are aware of it.

>
     
      > would people ever look into a directory called
     
     >
     
      > "resources/conf" in order to customize the editor?
     
     >
     
     
     >
     
      As above, hard to say.  They first need to look at the java 
     
     >
     
      editor. I think if there is good documentation, this may
     
     >
     
      not be much a problem - a top level README describing the
     
     >
     
      different directories and important files in each (like 
     
     >
     
      the types.txt) may be enough.
     
     
Hm, maybe you are right. A README file could do for the start,
as there won't be a lot of other stuff in the root dir then.

>
     
      Feel free to ignore my comments - i'm not writing any of the 
     
     >
     
      code that is doing all of this.
     
     
I appreciate your comments neverthless. ;)

>
     
      On a slightly related note, similar usage issues goes toward 
     
     >
     
      the arch directory and need to collect them.  While MT's point
     
     >
     
      is valid that people should (may) add new images to the arch
     
     >
     
      directory, actual usage shows this doesn't happen 
     
     >
     
      very often. So ideally, if the editor could take advantage 
     
     >
     
      of the collected archetypes and image files, this saves the
     
     >
     
      need for a player to have yet another distribution (eg, they
     
     >
     
      grab server, editor, and maps, and don't worry about archs).
     
     
There's another reason for having an option to load arches
from the collected files: It would cost less time to load.

Unfortunately, that's not an easy thing to do.
The directory structure in the arch dir is used to cathegorize
the arches in the left-side choosebar of the editor.

If we load from the collected files, the editor should still
have a way to put all background tiles for example
into a seperate "cathegory". Together with rewriting the loader,
this is a chunk of work, and the packaging issues also have to
be considered, as you said.
It's hard to tackle such a can of worms when the
editor is "already working fine"... :-)

I agree it should be done at some point. So far I always
found other things of higher priority though.


AndreasV