>>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes:

  Paul> I am thinking of revising the way projects work in the JDE to
  Paul> put each project in its own frame.

        I have to put state my claim here right at the begining. For 
a while I have no used the project system, to the extend that I use
this function...

(defun jde-load-project-file())

       (which does precisely nothing) instead of the standard one. 
When I did use the "project system" I subverted it by placing a "load
file" option in a menu item that I call "Jde+" which has all those
features that I like specifically. 

        It strikes me that the major problem with the project system 
is that it stores ALL of the JDE variables in the project file. For me
this is a pain because I have a whole series of functions which alter
JDE variables, to allow for instance toggling between javac, and
jikes, whether I run java with or without JIT and so on. These all get
overridden by the project system, when often all I want to do is to
over-ride for instance the javac -d directory, and classpath, or to
switch compilers so that I can check code is 1.0, 1.1 or 1.2
compliant. The fact that standard options such as for instance the
boiler plate text, gets stored in many places is for me enough of a
pain that Ive just removed it from my version of JDE (oh! the joys of
open source!). It would seem likely to me that fixing this problem
would probably work around the other problems that Paul is talking
off. Maybe Im being nieve here, but I keep all of my source code
arrayed from one root directory. Doesnt everyone?

        Im aware that fixing this is a large scale coding option. If
instead the small scale option is desired, I think I would be inclined
to provide two options rather than the straight forward way Paul has
suggested. Personally I would dislike having more than two frames open
(it took me ages to get used to speedbar because of this) for any
reasons yet alone different projects. It should I think be possible to
instead of doing this strictly frame based mechanism to have it menu
based (menu's are available from emacs thru vt100 right?). You would
have a basic menu called for instance "JDE project" with two menu
items "Project Open", and "Set Frame to Project" (oops this is not a
neat name..Im sure someone can come up with something better). On
opening a new project (with "Project open" which would give you the
minibuffer "find file" dialog, or equivalent function for xemacs if it
is different, which would allow you to load a whatever it is the
prj.el file has been called) you would get a new menu item named after
the project name. If you then called "Set Frame to project", this
would alter the name of the current frame to the project and any
buffer opened in this frame would get this project. For luddites like
myself who like one frame only or who have text only frames, you would
be in a nice position to switch Projects manually, which is what I
have been doing for ages anyway. It would be easy to tell which system
you were using depending on the title bar of the frame, which would be
a project name, or "Emacs", although here things might get hairy if
you opened speedbar half way though (Paul:- does speedbar reset the
title bar to the file name each time you change buffer? Have you
considered the effect this would have on the frame title bar? This
could be disconcerting!). This would only be ambiguous if you were on
a vt100, in which case you would set projects by hand anyway.

          If you really wanted to get complex you could have 
"Set Project by source location" option as well, which sets everything
back to current mechanism, which would satisfy everyone. Although
probably confuse the hell out of new users. The latter is of course a
problem, although I would say that in my brief foray out of emacs-land
into the dodgy no mans lands of "IDE's which arnt JDE" I have yet to
find a "project" system in any of the IDE's which didnt confuse the
hell out of me, so JDE would just be getting into line here. 



     Phil


     

Reply via email to