[Uml-devel] Call attr/oper properties directly from mylistview?

[Jens Krüger]

Am Montag, 29. Juli 2002 12:29 schrieb Jonathan Riddell:
> > You open the dialog for changing the properties of the class and you get
> > a dialog with 'Ok', 'Apply', and 'Cancel' buttons. As an user you assume
> > that all your changes in the dialog may not commited if you press cancel,
> > but they automatically applied if you press Ok in your operation or
> > attribute subdialog. Is this a good style for an user interface. I'm not
> > happy with your solution. On the other hand a generation of new
> > attributes, operations are also commited without any question to the
> > user. What should we do?
> >
> > >From the point of user the cancel button should all changes roll back,
> >
> > otherwise the cancel and apply buttons makes no sense in the properties
> > dialog. I think all properties dialog in the uml-program should have the
> > same behaviour.

It is ok, without an exception. I tried it yesterday in the evening. You had 
no chance to change the comment at the moment if you go directly to the 
properties dialogue of attributes and operations. I think we should add a 
comment field in the properties box. It seems more logically from the point 
of user to add the comment for attributes and properties in the same dialogue.
The existing possibility to change the comment in the properties dialogue of 
the class should not removed.

An other question is, should we directly open the properties dialogue, if you 
add a new attribute or operation in the list view? It seems more convenient 
for the user than clicking 'New' and afterwards clicking  'Properties' for 
entering all informations to the attribute/operation. 

>
> When clicking properties from an attribute or operation is seems logical
> to me that you would get the properties dialogue for that attribute or
> operation and not for it's class.
>
> Your point that some changes are applied before clicking OK is something
> that needs looked into.  Although the user has already clicked OK on the
> new attribute dialogue it should probably still beable to be cancelled
> from the class dialogue.
>
> > Did you read the projekt handbook of kmoney2 as Thomas proposed? I read
> > it and I found some interesting ideas. One of them is the splitting of
> > even and odd subversion numbers to the stable and development version
> > resp.. An other is to create a branch after releasing a version, so that
> > the development is always on the main trunk and the current development
> > state is HEAD. I think we should create a branch on the version 1.0.3
> > (released) if it is possible. Otherwise we have to wait for the next
> > release.  We should release if we find the most bugs in the current state
> > and not in a unstable state as now. We have to test and find the bugs and
> > errors and fix them.
>
> It's too late to make a 1.0.3 branch, there's been many changes since
> then.  I'm also not sure that there's enough developers to warrent two
> full time branches.  I'm thinking of making some 1.1 pre-releases when we
> get admin privilages over the project and a 1.1 release when most of the
> bugs are gone then branch to allow for new features but only change the
> 1.1 branch for the bugs that really need it.
>
> However that's all open to debate.  The Linux numbering scheme may well be
> more suitable.
>
> Jonathan Riddell
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Uml-devel mailing list
> umbrello-devel at kde.org
> https://mail.kde.org/mailman/listinfo/umbrello-devel

-- 

Jens Krüger

Technische Universität München
ZWE FRM-II
Lichtenberg-Str. 1
D-85747 Garching

Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666
mailto:jens_krueger at frm2.tu-muenchen.de
http://www.frm2.tu-muenchen.de