Icon snap to grid function

[jan.kokert@…]

Hi!

In OMEdit it would be wonderful to have a "snap to grid"-function.
As a first step it would be sufficient to change to datatype of the icon position from float to int, because coordinates like {-31.1321,-35.3773} are useless.
In a second step, an option could be added, to specify a rounding to "5" for example ({-31.1321,-35.3773} -> {-30,-35}.
Thank you so much!

[jan.kokert@…]

When will this feature be added?
For me this is very important - otherwise the editor is not useable!

I could try it by my own, but I don't want to damage the source code.

In trunk/OMEdit/OMEditGUI/GUI/Containers/ModelWidgetContainer.cpp
with every call like addComponent(QString className, QPointF position) the following should be added:
postiton.setX(qround(postiton.x());
postiton.setY(qround(postiton.y());

Thank you very much!

Kind Regards
Jan

[Christian Kral <dr.christian.kral@…>]

I think the requested feature is not only a matter of a nice look. Having a clearly structured graphical representation also support the professional appearance. So a am very much in favour of this feature!

[janK]

r18522 implements now a snap to grid function for components.
Snap to grid for annotations is in progress.

[dr.christian.kral@…]

The following report refers to the release r19727 (Ubuntu 12.04):

Great feature that the icons automatically snap to grid when moved by mouse. Holding down shift key snaps it to smaller grid! Wonderful. I really like that.

Yet I noticed, when moving models by cursor, they always move to the LEFT! This is a bug.

Shift+cursor keys already worked, manually moving a model on a smaller grid; but this is not working any more.

Snap to grid of annotations seems not be implemented yet.

[ceraolo]

In recent months the flattening and simulation capability of OM improved a lot.
So, for me, the need for OMEdit enhancements has become stronger.

Now icon snap-to-grid works well. I think a lot of people would appreciate a lot if the software is modified so that connecting lines are snapped to the same grid at they are model icons.

[janK]

Hi adeas31,

there is obviously a strong interest of improving the UI usability (Snapping and UnDo).
I wanted to do the job and did a few improvements in r18522.
But for snapping the connection lines to the grid, I was struggling with QT.
Right now, I admit that I don't have the time to implement the rest. So it would be great, adeas31, if you could implement the requested functions, because you’re very more into the code :)
Best Regards
Jan

[casella]

The MSL was developed using Dymola, which adopts a grid step of 2: if you check all Placement annotations in the MSL, the coordinates are always multiples of 2.

In order to avoid messing up with such models if they are edited or customized using OMEdit, I would suggest to adopt a default of 2 units as the grid size. I would also suggest to allow users to customize this, if they want.

[casella]

In fact, I noticed that the grid feature is already implemented in OMEdit as of r22673, and with a default step of 2.

However, if I drag some typical blocks from the Modelica.Blocks library and try to move then, the grid size seems to actually be 10.

Furthermore, if I try to resize them a) the size control is too coarse, and b) I cannot actually get back to the original size, which is particularly bad as an Undo feature is lacking.

Last, but not least, only the first and last segments of the connections are snapped to the grid, the rest isn't.

[sjoelund.se]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[adeas31]

Done in r23316.

[adeas31]

Replying to casella:

In fact, I noticed that the grid feature is already implemented in OMEdit as of r22673, and with a default step of 2.

However, if I drag some typical blocks from the Modelica.Blocks library and try to move then, the grid size seems to actually be 10.

Fixed the grid size. Default is 2.

Furthermore, if I try to resize them a) the size control is too coarse, and b) I cannot actually get back to the original size, which is particularly bad as an Undo feature is lacking.

Grid size is used while re-sizing the components. The undo feature is still not implemented see #2892.

Last, but not least, only the first and last segments of the connections are snapped to the grid, the rest isn't.

The connection lines are snapped to grid but they won't remain manhattanized when components/lines are moved. See #2506.

[janK]

I know that congratulations are kind of "unprofessional" in these tickets, but I really appreciate all affords to snap to the grid and the Manhattan-Project - Well done!

In r23393 there are only two remaining tiny issues, so I reopened the ticket:
1) Corners of ShapeAnnotations are snapping to grid, but dragging the whole shape allows totally free positioning, which is not a feature in my eyes.

2) A "funny" behaviour comes up if you draw e.g. an L with the line tool:
Take the line annotation tool and go to (0|20) [click] then to (0|0) [click] and then to (10|0) [double-click] for example. Then drag the first point somewhere. Now drag the last point and surprisingly the first point moves too, like a pantograph :)

I hope, you can fix this and finally close this ticket. Thanks!

[adeas31]

eeehhhhhh.........thanks for finding this out. I forgot to handle the case when shapes are dragged using mouse :).

I hope everything work fine in from r23410.

[janK]

Yes! Everything works fine in the latest version. Thanks!