I've separated this post from the previous one because this one simply presents my opinion and does not have anything to do with the right way to implement a feature.
My premise is that user configurable GUIs are a "bad thing." Sure, they can be lots of fun and I will admit to having enjoyed changing "skins" on my music player and other such toys, but when it comes to serious software they have several drawbacks. 1. Documentation. How do you look up how a function works or follow instructions when you can't find it because it has been relocated or removed. 2. Training. This is much the same problem. Unless everyone in the class has the same interface, it is difficult to do anything without going around to each student's workstation and finding where they have hidden the feature. Microsoft Word's UI is a source of constant irritation in software training classes. 3. Just talking about features to other users can be confusing since everyone can put it in different places and call it something different or use a custom icon. It can be a regular tower of Babel. 4. I have yet to have a user request this capability, although developers seem to love it. Having said all that, I have heard users request that their favorite feature be placed on the toolbar where it can be accessed with the minimum of clicks. I would support this if it is also available in the original location. I don't think that which menu you put a feature on is as important as not moving it from one software release to another. Consistency is very important to users. Whew! This is where I usually say "just my two cents worth" but this tirade has already taken up more of your time that is worth so, regards, Larry Becker On 5/9/07, Larry Becker <[EMAIL PROTECTED]> wrote: > I thought that it was time to start a new thread for this topic since > the original one was up to 15 posts and was kind of hijacked anyway. > :-) > > To sum things up so far. Michaël and Sunburned seem to be interested > in making OpenJumps GUI configurable by using an external XML file. I > am mostly interested in using the already existing > workbench-properties.xml to allow lib/ext plugins to be added without > the necessity of creating an Extension. > > It has been an interesting discussion so far, but to make it > productive I think we clearly need to define some terms more > rigorously. In particular the term plugIn (or plug-in since spell > checkers don't understand camelCase). > > As you all know, practically every feature in JUMP is implemented as a > plug-in. I count about 60 of them instantiated at the top of > JUMPConfiguration alone. These plug-in are sometimes lumped in with > what we call the "core" of JUMP. They provide the basic UI and > feature set. Let us call these plug-ins "core plug-ins". > > Then there are the plug-ins that are external to the particular JUMP > flavor that reside in the lib/ext folder. These plug-in have UI > installation code present in their initialize() method which is called > by their own Extension class. Let us call these "add-on plug-ins". > > As I mentioned, my goal is to use the workbench-properties.xml file as > it is used in the development environment - as a means of > instantiating add-on plug-ins. However, I have no objection to the > idea of replacing the JUMPConfiguration class with another one that > uses a different external XML file to both instantiate and configure > the UI for a core plug-in. This should be fairly easy to do since > JUMPConfiguration.initializeBuildTnPlugIns() already uses reflection > to build a list of plug-ins. All that is required is some UI glue > code and an XML format and reader. > > hope this clears up the discussion, > regards, > Larry Becker > > > > > -- > http://amusingprogrammer.blogspot.com/ > -- http://amusingprogrammer.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
