Automatic elimination of blank areas in diagrams (companion to #5841)

[ceraolo]

This is a companion discussion to ticket #5841, and should be considered once that ticket is solved.

Very often programmers leave ample blank areas around their diagrams. I think this is not done on purpose, just they concentrate on their activity and don't care about blank areas.

To fix ideas, consider PowerGrids.Examples.Tutorial.GridOperation.Static.PowerFlow, as in Diagram1.png.

Blank areas reduce the size of the useful objects, and this reduces diagram visibility especially when they are shown in the Plotting perspective, sharing desktop space with plot windows.

To improve the situation, I think that an "Extent to contents" function should be provided, which would eliminate blank areas outside the actual diagram content, giving as result something like what shown in Diagram2.png (where, before clicking, I slightly displaced the System box).

Obviously, the same effect can be obtained manually changing the extent: this button would just make it much faster.

A possible implementation of this button could be to choose the extent to be the smallest rectangle containing all the diagram elements (maybe making an exception for the outer interfaces), with values being divisible by 10. The tool would also center the diagram content to the extent.
This "Extent to contents" function would not require a button of its own: it could simply be associated with the already existing "Reset Zoom" button, e.g. using CTRL+click on that button.

Any support for this idea?

[casella]

I'm for it!

[ceraolo]

Some further thinking on this ticket.

After several years of usage of Modelica, personal and through my students, I understand that all users either struggle with the diagram extent of treat it negligently with poor results.

In reality, other environments have not such an idea of the "sheet size" (the diagram extent): you just have your drawing and can use some "fit to screen" function or zoom in and out.

The Modelica Extent concept is a bit tricky, for me. But it is there, and I think nobody would accept to change it.

The usage of the "Extent to contents" button I propose in this ticket should be very fast to implement and would solve 90% if the issues related to the use of a page in Modelica.

@adeas, what do you think? Could this be done with little effort as I expect?

[casella]

I agree. I understood the extent concept only after many years of use; if nobody explains the thing to you, it's not obvious what it means.

I think having a "fit to extent to diagram" button that automatically adjusts the extent of the diagram (and not the extent of the icon) would be really great.

[casella]

See also #6139, it would be nice to take the opportunity to also fix that one.

[casella]

Retargeted to 1.17.0 after 1.16.0 release

[adeas31]

Looking at the two attachments it seems that for Diagram2.png you have actually changed the extent of the model. If this is what we want to do with the new "Fit extent to diagram" button then note that this means that the model will be modified with that operation. Is this what we want or do we just want to zoom in the model until everything is visible without changing the extent of the model?

[ceraolo]

Replying to adeas31:

Looking at the two attachments it seems that for Diagram2.png you have actually changed the extent of the model. If this is what we want to do with the new "Fit extent to diagram" button then note that this means that the model will be modified with that operation. Is this what we want or do we just want to zoom in the model until everything is visible without changing the extent of the model?

Yes, when I opened the ticket I meant the button would modify the extent on model with that operation.
The button I thought of would have the same meaning of a button doing this in Microsoft Visio (in Italian it is called "adatta al disegno", that could be translated into "adapt page to drawing").
In Inkscape if you zoom a drawing, when you reopen it you'll see at the same zoom level you left it. So, in both cases, the occupancy of the available window is stored inside the drawing (i.e. the drawing file is changed).

Before confirming that this is what it is best for OMEdit, however, I prefer to discuss here its rationale and a different alternative to reach the same purpose.

The purpose of this ticket is to reduce the number of user clicks.

I expect that the user likes to exploit all the available space, when looking at the diagrams, when in modelling perspective and, even more important, in the plotting perspective, where the available space is more limited because the screen is shared with plot windows.

If the "fit extent to diagram" function is implemented, when users open a diagram they will find it already free from blank spaces around.

A possible second way to attain this reduction in the number of user clicks is a function "don't use diagram extent". When this function is activated, when users open existing models, they will be shown them zoomed in such a way that they occupy the whole available window size.
Then, in case of need, users can manually zoom into details or pan back using the already existing zoom buttons. If this second option is chosen, I don't see any reason to show the white square (or rectangle) of the extent. A huge change! But, I expect, very welcome for all the serious users.
The default extent of OMEdit would be used only when opening new models, to determine the initial diagram area.

This second solution would have the advantage that also when opening models of existing libraries users would see them at the largest size (both in modelling and plotting perspectives), without having to tamper with them changing their extent.
In fact, I noted that the large majority of library writers don't bother about choosing an extent different from the default, and there are therefore many models that with current OMEdit behviour occupy just a limited portion of it. You must zoom all the time, and I don't like this.

So there are two alternatives:

1. a "Fit extent to diagram" command
2. "don't use diagram extent"

For me, both are good, with a slight preference for the second option. What's your opinion?
@casella which would you think is better?

Finally: I think this ticket should not change the OMEdit behaviour when dealing with icons.

[casella]

My only comment is that diagrams are usually built on a relativey coarse grid, which helps keeping things aligned. From this point of view, "fit extent to diagram" sounds good, because it preserves the original positions, while "scale diagram to extent" would end up with the position of the components having odd fractional values rather than, say, multiples of 2, which would make the further maintenance of such a diagram difficult.

[adeas31]

I am also in the favor of 1. a "Fit extent to diagram" command. The only drawback with it is that it is not possible to use it on System Libraries as they are read-only. One alternative could be that in case of read-only we use the same button to increase the zoom instead of modifying the extent.

[casella]

Replying to adeas31:

I am also in the favor of 1. a "Fit extent to diagram" command. The only drawback with it is that it is not possible to use it on System Libraries as they are read-only. One alternative could be that in case of read-only we use the same button to increase the zoom instead of modifying the extent.

Sounds good.

[ceraolo]

ok.
It looks like we can proceed with option 1.
When adapting extent to diagram we could use the coarse grid Franceso mentions.

If instance we chose 10 units resolution possible rectangles 40X60, or 40x80, could be automatically set, but not 42x26 75x80, etc.

This 10 (or better 20?) point resolution seems to me a good default choice; ideally this choice should be under user control through OMEdit options

[adeas31]

I added the button "Fit to Diagram" in 9ac6586/OpenModelica.

The button does 2 things,

1. For user models it modifies the extent i.e., shrinks/expands the extent based on the diagram contents.
2. For read-only system models it zooms in/out based on the diagram contents.

[ceraolo]

I'll look at it tomorrow, Thanks

[casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[ceraolo]

Forget about the enclosed buck model (which I don't know how to delete). It had issues not depending on this ticket.

[ceraolo]

I checked the "fit to Diagram" button behaviour, and in simple cases seem to work very well (I need further tests)

In more complicated cases, something should be improved.

Consider the following model fro PowerGrids Library:
Examples/ENTSOE/SteadyState.mo

If you click Fit to Diagram on it, the outcome is not satisfactorily: there remain white areas on all four sides (especially left).
I enclose screenshots "before" and "after" taken on my home PC.

Instead of reducing, left space has increased; the right space could be reduced further;
The bottom space could be reduced and was not.

I'm not even sure that the half square on top is the best solution: OMEdit always uses some gray margin around the white page (both in modelling and plotting perspectives). This allows letting the diagram to fill the whole space if it is possible.

[adeas31]

Yeah I see the button behavior was not perfect. I tried to improve it in ​PR#7203. You can try it tomorrow and let me know your feedback.

[ceraolo]

I've checked, and now it works basically as expected.

There is still a minor glitch.
It is expected that the diagram size is symmetric with respect to zero, otherwise, the two thicker lines (vertical and horizontal) are not midway. See the enclosed "unsymmetric.png"

Could you make this final tuning?
Thanks

[adeas31]

I didn't quite get it. The thicker lines are aligned to (0,0). Do you want to align them to the new center?

[casella]

I don't get it either. @ceraolo, which thicker lines are you referring to?

Also, I'm not sure what do you mean by the diagram size being symmetric w.r.t. zero. I won't move around the blocks, only change the extent of the diagram.

If the blocks were initially aligned on some coarse grid, which is normally a good idea to keep the diagram tidy, moving them around could disrupt that alignment, making it difficult to edit the diagram properly after that.

[ceraolo]

For asymmetric.png OMEdit has chosen the following data:
Left: -150 Right: 60

Therefore the vertical thick line of the white rectangle is 3 white squares from the right and 7.5 from the less: too asymmetric, for me.

I don't see any good reason for having this line in a position different from the centre of the white space, near the centre.

It would be better if the chosen data were (with the same horizontal span):

Left: -110 Right: 100
or
Left: -100 Right: 110

If I had as the calculated original data
Left: -160 Right: 60

I would have recommended instead
Left: -110 Right: 110

Obviously, the purpose of this ticket is to have the whole diagram content inside the white area, so using these "symmetric" extent values and still having the diagram inside the white area, would involve moving rigidly the diagram by an integer number of squares.

This is what I have manually done for years and would expect the software be able to do for me when I click on the new button.

Nevertheless, is this is extremely difficult to reach, we can give up. After all, the thicker lines are rather meaningless for me: it is a little more than a question of aesthetics

[casella]

An integer number is not good enough, we should use a multiple of the grid step value, so that the blocks do not end up in some "half positions" that cannot be reproduced if you start moving around those blocks afterwards, or you add more stuff to the diagram.

So, maybe we could try to rebalance the center of mass of the diagram by moving the blocks by an appropriate number of grid steps, and then set the extent to be symmetrical and with multiples of 10, so we don't have "half squares" around.

@ceraolo, what do you think?

[ceraolo]

Replying to casella:

An integer number is not good enough,

I said an integer number of squares, not an integer number.

I know that the large majority of MSL components have as icon squares large as any of the small squares of the default diagram size, and I like it.

That's why I proposed to move the diagram by an integer number of squares (not just an integer number).

Regarding half square at the sides, I've not a precise position.
I've noticed that OMEdit when the fit button is clicked, sometimes creates a diagram having empty half squares round. This is acceptable for me.
The proposal from @casella of avoiding half squares is acceptable as well, but it should be guaranteed that a full row or column of empty full squares is avoided. Having components that "touch" (without going outside) the border of the diagram extent is acceptable

[casella]

Replying to ceraolo:

Replying to casella:

An integer number is not good enough,

I said an integer number of squares, not an integer number.

Sorry, that's right, so multiples of 10 units. Sounds good to me, this is a safe assumption.

Regarding half square at the sides, I've not a precise position.
I've noticed that OMEdit when the fit button is clicked, sometimes creates a diagram having empty half squares round. This is acceptable for me.

To me also, but I guess rounding at 10 would be nicer.

The proposal from @casella of avoiding half squares is acceptable as well, but it should be guaranteed that a full row or column of empty full squares is avoided. Having components that "touch" (without going outside) the border of the diagram extent is acceptable

Agreed

[adeas31]

The values are rounded at 10.

@cerelo I pushed in a change yesterday so can you please try the latest nightly build?

[ceraolo]

good improvement!

For me there is just a final polishing recommended:
consider the enclosed RTL model, after clicking on the fit button.

I don't see any good reason for the half square at its left side.
can you check?

[adeas31]

I guess is possible to go for full square. The only good and safe solution for it is to expand in most cases which means we are not really exploiting the white space.

[ceraolo]

Replying to adeas31:

I guess is possible to go for full square. The only good and safe solution for it is to expand in most cases which means we are not really exploiting the white space.

I'm not gainst half squares in general, I do want to exploit all the available space!

The issue with RL.mo is that the left half square is totally empty and therefore it could be avoided without sacrificing anything. Have you tried to load it and have a look? There should be a really tiny mistake in computing the needed squares that adds this unneeded half square
(see half.png)

[adeas31]

This is because for example the number 34 is always expanded to 40 and not to 30.

[ceraolo]

The extent chosen by the button with RL.mo is
Left-Right: -70, 80

A better filling would have been this case -60, 80. Yes, the numbers are a little asymmetric, but the user would see a better filling of the available space without any drawback.

Maybe I miss something, but It seems feasible to me. Obviously, this is just a possible final touch of a job that has been already done satisfactorily.

[adeas31]

Yeah so -70 is intentional since the algorithm prefer expand over shrink. I can make it -60, 80 but this will not guarantee that all the items are inside white square.

[adeas31]

There is a ​PR#7231 on the way that will do what you want. You can try it tomorrow. Lets see which one you prefer.

[adeas31]

@ceraolo what do you think now? Can we close this?

[ceraolo]

I think it works nicely, now.
I'm going to close this ticket.

[ceraolo]

Consider the model "Test.mo".
1) open it and click on "Fit to Diagram" => the blank areas are adapted to the model.
2) save and reopen it => the blank areas are much larger now, and the diagram is not centered into them.

[adeas31]

Fixed in 82684d4/OpenModelica and also ported to 1.18