Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Resent-date: Wed, 20 Dec 2000 20:09:27 -0600
Date: Wed, 20 Dec 2000 16:07:48 -0600
Resent-from: simeon@fitch.net
From: "Simeon H.K. Fitch" <simeon@fitch.net>
Subject: Re: Ideas on a different ant GUI
In-reply-to: <A914533BF4B9D2118D980008C7894C0A02D83A48@dueis01nok>; from
 Stefan.Vaillant@nokia.com on Wed, Dec 20, 2000 at 04:52:52PM +0200
Resent-to: Ant Developers <ant-dev@jakarta.apache.org>
To: Stefan.Vaillant@nokia.com
Cc: ant-dev@jakarta.apache.org
Reply-to: simeon@fitch.net
Resent-message-id: <200012210209.UAA24605@fugue.mustardseedsoftware.com>
Message-id: <20001220160748.A23833@mustardseedsoftware.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
User-Agent: Mutt/1.2.5i
References: <A914533BF4B9D2118D980008C7894C0A02D83A48@dueis01nok>

On Wed, Dec 20, 2000 at 04:52:52PM +0200, Stefan.Vaillant@nokia.com wrote:
> Hi Simeon,
> 
> sounds good!

Great!

> 
> 1) I agree with what you say.
>    (BTW: Thanks for the historic background on antidote, I wasn't aware of
> that.)

No problem. It's a real pain to weed through mailing list archives. I
only started work on Antidote a couple months ago.

> 2) Yes, I will cetainly base the developments on the antidote framework.
>    In fact, I have already started. 
>    See e.g. the attached files which include changes to 
>    the current source to support the anttool ideas.

Cool! I didn't get the attached files though. Send your updates in the
[PATCH] email format to ant-dev as spelled out in
http://jakarta.apache.org/site/source.html.

>    And I have to do some further changes, e.g. some 
>    events have to be redefined to support multiple build files.
>    I have put the new ProjectNavigator to a new gui.anttool package.

That's good. I hadn't even thought about multiple build file support,
but I know it is definately something that many people would want; not
just from a separate build standpoint, but many people like to break
their build files up into separate files.

Once I take a look at what you've sent (it may take me a little while
as I'm off for vacation), I may make some more changes to the existing
build file/project support to better accomidate what you are aiming
for.

> 
>    The main problem for me is, how do we sync the changes?

I'm a committer, so I can take care of that. No problem. I'll take a
look at what you've sent me and check it in. I probably won't want to
create a separate "anttool" package, but I do think there needs to be
a "modules" package which your ProjectNavigator can be placed. To
eliminate name collision, I'll just rename the existing one to
"ElementNavigator" or something else (as what you've proposed truly is
a ProjectNavigator).

Changes that I make right now are probably going to still be more framework oriented, or modules that are orthogonal to what you are doing.

> 
> Here some technical problems:
> 
> 3) Your current framework allows it to configure the UI in a flexibly way.
>    But how do you want to maintain multiple different configurations?
>    Or more concrete:
> 	a) Should I add the my source code in such a way that I overwrite
> existing
> 	   functionality?  -or-
> 	b) Should I add my editors as additional editors?
>    I guess the answer is b). Then, how to maintain multiple versions of the
> *.properties files
>    and how can the end-user select one configuration for the start-up?

For right now, assume more or less "a)". I'd like to be as
accomidating to what you are doing right now as possible, as you are
focusing more on the end-user level functionality. I'm really
interested in where you are going to take this. Insofar as the
antidote.properties file goes, just comment out my existing values for
the "modules" (used to be "editors") and put in your own. That reminds
me, make sure you are up to date with the latest source as I made a
couple of changes the other day to that code.

> 
> 4) To support the "yellow flag" in the UI, I need changes in ant.
>    (see end of my Email with a proposal.)
>    Any opinions on that?

I'll have to dig your proposal back up, but as far as changes to the
Ant core go, those are things you should pass through the developer
group, esp. Conor & Stephan. They really need to sign off on that sort
of thing. I recommend making the change you want to the source, and
then submitting a patch via the standard procedure. 

If it is the recommendation to have some of the core tasks generating
status events, then I'm for it, but I guarantee you'll get resistance
from others. A dialog probably needs to occur there.

>    I have not followed the discussions around ant 2.0 (and I'm not willing
> to do that, too.)
>    Do you know if ant 2.0 will go into this direction?

Your guess is as good as mine ;-). Post your desires though so that
they can be incorporated into the discussion.


> 
> 5) Do you have any comments on the repository idea?

There is already a discussion about that going on about that, called
CJAN. Take a look at the mailing list archives on that one. There are
some really good ideas being floated, and may have some impact on Ant
2.0.

> 
> 6) I'm not sure if it is a good idea to have references from the
> ProjectProxy to
>    the views (#getTreeModel): Why to hard-wire one representation/view in
> the model?
>    I could write my own, new projectNavigator without it.

Mostly short-sightedness on my part, and part waffling on
approach. Originally I was going to use the core Ant data structure,
and I wanted to provide a simple layer of isolation beteen the rest of
Antidote and Ant; that isolation being the views. Well, using the core
Ant datastructures turned out to be a dead end, but the proxy part
never got reworked. Based on your recommendation for multi-project
support, I think the whole ProjectProxy should go away and be replaced
with one or more classes that have nothing to do with view, and only
deal with management of the multiple projects.

Have you got any recommendations?

> 
> 7) Some ideas for a big refactoring:
> 	- move all framework classes to one package

OK

> 	- move each editor to it's own package (e.g. gui.editor.project,
> gui.editor.log, ..)
> 	  (or all to one new package.)

I think I want to do the latter first, and then as it grows break it
up again. That's why the "gui" package is the way it is, and as you've
pointed out it's time break it up some. Also, it's a lot easier to add
directories in CVS than remove them ;-0


> 	- IMHO Editors should be (special) JavaBeans (as requested by
> others).
> 

I just appied that change a couple days ago to the architecture to
allow that. They don't have BeanInfo or Customizers, etc. But that can
come later if someone wants to do that...

> On your Email:
> --------------
> > jakarta-ant/src/antidote/docs/gui-requirements.html you will find a loose
> > wish-list for what an Ant GUI should/could do. 
> 
> Yes, I have read it. I didn't want to be too agressive in my Email, so I
> didn't positioned
> anttool _against_ this requirements. Here is my opinion:
> Nearly 50% of the requirements dealed with _editing_ the build file.

Yes. That is what ant-dev voiced interest in. But that is only one
viewpoint. I'm actually interested in hearing more from people like
Diane who seem to be focused on efficiency from an end user
standpoint.

> My feeling is that existing and upcoming XML editors will provide 
> sufficient functionality to modify build files and I'm not sure if 
> there is any special need for a ant-specific _editor_.
> Therefore I'm proposing to use an external (generic) XML editor and
> just call this editor from an ant GUI.

My major counter to this is that 1) the Ant build definition could be
represented in some other format than an XML file (e.g. database
tables), 2) the goal was for a build definition editor, not an XML
editor (it looks like one right now, but that wasn't the end-goal), 3)
even if the build definition remained in an XML file format, there is
a desire to isolate the user from that detail. One of the thinks I
wanted to start working on next is a "wizzard" for building a default
build file definition without writing XML code. I think that sort of
"editing" is in line with the vision you have stated.

> 
> And instead, concentrate on ant specific stuff, e.g. build management.
> 
> 
> > ..., so I'd like to propose to you that
> > either 1) we roll your recommendations into the existing
> > gui-requirements.html file, or 2) we create and check in a separate
> > document (preferably in html) called user-experience-vision.html (or
> > whatever) that people can reference against.
>  
> I leave that up to you to choose, I don't have any strong feelings on that.

I'll create a new file.


Again, thanks for your work. Just submit your work in the standard
[PATCH] format and I'll take care of getting it checked in, etc. Don't
worry about the existing "editing" modules so much right now. Just put
your stuff where you want it and we'll work out the appropriate place
for that functionality later (like launching a separate window). Just
make sure the [PATCH] emails you submit are against the latest source
base, which is important since I'll be moving classes around based on
your recommendations.

sim


> 
> * Stefan
> 
> PS: Why the name "antidote"?

In the hopes that it "fortifies" Ant, and "counteracts the noxious
effects" of command-line usage (or something pithy like that). It's
what came to mind when I started this thing rolling.

>     (I must admit that I don't like the apache projects names in general.
>      It may be OK to use non-self-describing _poject_ names,
>      but using them as _product_ names is NOK for me.
>      IMHO this will will significantly reduce the acceptance of thes
> software 
>      by others.)

I dunno, the name "Apache" has a better ring to it than "IIS" :-)