[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-ant-dev] Fwd: External tools todo list...
|
Here are Simon's thoughts on where the external tools UI was before he went
on hiatus. Note that the "generic console" he mentions here will probably not
be happening.
Instead, Darin and I are looking at integrating the external tools framework
into the debug/launching framework. This would mean that external tools would
appear in the debug view like other launches and their output would be
available in the debug console (among other things).
- Jared
---------- Forwarded Message ----------
Subject: External tools todo list...
Date: Wed, 18 Sep 2002 14:22:58 -0400
From: "Simon Arsenault" <Simon_Arsenault@xxxxxxx>
To: "jared-eclipse" <Jared_Burns@xxxxxxx>
Cc: "Simon Arsenault" <Simon_Arsenault@xxxxxxx>, "Nick Edgar"
<Nick_Edgar@xxxxxxx>
Jared,
Here is a brain dump of things left to be done for external tools. Nobody
else has really work on the external tool project. But Rodrigo does have some
knowledge of this and may be of some help too.
Take some time to get familiar with the code and the ideas behind it. Also,
there is a couple of *Util classes and ExternalToolsPlugin have some helper
methods.
The goal before releasing to the head stream is to have no more compile
errors and have most of the previous functions in release 2.0 working
still. Also, the package org.eclipse.ui.externaltools.internal.ui should
eventually be empty and then deleted...but that is more of a pre 2.1
release goal.
Also, as you are modifying classes in this internal.ui package, please
update the copyright notice (just look at a class in another package and
copy/paste).
BuilderPropertyPage needs to be updated to have no compile errors. Look
at the .view package to see how a new external tool is added and how it
is edited. You can make use of those actions. We also need an "Add"
button on this page. This button would show a dialog with a list of all
the external tools that you can see in the External Tools view (again,
look at the .view package to see the code that presents this list in the
view). When the user selects a tool from this list, we would make a
"copy" of it and place it as an external tools builder. These would be
then two totally independent tools, so changing one will not affect the
other. Thinking more about this, maybe "Add" is not such a good name for
the button... Once the copy action is implemented (in the .view package)
you can make use of this code. Also, once the class is ready, we should
move it to the .internal.dialog package, we should also update the
plugin.xml file by moving the contribution from the "old stuff" section
to the top part of the file.
ConfigurationDialog and EditDialog should be deleted. The only reason
they are still there is to have access to the old code. But they have no
purpose anymore. The ConfigurationDialog was replaced by the External
Tools view. The EditDialog is replaced by both the external tools new
wizard and property dialog.
AntAction represents the "Run Ant..." menu item on a context menu for an
.xml file. I'm still not sure what this should do. One option is to drop
this action completely (also remove contribution in plugin.xml file).
Another option is to have this action launch the ant external tool new
wizard, but if so, maybe "Run Ant..." is not such a good menu name
anymore? Third option is to have it prompt only for the target/arguments
and then create an external tool underneath if it does not exist (this
is what we do in release 2.0). This would kinda be like invoking the
"Run With..." action on an Ant external tool. If we go with any of these
options (I prefer #3) or some other one, we need to rename this class (I
prefer RunAntAction assuming we stay with the current menu name). If we
keep this action, once it is updated, we should create a new package
org.eclipse.ui.externaltools.internal.ant.action in the Ant Tools
Support source folder and move this action into it. It should not refer
to any internal code in the External Tool Base source folder (except for
the ToolMessages, ExternalToolsPlugin. and IHelpContextIds).
AntLaunchWizard and AntLaunchWizardPage are used only by the AntAction
class. If we keep this action and depending with option we go with, we
need to move these classes to the Ant Tools Support source folder
(probably .dialog package) or delete them. If we keep them, we can
probably rename them too if applicable. The wizard does a bunch of work
to launch the external tool...we should drop all that code and simply
use the RunExternalToolAction instead. We will need to update the
AntLaunchWizardPage to use the AntTargetsGroup instead of creating its
own widgets. Then we can also delete the classes
AntTargetContentProvider and AntTargetLabelProvider. (side note, what
this is doing is very close to what the Run With... action would do from
the UI perspective...so maybe we can reuse the same classes there when
we implement the Run With... action later on)
LogConsoleDocument, LogConsoleView, LogTreeContentProvider,
LogTreeLabelProvider, and OutputStructureElement is all related to the
current external tools console. We can leave these here for now. But
once the generic console is ready, these 5 classes should be deleted as
they will not be needed anymore. Also, remember to delete the entry in
the plugin.xml file concerning the view contribution for the log console
(see "old stuff" section at botton of file)
ToolsPreferencePage basically only has preferences concerning the
console. Again, once the generic log console is ready, it will have its
own preference page, so this page will not longer be needed. Now, we
will also need to update the plugin.xml file because the Ant external
tool preference page is a sub-item of this page. It will need to become
a top level preference page unless we find we have some global external
tool preference page need.
Ok, that takes care of that internal.ui package.
Some areas where the code is not complete in the new rework:
We have a new action called Run > External Tools > Run Last Tool It
should have a short cut key of Ctrl+Shift+R
Copy & Pstes actions are not yet implemented (in the .view package)
Rename action is not yet implemented (in the .view package). This should
work like in the navigator view where an inline editor opens up. Also,
you will need to add a new api to ExternalToolStorage to rename a tool
(pass in a tool and a new name). Validate the new name will be unique.
Then apply the change. Look also closely at the ExternalToolRegistry as
it has some caches dependent on the tool name which will need to be
updated also.
The Run With... action does the exact same thing as the Run action at
the moment. What this action should do is allow a client contributing an
external tool type to specify either a wizard or dialog that we would
invoke to prompt the user before running the tool. For example, a
"program" type external tool would want to prompt for arguments. An Ant
type external tool would want to prompt for arguments and ant targets to
run. The restriction is this wizard/dialog can only work with the
argument field or extra attributes. This wizard/dialog would not modify
the tool. Instead, the Run With action would get the entered argument
and extra attribute values entered by the user and place them in the
DefaultRunnerContext. We'll need to update this DefaultRunnerContext.
Right now, it has a var to hold onto the args, but for extra attributes,
it goes to the tool directly. It should have a variable for the extra
attributes entered by the user. So then it looks in that var first, then
if not found, goes to the tool. Until we get this done, we should
disable this action (or get it to show a dialog saying it is not yet
implemented...otherwise people will not understand what it is for).
The threads that are used by the ProgramRunner to read the input/error
streams could be optimized. Maybe reading a few bytes at a time or until
a CR is detected? I guess this will depend on how the generic console
will work.
The ProgramRunner, while waiting for the runtime.exec process to
complete, does not check for monito cancelled. This should be changed.
ExternalToolRegistry:from/toCommandArgs methods use the "=" as the
key/value separator. We need to handle the case where the key or value
has a "=" in it. Maybe by using "==" to mean a single "="?
In AntUtil, storing run target list uses "," as the separator but does
not handle the case where the target name contains a "," in it. Again,
we should use ",," to mean ","?
When you edit/create a new tool, the "Browse" button for specifying the
location and work directory do not work. They should show a dialog. At
the top, there would be two radio button on one line. Something like: "
( ) Variable ( ) File System". If variable is selected, then
underneath, the variable form should be shown (see
ExternalToolVariableForm). There is an extension point for both location
and work directory variables. Look at how the refresh scope group makes
use of this variable form. If file system is selected, then underneath a
widget(s) should be shown to select a file or directory. I think the
workbench or swt has support for this. We do not want the file selection
dialog to open here.
On the "Options" page, the "Variables" button does not do anything at
the moment. It should open a dialog with the variable form in it. There
is an extension point for supplying argument variables. The new variable
should be added at the current cursor location.
There are some methods in the RunExternalToolAction that are not
implemented yet (like showing the console view... by the way, the UI
team should be looking at providing an api to show a view without it
taking focus...there was not resolution about what to do with fast views
that need focus in order to show themselves...talk to Eduardo about the
status of this)
Not all variables have been defined in the XML yet. These need to be
added (see the IExternalToolConstants for a complete list...ignore the
editor ones for now). Also, only some variables have a valid "Extender"
class and "Component" class implemented so far. We need to add the rest.
For the working set variable, we should get Knut to provide us from the
workbench a class that we can use. Right now, there is a dialog, but it
would be better to have a class which we could call some create* method
with a parent composite. That way, it's embedded in the variable form.
I've talked to Knut about this so he has an idea what I want. He is also
reworking the ui for working set and I've asked in to consider this
request. Check with him when you get close to working on this.
Aside from that, this project needs a great deal of testing. I've done very
little and given the amount of changes, I'm sure there are serious problem
lurking in the back somewhere ;-)
My suggestions is to do the following before releasing to head:
Get builder property page fixed up and moved to proper package.
Decide what to do with the Run Ant action. If unsure at the moment.
disable the code and remove contribution from the plugin.xml
Get ride of the ConfigurationDialog and EditDialog classes
Update the Run With action to show a dialog saying it does not do
anything yet
Then maybe you should start looking into the generic console. Every now and
then, you could start thinking about the rest of the work and do a bit at a
time. The Run With and Run Ant actions are the biggest and need some amount
of thinking here.
Simon :-)
-------------------------------------------------------
