--- [EMAIL PROTECTED] 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:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
