[CF-Devel] RE: [Crossfire-cvs] CVS commit: CFJavaEditor

[Bob Tanner]

Quoting Andreas Vogl (
     
     andi.vogl at gmx.net
     
     ):
>
     
      o The biggest Problem is the new formatting. The linux tabs turn out
     
     >
     
        completely corrupt in Visual J++ (Windows).
     
     >
     
        Please convert all tabs into spaces, if that is possible. That is
     
     >
     
        the only way to keep the formatting platform-independant.
     
     >
     
     
     >
     
        Besides, I actually liked my old formatting with 4 space indent.
     
     >
     
        And I believe MichToen did so too. But nevermind on that one...
     
     
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.

>
     
      o Why is the source code suddenly in
     
     >
     
      "/src/org/crossfire/editor/CFEditor"?
     
     >
     
        Did you try to hide it or something?
     
     
This is the default setup that the Enhydra build evironment wants. Plus it
allows all source code to be located in 1 directory. It's more a requirement of
the Enhydra build env then anything else.

>
     
        This new directory strucure might be handy in *your* editor, it
     
     >
     
        definitly is not in mine. Besides, to my knowing it is convention
     
     >
     
        that Package name and directory path are identical. Visual J++
     
     >
     
      enforces
     
     >
     
        this. The new Package name "org.crossfire.editor.CFEditor" therefore
     
     >
     
        doesn't work. It has to be "src.org.crossfire.editor.CFEditor".
     
     >
     
        However, 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. Since no one under Linux
will use or can using Visual J++, and all the editors under Linux allow src to
be located in any directory, even in non-package-name compliant areas, I wanted
a linux branch so I could work on it without upseting or breaking any windows
stuff.

As an aside, Visual J++ requirement seems a little restrictive. I've used
JBuilder and it does not have this requirement.

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.

>
     
      o The new policy of extracting all resources out of the .jar file
     
     >
     
        doesn't seem like a good idea to me. Unless I totally misunderstood
     
     >
     
        your purpose.
     
     >
     
        Resource files (like icons and config files like "autojoin.txt")
     
     >
     
        should be easy to access and easy to modify. If they are burried
     
     >
     
        in the jar file, the average user won't find them.
     
     >
     
        And you have no visual control over the stuff in the jar file
     
     >
     
        either. 
     
     
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 the want to change the image of the save button, etc.

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.

The jar also makes for easy packaging in linux. 1 file contains everything. Drop
it into the classpath and your done.

I'm not sure what you mean about visual control, but I have written lots of code
that extracts and puts stuff into a .jar file. My code is based on this url:

     
     http://www.javaworld.com/javaworld/javatips/jw-javatip49.html
     
     

What I've found that works well, is to put a resonable set of default Properties
and Resources into the .jar file, but make the visual side of things read from
the defaults (.jar), and save customization into user.home.

>
     
      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?

All resource files are still in cvs, just bundle them into the jar for easy
distribution.

>
     
      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:
     
     http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002840.html
     
     

You responded:
     
     http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002841.html
     
     

I again asked a question:
     
     http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002854.html
     
     

You responded:
     
     http://mailman.real-time.com/pipermail/crossfire-devel/2001-December/002857.html
     
     

What do I need to do to keep you more aware?

What things should I ask you?
-- 
Bob Tanner <
     
     tanner at real-time.com
     
     >         | Phone : (952)943-8700
     
     http://www.mn-linux.org,
     
      Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9