[Uml-devel] UI for new code generator

[Brian Thomas]

On Wednesday 12 March 2003 03:16 pm, Jonathan Riddell wrote:
> On Mon, 10 Mar 2003, Brian Thomas wrote:
> >       I've put together a small cartoon diagraming how I would construct
> > the user interface for the new code generator. I would like to largely
> > re-use the layout in the current tool, simply replacing functionality of
> > some windows as is needed. I believe the following functionality is
> > needed:
>
> Excellent that you're interested in improving it.  Is that a definate
> volunteer?  :)

	Yeah. I plan to start hacking it as soon as I can wrap up laying out proper
	inheritance for UMLConcept-> UMLClass. Many classes are effected and
	its on the nasty side. I'll update with a patch soon I hope.

>
> >        - a tree view of all the classes that you have loaded into
> > Umbrello. This tree view is just like the current one for the "Logical
> > View" except that it omits the diagram stubs... in other words only the
> > classes and their properties are shown.
>
> Any improved code generator should include interfaces as well as classes.
> What's the point in the tree view in this instance?  Is it just something
> to refer to?  Would it have any functionality?

	Of course Interfaces. I didnt mention them in part because the current code
	generators ONLY generate Classes (aka "UMLConcept")>> once I can get
	UMLClass and UMLInterfaces inheriting properly from UMLConcept, code
	generation may proceed with creating interfaces too.

	The tree view is simply to show you every UML construct that will be used
	to generate code (in the near term, only "UMLConcepts" and the UMLassociations
	between them will be used). Since I dont understand how to generate code from
	activity or other types UMLdiagrams (than a good old class diagram), that wont 
	be implemented. 

	By selecting an item from the tree view, the "code view" and the "local parameter config"
	views will update to that particular concept. 


>
> >       - a language-oriented global parameter control box for code
> > generation. Things that might go in here include the style of comments to
> > generate, if you want high comment verbosity, if you want accessor
> > methods generated, etc. Part of the controls will be language specific
> > and change based on what you have selected as the current language to
> > generate.
>
> Sounds great.  Not quite sure how the programming interface for that would
> be, if each code generator would have to define a widget with the
> checkboxes and lineedits to be used or if some clever extendable interface
> would be possible saying I want this option and it should use a lineedit.
>

	Well, if we extend the codegenerator class to have a virtual method called something
	like "showGlobalConfigWidget()" method perhaps that will work. Global parameters
	that I can think of include things like :

	- C++ : default all operations to "virtual" (or opposite).
	- C++/Java : default comment style (e.g. use // or /* */ styles)
	- Perl : default method to create objects, choice of singleVariable, HashTable or Array.
	
	and so on. More should be apparent as time goes by. This box could very well be "empty"
	for some code generation types.

> >       - a class template control box. You should be able to override
> > global
> >          code generation parameters for this particular class here.
> > Class selection
> >         is via the tree view (just click it). You can get a control
> > box for attributes
> >         and associations by clicking on the child attributes of the
> > class in the tree view.
>
> Not quite sure what the global code generation parameters are here.  I
> think I get what the tree view is for though now.

	Well, the "local" box should have all the same buttons as the global box, but allow you to
	override them in this particular Class/Interface.

>
> >       - a code view window, which shows you what code will be generated
> > and indicates roughly which attributes in the tree generate which parts
> > of the code. Nominally, you should be able to edit the code in this
> > window and have your edits "stick".
>
> That last sentence will be difficult, but something to aim for.

	I think its possible by using the "CodeDocument" object hierarchy that I mention in my
	proposal. Luis also mentions another possible route implemented via QT libraries:

Dont ask me any details about it, but I know Qt can load Designer files (ui) 
at run time and generate forms (widgets) out of them. These forms are of 
course not compiled and therefore *the widgets themselves* cannot have any 
intelligence... but, there seems to be a way of binding these "dumb" widgets 
with a "controller" that can process the information. 


	BTW, when is Umbrello 1.2 supposed to be released? I guess my plan is to wait for that
	to come out before I start this (major) hack. 

				-b.t.