Opened 8 years ago

Closed 7 years ago

#4308 closed enhancement (fixed)

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

Reported by: janK Owned by: adeas31
Priority: normal Milestone: 1.12.0
Component: OMEdit Version:
Keywords: Snap to grid coase shift key pan view control key Cc:

Description (last modified by janK)

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)

Change History (18)

comment:1 Changed 8 years ago by janK

  • Description modified (diff)

comment:2 Changed 8 years ago by adeas31

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.

comment:3 Changed 8 years ago by janK

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!

comment:4 Changed 8 years ago by janK

  • Keywords pan view control added
  • Summary changed from OMEdit: Snap to grid coarse modifier (shift key) to OMEdit: Snap to grid coarse modifier (shift key) and pan view (control key)

comment:5 Changed 8 years ago by adeas31

  • Milestone changed from Future to 1.12.0
  • Status changed from new to accepted

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.

comment:6 Changed 7 years ago by adeas31

Panning is available now d48d23a/OMEdit.

comment:7 Changed 7 years ago by janK

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.

comment:8 Changed 7 years ago by adeas31

  • Resolution set to fixed
  • Status changed from accepted to closed

Done in f627d1/OMEdit.

comment:9 Changed 7 years ago by janK

Nice - I like that!

comment:10 Changed 7 years ago by janK

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.

comment:11 Changed 7 years ago by janK

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:12 Changed 7 years ago by adeas31

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].

comment:13 Changed 7 years ago by janK

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).

comment:14 Changed 7 years ago by adeas31

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

comment:15 Changed 7 years ago by janK

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)?

comment:16 Changed 7 years ago by adeas31

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.

comment:17 Changed 7 years ago by janK

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

comment:18 Changed 7 years ago by janK

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.