[Uml-devel] Umbrello2

[Mathias Meyer]

On Wednesday 26 February 2003 19:13 you wrote:

> gui layout... here's an idea: we're all familiar with the "Use Case
> View", "Logical View" and "Deployment View" concepts right? essentially
> hardcoded packages that contain various parts of the UML model. We can
> generalize this concept to describe abstract views of the model - for
> example, we could a "Development View" that would contain things like
> UML::Artifact objects (stereotyped as header or source files).
> basically, it would show diagrams of the build environment and
> relationships (e.g., #include dependencies) between them. to contain
> these "abstract views" i was thinking that we could take the standard
> tree view (a la 1.x) and turn it into a tab view - each tab contains a
> tree with the relevant objects contained therein (more like kdevelop).
>
I don't use kdevelop, but the idea you described, does sound appealing ;)
The treeview looks a bit overloaded with all that stuff put in it. It's 
useable, though, but there's always room for optimization.

> we should include the possibility to work on diagrams in multiple
> top-level windows. that should work really well with large design
> projects and multihead displays. for each window there should be an
> associated toolbar that contains icons representing all the elements
> that can be applied to the specific type of diagram - including
> non-databound graphical artifacts like boxes and text labels. those
> generic tools should be applicable to all diagrams.
>
Multiple windows? Hmm, what about making it possible to edit more than one 
diagram at one time and using a tabview on top to switch between them? 
That was an idea that popped into my head when I started using Umbrello.
However, there has to be a way to edit more than one diagram at a time, 
that's our common ground here.

> any property dialogs that are popped up should be... what's the right
> word. modal? probably not. we should allow the user to throw up lots of
> property dialogs. modifications to properties of an object should be
> reflected in the diagram as properties change. for example, clicking
> the "isAbstract" checkbox on a class should automatically change the
> font of the class name to italics or plain (depending on the value).
>
Throwing up more than one dialog at a time can be useful, but it's tricky 
to implement, isn't it? You definitely gotta take care of not having two 
of the same dialoges open. And, for example take the class properties 
dialog. If that wouldn't be modal, you'd have to take care that, if the 
user would change some attribute of a class, using its properties dialog, 
you reflect possible changes in the other open dialog. You did mention 
that regarding the diagram, but I think there's more to it ;)
But I definitely like the idea of having it all more flexible. Slots & 
signals should be our best friends here, don't they?

Best regards,
Mathias
-- 
"only wimps use backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)" - linus torvalds