Thanks for bouml. And some suggestions.

[chr_h]

Dear Mr. Pages,

firstly something I wanted to tell you many years ago (back when bouml was still FOSS) - your UML modeller is simply the best. And I've tried quite a few, both free (ArgoUML, Umbrello, ...) and commercial (mainly Rational Rose). Before I found bouml, I ended up using pen and paper, simply because no tool suited my needs. So, thanks for bouml! It's a pity that it isn't more wide-spread, in my opinion it deserves more recognition.

With that in mind, I still have some ideas to make a great tool even better:

- Instead of displaying a grid in the diagrams, I would find it more helpful to (a) only display the "crossings" of horizontal and vertical grid lines (a "dot grid") and (b) enable a "snap to" these points, allowing easier alignment of relations and classes/objects/...
- I can edit the drawing settings; however, they don't seem to be stored for a new diagram. For example, I find shadows unhelpful and always disable them. Would be nice to do once and store the settings.
- In parameterized classes ("templates" in C++) the box for the parameter names depends the class width, making it very wide for classes showing full function declarations. If its size would only depend on the parameter name, it would look better I think (plus, leave more space for relations).
- The "zoom"-method doesn't zoom everything evenly. Especially when changing the "geometry" of relations in a different zoom level, things get mixed up (e.g., horizontal lines don't stay horizontal)
- A possibility to "anchor" labels at certain points on their relations would be nice. I.e., select a label center and snap it to the beginning/middle/end of a relation, where it will stay (relative to the relation). With many relations entereing a class from the same side, the labels are often drawn "over" the relation to the right, where centering would be more readable. In this context it would also be helpful to rotate the labels to match the relation's angle.
- Also, I sometimes have labels in the middle of nowhere. To handle those, it would be nice to get to the relation dialog when (double-)clicking on them, or some other help to find out to which relation they do belong

Anyways, thanks again for a great tool!
Cheers,
Christian

[Bruno Pagès]

Hello,

firstly something I wanted to tell you many years ago (back when bouml was still FOSS) - your UML modeller is simply the best. And I've tried quite a few, both free (ArgoUML, Umbrello, ...) and commercial (mainly Rational Rose). Before I found bouml, I ended up using pen and paper, simply because no tool suited my needs. So, thanks for bouml! It's a pity that it isn't more wide-spread, in my opinion it deserves more recognition.

Thank you

- Instead of displaying a grid in the diagrams, I would find it more helpful to (a) only display the "crossings" of horizontal and vertical grid lines (a "dot grid")

I do not understand you, do you want to have

grid1.png (2.16 KiB) Viewed 4548 times

or

grid2.png (1.45 KiB) Viewed 4548 times

... and (b) enable a "snap to" these points, allowing easier alignment of relations and classes/objects/...

Because generally the elements have different sizes the best way to align elements and relations is to have relations starting and finishing on the center of the linked elements, and I enforce that by memorizing the center of the elements rather than their top-left corner by instance. I also do that to as more as possible respect these alignments when the zoom is changed because the zoom is not a 'simple' zoom but a modification of the font size then a recomputing of all

- I can edit the drawing settings; however, they don't seem to be stored for a new diagram. For example, I find shadows unhelpful and always disable them. Would be nice to do once and store the settings.

For that do not change the drawing settings of a given diagram but at an upper level, this means to a container of diagrams, may be at project level. Please look at the video tutorial http://www.bouml.fr/video/starting.wmv from 10:43

- In parameterized classes ("templates" in C++) the box for the parameter names depends the class width, making it very wide for classes showing full function declarations. If its size would only depend on the parameter name, it would look better I think (plus, leave more space for relations).

The minimum width of the formals box is half of the class width, I did that choice because I supposed this proportion is nice
I can parametrize that proportion, or allow to have the smaller width, but is it really important, there are already so much drawing settings

- The "zoom"-method doesn't zoom everything evenly. Especially when changing the "geometry" of relations in a different zoom level, things get mixed up (e.g., horizontal lines don't stay horizontal)

yes, the zoom is not a standard zoom, and there are two main reasons
- the width of the relations is one dot, with a zoom smaller than 100% they disappear, and if the zoom is greater than 100% the result is not pretty.
- applied on the text the zoom gives a bad result

So still the beginning the zoom is a complicated operation, and because I recompute all based on the font being the nearest of the expected one being generaly not the expected one the result cannot be like a standard zoom

- A possibility to "anchor" labels at certain points on their relations would be nice. I.e., select a label center and snap it to the beginning/middle/end of a relation, where it will stay (relative to the relation). With many relations entereing a class from the same side, the labels are often drawn "over" the relation to the right, where centering would be more readable.

I do not understand, I already do that, this is why the menu of a relation proposes label default position to move them back to their not manual position

In this context it would also be helpful to rotate the labels to match the relation's angle.

ouch, if the labels follow the angle of the relations this will be unreadable, no ?

- Also, I sometimes have labels in the middle of nowhere. To handle those, it would be nice to get to the relation dialog when (double-)clicking on them, or some other help to find out to which relation they do belong

This is because you moved them, and again just use label default position ... but this must be done on the relation, currently a label doesn't know its associated relation, so this is not possible to ask for that directly on a label, this doesn't help

[chr_h]

Hello,

I should reiterate that the suggestions are merely some ideas on my part, you'll have to decide for yourself if they make sense or steer bouml in the
wrong direction.

Regarding the dot grid, I was thinking of the second version. It is much less obtrusive, and serves the purpose of "help lines" for precise
alignment just as well. By the way, I got the idea from another great French product, http://www.bloc-rhodia.com/cat/rhodia-basics/dotpads/

I get the problem of a 'snap to grid' for rectangles. For it to make sense, one would have to enforce that the dimension of the rectangles are
multiples of the grid size (well, multiples of twice the grid size actually, if you use the center as reference). I understand if you don't want to do
this, although I'd still use the feature if it were there.

The minimum width of the formals box is half of the class width, I did that choice because I supposed this proportion is nice

Huh, I never looked at it this way. You are right, the proportion is nice. And with the possibility of increasing the workspace area beyond A0, space
is no longer an issue.

The zoom... well, that's a tricky one. I can follow your points. However, I have a different perspective: for me, the (only) reasons to use the zoom
are (a) to get an overview of the whole diagram and (b) to arrange the items "globally". Due to the mechanics you use, this is not really possible (as
relative class dimesions change with zoom level). Just floating an idea... you could think about another level of "semantic zoom": for class diagrams,
for example, you could scale the dimensions of the "box" exactly, and remove the written content, except, for example, the class name. Then, the name
could be displayed large enough to be readable (which it currently isn't for low zoom values), and the function/parameter names are removod altogether
(which currently aren't readable anyways when zoomed out).

And finally, the labels.
The current default positions. If we didn't know that a generalization cannot have a label, we would be lost...

(yes, we could increase the class size, but of course a real GUI toolkit would have a lot more relations to its widget base class than are shown here...)

What I mean by centering - slightly better, but still far from good


The labels aligned to the relation angle - I find this the most readable solution, but that's probably up to taste


An automatically set stereotype position, which I find suboptimal, and which gets worse for larger distances between the classes. The problem becomes slightly annoying when you have several of these labels and no clue to which relation they belong



Cheers
Christian

[Bruno Pagès]

Hello,

The zoom...
... (as relative class dimesions change with zoom level). Just floating an idea... you could think about another level of "semantic zoom": for class diagrams,
for example, you could scale the dimensions of the "box" exactly, and remove the written content, except, for example, the class name. Then, the name
could be displayed large enough to be readable (which it currently isn't for low zoom values), and the function/parameter names are removod altogether
(which currently aren't readable anyways when zoomed out).

Two remarks :
- classes like some other kind of elements in diagrams can be resized manually, so you can increase their width and/or height, in that case the zoom will respect their proportions because the size of the texts inside have no undesirable effect
- you can ask by yourself to hide attributes/operations, for a given class or all in a given diagram or ..., through the drawing settings, like for the shadow (again please refer to the the video tutorial http://www.bouml.fr/video/starting.wmv from 10:43)

This is not directly link to your remark but let's note you can also limit the width of the attribute/operation definitions using the drawing settings member max width

And finally, the labels...

Yes it is not easy to have a readable diagram when there are a lot of labels, and to separate them by default the role name and multiplicity are each on a side of the relation, and the stereotype is centered on one of the segments of the relation (you can choose the segment supporting the stereotype)

Yes it may be more readable to turn the labels like you in the example you give, but this suppose you use only horizontal / vertical else with different angles this become crazy, and to put name and multiplicity on the same side. I note that possibility but frankly not for a short term delivery

Concerning your last diagram the stereotype is far of its relations because you moved the label by hand, or there is a bug I don't know

Thank you for your remarks

[chr_h]

Hi,

Concerning your last diagram the stereotype is far of its relations because you moved the label by hand, or there is a bug I don't know

I didn't touch the label, this is the behavior for automatic positioning. It's under Debian GNU/Linux jessie, so in case the position is not what you intended in your code, its a... let's call it "hidden feature"

[Bruno Pagès]

oh yes, this happens when using crtl^l one time to cut the line, a second ctrl^l correct the position etc
also to ask for the default label position correct the position

I didn't see because I tried cutting the line by hand (moving the mouse button down from somewhere in the line)

so an update of the position of the stereotype is missing ( role name and multiplicity are well moved), this is a very old bug

[Bruno Pagès]

Hi,

The release release 6.11.1 is available, correcting the bug about the stereotype/label position after the modification of the geometry, and changing the drawing of the grid now using cross
Best regards,

Bruno Pagès