[CF-Devel] CVS commit: CFJavaEditor

[Bob Tanner]

Quoting Andreas Vogl (
     
     andi.vogl at gmx.net
     
     ):
>
     
      > 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.
     
     
A linux branch, so I would not mess up the main branch. Personally, I find
merging branches a simple task, cvs does most of the work for you. 

Most of the projects I work on have several branches.

Like 

PROJECT_2_0		Final version of 2.0 release
PROJECT_2_0_BRANCH	Branch for 2.0 release development

When a port to a new OS is done

PROJECT_2_0_LINUX	Branch for 2.0 port to Linux

Maybe it's because the other projects I work on are larger (in terms of number
of developers). But the above system works well IMHO.

>
     
      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.
     
     
Ok, how about to follow Sun's recommended naming convention.

     
     http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
     
     

>
     
      Why would directory locations be platform-independent?
     
     
Quoting you: 
	"The Java Editor is all about Platform-Independency."

>
     
      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.
     
     
Again quoting you: 
	"After all, the editor is designed for users, not developers."

How many users would want to chage the icons? That's more of a developer thing.
Unless you invision some sort of PLAF (pluggable look-n-feel, aka skins).

I talked a little bit about this in irc, I should have logged it. The stuff
(icons, autojoin, etc) in the .jar as a set of reasonable defaults. 

1. This make package management easier. 1 file, drop it in the classpath and
your done with it.
2. Make setup easier for non-package management. Ie just download this .jar file
and java -jar CFEditor.jar to make it work. 
3. Makes documentation lots easier. Don't have to tell users where the files
need to be located, etc.

By no means, be for it to be unflexible. They are in the .jar as defaults, the
users can easily change their preferences.

Using the Properties class, you can instantiate a new Properties with a set of
defaults.

     
     http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html#Properties(java.util.Properties
     
     )

Pseudo code:

	// Create some new properties using .jar as defaults.
	Properties prop = new Properties(defaults from jar);

        // Look for the user preferences, if they don't exist write
	// the defaults from the .jar to their preference file.
	String path = System.pathSeperator;
	if (user.home+path+CFEditor does not exist) {
	  prop.store(user.home+path+CFEditor);
        } else {
	  prop.load(user.home+path+CFEditor);
        }

	
>
     
      > 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.
     
     
.jar is just a zip file. Winzip can manipulate them just as easy as the jar
tool.

What is easier then saying put this .jar into your classpath and run java
org.crossfire.editor.CFEditor?

Verse, put .jar into a directory, make sure you download the autojoin.txt and
put it into the same directory, and download the HelpFiles, system files, etc..

Make makes it much easier for the end user IMHO.

>
     
      Yes, that has happened numerous times on CF cvs.
     
     >
     
      But it means only loss of *one* resource file, which is
     
     >
     
      usually easy to fix.
     
     
As I stated before, ALL the files in the jar are still in cvs, the .jar is all
that is distributed to end users to make it easier for them all around.

Again quoting you:
        "After all, the editor is designed for users, not developers."

If this is true, most user are not going to be looking at cvs, they are going to
be looking at the pre-build packages.

>
     
      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.
     
     
If you notice, I did not check in .jar file, it's not in cvs. I don't believe
the .jar should be in cvs in the first place. We don't store the .a or .o files
for the server, why store the .jar?

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