ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <meta...@yahoo.com>
Subject Re: Ideas on a different ant GUI
Date Mon, 18 Dec 2000 21:37:41 GMT

--- Stefan.Vaillant@gmx.de wrote:
> Hi,
> 
> having struggled for some years with various version of make,
> I really appriciate the concepts of ant.
> 
> However, I personally have a different vision for an ant user interface.
> It's not really conflicting with antidote, it seems to adress a different
> user group.
> 

First of all: Wow! You've got some really great ideas! 

However, what I'm hoping to do is /convince/ you that what you have
proposed is not necessarily a different "vision" for an Ant GUI, but a
better thought out one. Not only is this in the hopes that you will
contribute your efforts to the existing Antidote base rather than starting
a new effort, but also see that this is exactly the kind of input that
Antidote needs at this stage.

Here's why:

1) If you look at the file
jakarta-ant/src/antidote/docs/gui-requirements.html you will find a loose
wish-list for what an Ant GUI should/could do. This is a document that I
threw together based on input I received from the development group. It was
a kitchen sink approach to requirements gathering. Nothing was edited out,
and any submission was valid. Build Management, which is essentially what
your proposal deals with (as I interpret it in one reading) was at the top
of the list, and one of the purposes of Antidote but not the only item.
This document gave me an idea of the breadth of features that Antodote
/may/ need to deal with in the long term, and aided me in architecting a
framework for Antidote. 

2) The code for Antidote as it stands today is mainly a framework. Yes, you
can load a build file, execute it, and even edit parts of the build
definition, but the implementation of those features is only extensive
enough to test out the concepts and features of the architecture. They also
serve as loose examples for potential contributors for how to create new
modules. Antidote comes off at first glance as a build file editor, as that
is the view you are presented with when you run it right now, but that is
by no means the end goal of Antidote. I think it is a desireable feature,
but is probably not be the primary one for Antidote. What exists today is
what I have implemented to exersize the architectural constructs of the
framework. Also remember that the current feature wish-list was developed
by *developers*, of Ant and no-one has explicitly taken on the role of
end-user advocate. Maybe that is what you are being called to do! ;-) Until
now, as far as I can remember, no-one has explicitly defined who the
targeted end user should be. I've had an image in my mind (people who don't
want to futz with Ant XML files), but certainly nothing as well thought out
as what you've presented.

3) Given my focus on application architecture, I have aimed to accomidate
persons such as yourself who have a specific user experience you would like
the GUI offer. I have *not* articulated such a user experience definition,
which is why it currently looks like a build file editor. *I* have focused
on the developer/add-on experience, as that is what I think will make or
break my ability to get help with the GUI. I can't do it by myself, so it
is paramount at this stage that I make developing against the Antidote
framework an appealing prospect. I hope has been the case for you since you
mentioned using the command structure and event bus. Given that, I think
you will find the ability to add the features you desire fairly well
supported by the GUI. Check out the discussion on the AntEditor class in
jakarta-ant/src/antidote/docs/design-overview.html. (The one thing that is
not explicitly supported by the Antidote framework is the handling of
multiple build files, but that is an easy fix at this stage). The current
dom navigator and properties editor are by no means considered the
long-term defaults for the initial view. Your proposed panels could
certainly do a better job of filling those default views.

> I have written down some ideas and requirements for the user interface
> which I call anttool. I appriciate any comments.

Since the first round of feature recording had the policy of accepting all
offerings, yours certainly deserves equal treatment. However, you have
given the user experience component of it much more thought than any one
else has yet to articulate on the list, 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.

Given what I've said, I hope that you will consider giving the current
Antidote base a chance, and working with me to develop a tool to make Ant a
more accessible tool. Obviously the framework is not complete, but it is
through the contributions and efforts of others that such insufficiencies
are uncovered. 

My vision for Antidote is to act as an enabler for Ant, particularly to
those who might otherwise overlook the power offered by the Ant core. I
speculate that this vision is in line with what you are proposing, and I
hope that we can work together to make this happen. You may have your own
thoughts and desires for Anttool, but as far as Antidote goes, I certainly
can't do it alone.

Thanks,

Simeon

=====
Mustard Seed Software
mailto:simeon@fitch.net

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Mime
View raw message