GUI

Issue owner:
Don Day <dond at us dot ibm dot com>

Statement of problem or objective:

Is this architecture, function, fix, or other?

Goals of this proposal:

Use cases:

Stakeholders:
List of those who request or need the proposed item.

Interested parties:
List of people interested in potential meetings or discussions.  Use obfuscated addresses, please.  For example, dond at us dot ibm dot com

Proposed design:

Design for enhancing the command line help

Note: All design discussions should occur on the dita-ot-developer list at the dita-ot sourceforge site.
As one who wants to trial DITA to prove its worth, before a company wide roll-out, a GUI is essential.  I live in a user environment, not one inhabited by developers, so access to the command line is virtually impossible. Blocked by company policies.

I can't install the OT because I need to run a batch file, which we can't do.  I might be able to negotiate an exception for installation, but to get long-term access to a command line interface to run the OT would be mission impossible.

ant at ant hyphen davey dot com

Currently there are two purposes of this GUI in my mind.
One is for ease of use to set and start a build in DITA OT. By achieving this goal, first-time users do not need to type the command or write ANT script. They can select in GUI and start a build from there. The ANT script will be generated when they want to save their selection in GUI. 
The other one is to help to install and set up the environment of DITA OT which is necessary to make the build successful. Currently, users need to type a lot of command to set up the environment for DITA OT during the installation. What's worse, it is not easy to test and debug whether the environment is set up correctly. By adding check function in GUI, we can help to test whether environment is OK, provide advice ot users about setting up environment.

Scope of GUI

 ·         Will there be an installer? For what platforms?
No. there won't be an installer. The "install the toolkit" means that users can set up where FOP or SAXON or other tools that is needed by toolkit correctly in GUI. These steps are covered by installation guide in the document of toolkit and are too complex for users to set under command line.

·         Will there be a GUI for adding plugins?
No. there isn't any of this function in current scope

·         Will there be a per-output type GUI for setting per-output type parameters?
No. GUI only has the setting for following parameters. input, output, transtype and dita extension file name.

·         How will errors and warnings be shown?
They will be shown in the console, the same as what you can see in the command line.

·         Will the GUI be able to auto-detect the transtypes that are installed?
No. Basic outputs like html, pdf etc. can be selected. The extened output type and be typed in a text box

·         Will the GUI be able to auto-detect the parameters for each transtype?
No. Currently there is no specific parameters setting for different transtypes.

·         Will the GUI manage headers, footers, stylesheets, logos and overrides?
No.

·         Will the GUI allow saving of sets of parameters?
Yes. the setting can be saved into some profile.

·         Will there be a GUI front end to the DITAVAL file?
No.

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I