OMEdit: Snap to grid coarse modifier (shift key) and pan view (control key)

[Jan Kokert]

Dear developers,

when I implemented the very first version of the function 'icon snap to grid' in [18522] I also included that the snapping can be set to more coarse when holding down the shift key.
The code was improved in [23316] but on its way to the latest version somehow this feature has vanished.
Were there any complications? Was the feature unwanted?

In many applications like Word the shift key has a comparable function, so I would really appreciate if this feature is activated again. Thanks very much!
(Original ticket: #2477)

[Adeel Asghar]

AFAIK this is done to make the tool more like other Modelica tools e.g., Dymola. You can still do what you want but perhaps by holding down the ctrl key.

[Jan Kokert]

Thanks for your fast response.
In Dymola control key + mouse drag will pan the whole area. In my Dymola version (2016 FD1) holding down the shift key will result in something wired actually - an offset between the icon and the mouse pointer is added, the more you drag the icon around. I think this is a little Dymola bug and should be something like "coarsen the grid".
So shift key + mouse drag = coarsen grid goes totally in line with other established tools. And by the way: Why can’t OMEdit be a better tool than these tools? 8-)

So there are in total two issues:
1.) Control key + mouse drag does no pan as in Dymola - this should be added. Imagine you have just zoomed in with control key and mouse wheel and now you want to navigate (pan) to a certain position.

2.) Shift key + mouse drag does no coarsen grid (as it is supposed to be in Dymola). This will come handy to quickly draw diagrams with nice equidistant spacing. I propose a factor of 10.

In the current version of OMEdit both feature are not included.
So could you please add the code? - I already searched for the old tickets ;-) Thanks!

[Adeel Asghar]

I thought you are talking about moving components with keyboard :).

1.) Yeah we could include panning.
2.) I am not sure what do you mean by coarsen grid and why the factor should be hard coded when we have variable grid size.

[Adeel Asghar]

Panning is available now d48d23a/OMEdit.

[Jan Kokert]

I am not sure what you mean by coarsen grid

When moving (dragging) components with the mouse, currently the component snaps into every even position, as the grid is 2.
If one likes to draw by mouse a structure very fast or quickly adjust objects on major grid crossing point or exactly in the middle, it is handy if the component would snaps to positions which are oriented on a grid which is more coarse e.g. grid of 10 (coarsen factor of 5).
My idea is that holding down the [Shift] key + mouse drag will coarsen the grid temporarily.

Why the factor should be hard coded

The factor can be hard coded, as the coarsen is only temporarily active when the shift key is pressed. A factor of 5 resulting of a grid of 10 seems to be reasonable.

[Adeel Asghar]

Done in f627d1/OMEdit.

[Jan Kokert]

Nice - I like that!

[Jan Kokert]

Hi Adeel,

I had spoken too soon. Unfortunately, the new behavior is not what I intended with this ticket. In the current implementation, the INCREMENT while moving is coarsened. I thought of coarsening the grid, so the absolute coordinates.
E.g. if a component sits at (2|0) and you hold [Shift] and drag it to the right, it is placed on (12|0). But I thought, that (10|0) should be the position.

I guess the origin of the component needs to be considered as well. Anyway, Thank for working on that enhancement.

[Adeel Asghar]

Well that's what I thought earlier but then you said the factor could be hard coded and also I don't think so that's what you implemented in [18522].

[Jan Kokert]

With "hardcoding the factor" I mean:
There is a ratio (a factor) between the normal grid and the coarse grid. The normal grid is 2 and the coarse grid is 10 so the ratio is 10/2 = 5. I think it is not needed that in OMEdit this "5" can be adjusted by an option via an options dialog. Instead, this 5 can just be a "magical" number within the code.

This whole thing does not affect, of where the origins of both grids are. In the current implementation, the grid's origin is in the origin of the component. My comment from this morning points out, that the origin of both snap grids should be absolute at (0|0).

Consequently, my early implementation in [18522] was not correct.

I hope things are clearer now. In the end, the following use case should be realized:

If one likes to draw by mouse a structure very fast or quickly adjust objects on major grid crossing point or exactly in the middle, it is handy if the component would snap to positions which are oriented on a grid which is more coarse e.g. grid of 10 (coarsen factor of 5).

[Adeel Asghar]

Try 3d0d8a/OMEdit. I think this is what you want.

[Jan Kokert]

Snapping to coarse grid works a treat now!

Coincidentally, I realized that the dragging is a bit slow: when you drag a component, it takes a few ms to respond, especially in models with more components. Is that because the Modelica code is constantly updated in the background? Maybe this updating could be paused as long as the component is dragged (mouse button is down)?

[Adeel Asghar]

Nothing has been changed with the dragging.
The Modelica code is only updated when the mouse is released.

Can you share a test model?
Better is to close this ticket and create a new one.

[Jan Kokert]

OK, I will create a new ticket soon and I close this ticket then :)