I don't see the usefulness of the little anchor emoji. It's unintuitive: the first time I saw it I tried to interact, but nothing happens (after, I learned it's meaning). Also, if you unsnap the MapOverview the anchor emoji just stays there, without any meaning.
Good point. @danix800 I would remove it completely, how do you see it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When the overview is moved away from the corner the anchor could be used as indicator that it's still pinned to that corner, which means the overview window does not change its relative position to that corner.
But if it does cause visual distraction I'm OK without it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About zooming using the mouse wheel with the cursor over MapOverview: it starts behaving strangely once you move the purple rectangle inside the MapOverview (the focus spot). See the FP.mp4 attached. I start with the yellow node selected; move the focus spot; zoom out and it goes in a diagonal trajectory in direction of outside the map; zoom in and it starts a diagonal trajectory in the direction of selected node. In my opinion, it's a better behavior if the zoom has as a pivot the center of the focus spot itself. In yEd.mp4 attached you can see how it behaves in yEd. I think this makes more sense, because, once you move the focus spot to a certain area of the map, when you zoom in and out you are interested in the spot.
I am really upset to see any bug reports in forum threads.
Each bug report should be handled separately.
Each bug must be reported as a separate bug ticket.
Regarding to the observed behavior I can say that I can not reproduce it.
But I do not like having any bug related discussions in the forums.
So please create a bug report and let us continue the topic there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the zooming and focusing is a feature, not a bug. The implementation might've chosen a different semantic of focusing, which is a map node, rather than the natural mouse point over the view. I think using node as focusing point is reasonable and better than natural mouse point.
There're some preference options which are related to the zooming and focusing behavior, like Preference -> Behaviour -> Zooming keeps selected node position or Preference -> Behaviour -> Zooming keeps selected node visible, which are worth trying, @eu
As for the overview implementation, the zooming is just redirected to the underlying map view, so the behaviour would be the same when zooming.
Last edit: Ding Fei 2021-06-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@danix800 You explained me what happens.
If both options are deactivated we observe behavior reported by eu because in this case the zooming keeps position of the mouse cursor related to the map view.
But if the cursor is placed over the overview pane I think it makes no sense. Try it yourself.
So I think we need to fix it as suggested by eu.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be very easy to keep the current center of the viewable area because calculating of this point is trivial, but I think that zooming around the cursor at the overview pane would be nicer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I seems the 9 handles on the overview map should appear only if the
overview map is clicked. If it is the map that is clicked then the
handles should disapear. Usually it is like this in other apps it
seems. Like in drawing apps like open office draw objects etc.
It would be very easy to keep the current center of the viewable area
because calculating of this point is trivial, but I think that zooming
around the cursor at the overview pane would be nicer.
Dimitry:
The panning with the menu options Scroll-Left, Scroll-Right, Scroll-Up
and Scroll-Down, once assigned the proper keyboard shortcuts, is perfect.
I'm so glad you had a moment to implement that.
Thank you so much. :-)
You can switch this control on and off, and the full screen setting is separate from the windowed setting like for other controls
Now, I see it can be activated in the rightclick menu.
which means the overview window does not change its relative position to that corner
Now, I see. This is only relevant when the person is resizing the FP window, right? But, isn't it visually intuitive to know the corner (that is the reference) once the user starts resizing the window?
I just noticed something "curious". Steps to reproduce:
-you are editing the node contents inline
-use the mouse wheel over the overview to change the zoom
-the node content size will stay frozen (although you can still edit it normally) and everything else will change its size
Probably unintended, but I don't know if it qualifies as a bug. Some people can find it useful, because you can quickly change the scale of the map while keeping the node being edited on the desired size. I don't know if it already existed a way to do it before. See FP2.mp4 attached.
Just tested 1.9.4-pre02 here. It's a big improvement. The zoom steps are perfect for me. The zoom to the cursor is excellent (way better than the yEd way). It's almost awesome... but it is a little buggy in some situations. I will report that in a ticket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Dimitry, dear Ding Fei,
I'm currently using 1.9.4-pre01 and I didn't realize before that I needed "Map Overview" so badly!! Now that I have use it, I can't live without it.
It's a great feature and it allowes me to retain mentally a global view of the map while working in specific branches.
Thanks again!
edo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the resizing of the map.
Is it possible that each overview map keep their own size. I noticed that resizing one will resize it in all views/maps. It seems that resizing one overview map should not resize the others as all maps have different heights and sizes so the overview map should not be the same size on each (it seems).
Also it could be useful maybe to save the size (width, height) of all overview maps when quitting freeplane and then opening it again will set them to the previous size.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your ideas.
I am afraid it would make the logic over complicated.
As always I am inviting you to share some screen shots to prove your request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We could consider implementing this as a new complemental feature, rather
than a replacement. The original behaviour is pretty good to me.
Last edit: Dimitry Polivaev 2021-06-07
You can switch this control on and off, and the full screen setting is separate from the windowed setting like for other controls
Good point. @danix800 I would remove it completely, how do you see it?
When the overview is moved away from the corner the anchor could be used as indicator that it's still pinned to that corner, which means the overview window does not change its relative position to that corner.
But if it does cause visual distraction I'm OK without it.
I am really upset to see any bug reports in forum threads.
Each bug report should be handled separately.
Each bug must be reported as a separate bug ticket.
Regarding to the observed behavior I can say that I can not reproduce it.
But I do not like having any bug related discussions in the forums.
So please create a bug report and let us continue the topic there.
I think the zooming and focusing is a feature, not a bug. The implementation might've chosen a different semantic of focusing, which is a map node, rather than the natural mouse point over the view. I think using node as focusing point is reasonable and better than natural mouse point.
There're some preference options which are related to the zooming and focusing behavior, like
Preference -> Behaviour -> Zooming keeps selected node positionorPreference -> Behaviour -> Zooming keeps selected node visible, which are worth trying, @euAs for the overview implementation, the zooming is just redirected to the underlying map view, so the behaviour would be the same when zooming.
Last edit: Ding Fei 2021-06-07
@danix800 You explained me what happens.
If both options are deactivated we observe behavior reported by eu because in this case the zooming keeps position of the mouse cursor related to the map view.
But if the cursor is placed over the overview pane I think it makes no sense. Try it yourself.
So I think we need to fix it as suggested by eu.
It would be very easy to keep the current center of the viewable area because calculating of this point is trivial, but I think that zooming around the cursor at the overview pane would be nicer.
I seems the 9 handles on the overview map should appear only if the
overview map is clicked. If it is the map that is clicked then the
handles should disapear. Usually it is like this in other apps it
seems. Like in drawing apps like open office draw objects etc.
On 07/06/2021, Dimitry Polivaev dpolivaev@users.sourceforge.net wrote:
There's a PR for this but I did it purely for exercising and it's not a big improvement so don't expect it to be accepted.
Confirmed, there's a PR 217 for fixing this. Nice catch and thanks for reporting this.
Dimitry:
The panning with the menu options Scroll-Left, Scroll-Right, Scroll-Up
and Scroll-Down, once assigned the proper keyboard shortcuts, is perfect.
I'm so glad you had a moment to implement that.
Thank you so much. :-)
Now, I see it can be activated in the rightclick menu.
Now, I see. This is only relevant when the person is resizing the FP window, right? But, isn't it visually intuitive to know the corner (that is the reference) once the user starts resizing the window?
This means you now understand what I said, or I still need to clarify? I'm not talking about the good old zoom in the main view.
I did not see this as a bug, but as an option of behavior.
Thanks for pointing that out. I got really happy when Dimitry implemented it.
+1 on that.
I just noticed something "curious". Steps to reproduce:
-you are editing the node contents inline
-use the mouse wheel over the overview to change the zoom
-the node content size will stay frozen (although you can still edit it normally) and everything else will change its size
Probably unintended, but I don't know if it qualifies as a bug. Some people can find it useful, because you can quickly change the scale of the map while keeping the node being edited on the desired size. I don't know if it already existed a way to do it before. See FP2.mp4 attached.
Just tested 1.9.4-pre02 here. It's a big improvement. The zoom steps are perfect for me. The zoom to the cursor is excellent (way better than the yEd way). It's almost awesome... but it is a little buggy in some situations. I will report that in a ticket.
Dear Dimitry, dear Ding Fei,
I'm currently using 1.9.4-pre01 and I didn't realize before that I needed "Map Overview" so badly!! Now that I have use it, I can't live without it.
It's a great feature and it allowes me to retain mentally a global view of the map while working in specific branches.
Thanks again!
edo
Thanks for the resizing of the map.
Is it possible that each overview map keep their own size. I noticed that resizing one will resize it in all views/maps. It seems that resizing one overview map should not resize the others as all maps have different heights and sizes so the overview map should not be the same size on each (it seems).
Also it could be useful maybe to save the size (width, height) of all overview maps when quitting freeplane and then opening it again will set them to the previous size.
Thanks for your ideas.
I am afraid it would make the logic over complicated.
As always I am inviting you to share some screen shots to prove your request.