[CF-Devel] CVS commit: CFJavaEditor

[Andreas Vogl]

In reply to Bob Tanner:

>
     
      > o The biggest Problem is the new formatting. [...]
     
     >
     
     
     >
     
      Hmm, I thought I changed emacs to do this. :-( Point 12 of
     
     >
     
      the programming_guide specifically says to use 4 spaces. I'll have
     
     >
     
      to double check it.
     
     >
     
     
     >
     
      I've added the appropriate info to the programming_guide to
     
     >
     
      configure emacs and vim according to the 4 space rule.
     
     
Oh, I'm glad to hear this is only a minor flaw from your emacs
settings. There's no problem then. The new ArchObject.java
file you committed testwise is now perfectly formatted.

>
     
      > o Why is the source code suddenly in
     
     >
     
      > "/src/org/crossfire/editor/CFEditor"?
     
     >
     
     
     >
     
      This is the default setup that the Enhydra build evironment wants.
     
     [...]

Well, for my part I didn't even include the Visual J++ Project file
into CVS. It might have increased my personal convenience but this
file would be garbage for anyone using a different editor.

Anyways - To solve this debate: I suggest we try and leave it as
is, at least for now.
It's not a big problem, paths can always be changed.

>
     
      > [...] The new Package name [...] doesn't work. 
     
     >
     
      > [...] I would greatly prefer the *.java files back in
     
     >
     
      > the "/CFEditor" dir, where they belong.
     
     >
     
     
     >
     
      This is why I specifically asked for a linux branch. [...]
     
     
The Java Editor is all about Platform-Independency.
Doesn't it seem paradoxical to have both a Linux- and a Windows-
branch for an explicit cross-platform software?

Moving some directorys after checkout is less work than
synchronizing two branches I believe.

>
     
      I renamed the package, to org.crossfire.editor.CFEditor, because
     
     >
     
      some day there could be other editors, or other java code for
     
     >
     
      this project. So the package name becomes important to prevent
     
     >
     
      name collisions as well as an organization issue.
     
     
Naming collision is hardly an issue for the CF Java Editor.
I doubt there will ever be a second Java Editor, let alone
one with identical name, trying to import classes from the
first one.

>
     
      > The new policy of extracting all resources out of the .jar file
     
     >
     
      > doesn't seem like a good idea to me. [...]
     
     >
     
      > Resource files (like icons and config files like "autojoin.txt")
     
     >
     
      > should be easy to access and easy to modify. [...]
     
     >
     
     
     >
     
      What is the standard location, cross-platform, for resource files?
     
     >
     
      Shoving them into the jar gives a default cross-platform location. 
     
     >
     
      Does the average end user really need access to the icons? I can't
     
     >
     
      think of any reason why, unless they want to change the image of the
     
     >
     
      save button, etc.
     
     
Why would directory locations be platform-independent?
And yes, why not change icons? Some of the icons, like the highlighting
frame (for the map-view) might depend a lot on personal taste.

>
     
      I do have code for putting resource files into the users home
     
     >
     
      directory, using System's user.home property, for things like
     
     >
     
      autojoin.txt, but I've found that not all Window JVM's set this
     
     >
     
      property, so it can be an issue.
     
     
Why not simply leave it unpacked? Seems quite practical to me...

>
     
      The jar also makes for easy packaging in linux. 1 file
     
     >
     
      contains everything. Drop it into the classpath and your done.
     
     
A jar file does not make for easy packing in Windows.
And even for Linux, don't forget that there are people
much less accustomed to java than you are.
After all, the editor is designed for users, not developers.

>
     
      > If someone commits a corrupt jar file, will that be
     
     >
     
      > noticeable from the cvs diff? I guess not - though effectively
     
     >
     
      > all resource files are lost.
     
     >
     
     
     >
     
      What happens if someone commits a corrupt .png file in the server
     
     >
     
      code page?
     
     
Yes, that has happened numerous times on CF cvs.
But it means only loss of *one* resource file, which is
usually easy to fix.

And it's not like I'm making this up: There have already been
corrupt jar files on cvs.
It is much more likely to build a jar file in the wrong way,
than to come up with a corrupt .png file.

>
     
      > Well, I hope that doesn't sound too criticizing.
     
     >
     
      > I'm sorry that I didn't come up with these issues earlier, but I
     
     >
     
      > was busy and didn't have time to test the new stuff before.
     
     >
     
      > Besides, I wasn't really aware of these changes and nobody asked me.
     
     >
     
     
     >
     
      I asked: [...] You responded: [...]
     
     >
     
      What do I need to do to keep you more aware?
     
     
Specifically, you said you were "trying to put Makefiles and build.xml
(ant) files around CFJavaEditor".

You may call me simple-minded, but this did not imply to me that you
were about to change directory structure, package names and resource-
location-policy. :-)

My reply: "I'm very happy if someone works on good makefiles for
the Editor" might have also shown my lack of deeper understanding.


Anyways, there's nothing we can't settle.
If you only fix the formatting, I'm already quite happy. ;-)


Andreas