[CF-Devel] CFEditor cleaning up

[Mark Wedel]

Andreas Vogl wrote:
>
     
      in reply to Mark W.:
     
     >
     
     
     
>
     
      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.
     
     
  Yep - that would seem reasonable.  It means a user could also have whatever 
versions of the file in the directory if they want to override the default file. 
  Probably a little extra code to do so.


>
     
     
     >
     
     
     >>
     
     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.
     
     
  I imagine it can be made pretty trivial.  For the rest of the crossfire stuff, 
its basically update the version string in the makefile or configure.in script, 
rebuild the files, and do a 'make archive'.

  Its a little more time consuming (for me) for the server/client, as I then 
unpack that archive and make sure it all compiles properly, etc.


>>
     
     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.
     
     
  Hmm..  I'm pretty sure I wrote some docs, but don't see them in CVS.  Maybe I 
was going to put them in - I'll have to see if I have them stored away someplace.



>
     
     
     >
     
      There's another reason for having an option to load arches
     
     >
     
      from the collected files: It would cost less time to load.
     
     
  Yep - probably a lot less time to load, depending on how good your system is 
about caching disk access.


>
     
     
     >
     
      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"... :-)
     
     
  Any reason the editable field can't be used for sorting like crossedit does? 
Note one difference there is the editable field is a bitmask, so in crossedit, 
an item can appear in multiple categories.  Not sure how easy that is to do.

  I would think the loading of archetypes shouldn't be that difficult - the 
editor can obviously handle more than one arch definition in a file, so having 
one file with 1000 entries shouldn't be any different.  But the categorization 
code would need to get changed.

  The loader for images may need work - I'm not sure how the java editor 
currently deals with faces - I'm guessing that it reads the arch, and looks for 
the faces in the same directory and associates them with the arch itself?

  And if you actually wanted to do the different image support schemes, it also 
gets trickier.  Editor doesn't seem to support that right now, so probably no 
rush to get that functionality in.

  As a side note, I personally think it may be friendlier to alphabetize the 
tabs for the object selector instead of them being in directory/load order, 
which isn't always the friendliest when I know I want the 'floor' tab.