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

chr_h wrote: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

chr_h wrote:- 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")

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

chr_h wrote:- 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

chr_h wrote:- 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 niceI can parametrize that proportion, or allow to have the smaller width, but is it really important, there are already so much drawing settings

chr_h wrote:- 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

chr_h wrote:- 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

chr_h wrote: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 ?

chr_h wrote:- 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

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 precisealignment 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 dothis, 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, spaceis 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 zoomare (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 namecould 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

chr_h wrote: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 namecould 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

chr_h wrote: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

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"

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 crossBest regards,