[ICONS] different select icons and "show add-node mouse-icon in select mode over red plus"

[dieterdreist]

show add-node icon in select mode over red plus, i.e. when within snapping-distance. This would be nice to give the user a feedback for snapping while selecting or refining. The icon should be the same one as for add node.

[xeen]

Can you create icons for "snapping", "select * node", "select * way" and "select * multiple" with * being add or remove? (because it's possible to add/remove items from the selection)?

[dieterdreist]

Replying to xeen:

Can you create icons for "snapping", "select * node", "select * way" and "select * multiple" with * being add or remove? (because it's possible to add/remove items from the selection)?

yes, I will try to do so as soon as I have some time. Where do you want me to post the icons? Here?

[xeen]

I guess this is the best idea, so they don't get lost.

[dieterdreist]

Replying to xeen:

I guess this is the best idea, so they don't get lost.

May I raise here some attention? I think that it is quite easy to get this behaviour, unfortunately I am not able to code it myself.

[dieterdreist]

icons for the selection mode

[dieterdreist]

OK, I created 6 new icons and uploaded as attachment. The usage should be like this:

• select.png - normal selection with rectangle (not in snapping range)
• select_way.png - way in snapping range
• select_way_add.png - add way in snapping range to existing selection (modifier pushed)
• select_way_remv.png - remove way in snapping range from existing selection (modifier pushed)
• the same like for way also for select_node
• add_node (from add-mode) to use when in snapping range of the red-plus (refining in selection mode), not included, use the existing icon
• rotate for the rotation (remains untouched, not included)

[dieterdreist]

add to an existing selection

[dieterdreist]

icon remove from an existing selection

[dieterdreist]

Replying to dieterdreist:
added 2 more icons:

• add and remove from selection by dragging a selection rectangle (start dragging outside snapping radius)

[xeen]

I'll try to implement this similar to the way draw mode works. This means that the target node and way will be highlighted (this works already) in addition to the cursor (doesn't yet work).

However, there is still the problem of highlighting the target virtual node. Since those aren't OsmPrimitives it's not possible to leverage the existing highlight method. I traced the way from SelectAction to MapPainter and only a boolean "virtualNodesEnabled" is passed throughout whole JOSM. I haven't investigated thoroughly, but as far as I can tell it isn't ever used anywhere except in MapPainter… which then uses the following gem:

this.virtualNodeSize = virtual ? Main.pref.getInteger("mappaint.node.virtual-size", 8) / 2 : 0;

Since on/off is determined by the same variable (i.e. >= 1 means on) it might be worthwhile to remove all that passing through and directly query the variable.

To get back on topic. It doesn't sound too appealing to pass which vnode to highlight through a dozen layers, nor does turning vnodes into a real class which support states per instance. I tend to just draw directly over the vnode with the same settings as one would expect (size, highlight color). This isn't exactly the bee's knee, however since vnodes are drawn on top of everything in my experience it *could* work. It still is ugly, so I welcome any suggestions on how to implement this nicely. Adding comments in both places could ensure the style doesn't get out of date, but it's more of a hack than a solution.

Any comments?

[bastiK]

Replying to xeen:

I'll try to implement this similar to the way draw mode works. This means that the target node and way will be highlighted (this works already) in addition to the cursor (doesn't yet work).

However, there is still the problem of highlighting the target virtual node. Since those aren't OsmPrimitives it's not possible to leverage the existing highlight method. I traced the way from SelectAction to MapPainter and only a boolean "virtualNodesEnabled" is passed throughout whole JOSM. I haven't investigated thoroughly, but as far as I can tell it isn't ever used anywhere except in MapPainter… which then uses the following gem:

this.virtualNodeSize = virtual ? Main.pref.getInteger("mappaint.node.virtual-size", 8) / 2 : 0;

Since on/off is determined by the same variable (i.e. >= 1 means on) it might be worthwhile to remove all that passing through and directly query the variable.

To get back on topic. It doesn't sound too appealing to pass which vnode to highlight through a dozen layers, nor does turning vnodes into a real class which support states per instance. I tend to just draw directly over the vnode with the same settings as one would expect (size, highlight color).

Maybe pass a WaySegment object (the "active virtual way segment") to the MapPainter in OsmDataLayer l. 259. Then compare it to each way segment that is about to get a cross hair in the centre in MapPainter.visitVirtual.

Another option would be, to turn SelectAction into a MapViewPaintable (like DrawAction) and hand over the cross hair node painting to the map mode.

This isn't exactly the bee's knee, however since vnodes are drawn on top of everything in my experience it *could* work.
It still is ugly,

Agree with that. :)

so I welcome any suggestions on how to implement this nicely. Adding comments in both places could ensure the style doesn't get out of date, but it's more of a hack than a solution.

[xeen]

I have a basic version working, but it is not yet finished. Since I removed the 10 layers of passing drawVirtualNodes and because highlighting vnodes is very similar to highlighting WaySegments I implemented both while at it. Latter is required to implement targetHighlight for the deleteMode. Also moved the alt/shift/ctrl detection to MapMode because the copy-paste was getting annoying.

In return this means the patch will become quite large, so I hope someone can help me test there were no regressions once I'm finished (I can remember it took ages to make the patch set work for draw mode).

@dieterdreist: can you provide an icon for when the cursor is above a virtual node?

[xeen]

@dieterdreist: oh wait, now I understood what you meant by “add_node (from add-mode) to use when in snapping range of the red-plus (refining in selection mode), not included, use the existing icon”.

So nevermind about that icon :)

[xeen]

As far as I can tell I have a working patch with no (new) bugs. Here's a JOSM version for you to try:
​http://mathphys.fsk.uni-heidelberg.de/~stefan/josm4318-cursor-and-highlight-party.jar

I hope I can get some feedback before actually checking the patch in. I'll see if I can split it up, but since eclipse re-wrote much code I didn't touch due to project style settings and SVN doesn't make it easy to split changes in one file I have to do this by hand. Also MapPainter has been patched, so let's see if SVN manages to merge :)

[xeen]

Here's what's actually changed:

• select+delete action have target highlighting
• select action has cursors hinting at what will be selected

• waysegments and virtualnodes can be highlighted and the painting bits have been added for the default and wireframe renderer. the highlight tracking variables belong to DataSet
• some code unification in the mapmode actions (modifier detection)
• added WaySegment.toWay() function as convenience (currently only used for drawing, haven't thought about if this might be bad)
• fixed a bug in DeleteAction, that will definitely become a seperate patch though :)

[bastiK]

Tried to test your patch, but there are too many new images. Can you zip them all and add here?

[xeen]

new icons used in the patch. Place them in bin/images/cursor/modifier

[bastiK]

One problem in select mode: How to see if a highlighted object is selected? If you move the mouse cursor over a way, it gets highlighted. Then, if you press end release the mouse button, there is no visual feedback that the way is now selected.

In delete mode, if you hover a node outside the downloaded box and press Ctrl, there is a popup window, preventing any action.

Highlighted nodes are much like selected nodes, just another color. However, highlighted icons are missing the frame, that selected icons have. It was like this before, but now this "glitch" is more apparent.

[xeen]

One problem in select mode: How to see if a highlighted object is selected? If you move the mouse cursor over a way, it gets highlighted. Then, if you press end release the mouse button, there is no visual feedback that the way is now selected.

true enough. Maybe only highlighting stuff that will get (de)selected helps? I.e. when in "add to selection" or "select this" mode, only not yet selected primitives would be highlighted. Similar for remove from selection, only selected items could be highlighted. I'm not sure though that this works in praxis, I'll try for myself if it isn't too complicated to implement.

In delete mode, if you hover a node outside the downloaded box and press Ctrl, there is a popup window, preventing any action.

hm… this doesn't happen for me or it occurs only in specific situations. Can you provide an example? It sounds like there's a missing "quiet" parameter somewhere. Which dialog exactly comes up for you?

Highlighted nodes are much like selected nodes, just another color. However, highlighted icons are missing the frame, that selected icons have. It was like this before, but now this "glitch" is more apparent.

Adding a frame could help, although tinting the icon might work better. In any case this is not directly related to this patch, so I'll implement this at a later point.

[bastiK]

Replying to xeen:

One problem in select mode: How to see if a highlighted object is selected? If you move the mouse cursor over a way, it gets highlighted. Then, if you press end release the mouse button, there is no visual feedback that the way is now selected.

true enough. Maybe only highlighting stuff that will get (de)selected helps? I.e. when in "add to selection" or "select this" mode, only not yet selected primitives would be highlighted. Similar for remove from selection, only selected items could be highlighted. I'm not sure though that this works in praxis, I'll try for myself if it isn't too complicated to implement.

Another option would be, to make some kind of halo to highlight an object, but this is more work to implement. Then you could have an object selected and highlighted at the same time. One technical advantage: You don't have to keep track, what way segments are "normal" and which are "highlighted", but you could simply draw the highlights additionally at a certain zoom level (say -300).

An intermediate solution could be another color for "selected & highlighted".

In delete mode, if you hover a node outside the downloaded box and press Ctrl, there is a popup window, preventing any action.

hm… this doesn't happen for me or it occurs only in specific situations. Can you provide an example? It sounds like there's a missing "quiet" parameter somewhere. Which dialog exactly comes up for you?

Download ​http://api.openstreetmap.org/api/0.6/map?bbox=-2.5122643,41.1305729,-2.4923515,41.145699, switch to delete mode, hover node 562876498 and press Ctrl. It says "You are about to delete nodes outside of the area...".

Highlighted nodes are much like selected nodes, just another color. However, highlighted icons are missing the frame, that selected icons have. It was like this before, but now this "glitch" is more apparent.

Adding a frame could help, although tinting the icon might work better. In any case this is not directly related to this patch, so I'll implement this at a later point.

Fair enough...

[xeen]

Another option would be, to make some kind of halo to highlight an object, but this is more work to implement. Then you could have an object selected and highlighted at the same time.

This seems to be the idea to shoot for, although I'll probably won't implement this for the wireframe renderer. Highlighting only stuff that will change the selection on click is implemented though.

One technical advantage: You don't have to keep track, what way segments are "normal" and which are "highlighted", but you could simply draw the highlights additionally at a certain zoom level (say -300).

I'm not sure I understand. Do you mean to put this in some other class or do you mean to simply draw highlights on top of existing ways instead of that if-else juggling? I did the latter for the wireframe renderer because I know there won't be graphical glitches. I wasn't sure about the style renderer because there might be problems with transparency where several styles get drawn on top of each other and one ends up with an undefined color. Is that not the case?

In delete mode, if you hover a node outside the downloaded box and press Ctrl, there is a popup window, preventing any action.

Fixed. Although this bug wasn't introduced by me, I rather uncovered it :)

I'll attach the patch with the only-highlight-changes and delete-dialog bug fixed shortly. I won't clean it up, so there's other unfinished stuff from my tree (shouldn't affect this area though).

[bastiK]

idea for highlight halo

[bastiK]

Replying to xeen:

Another option would be, to make some kind of halo to highlight an object, but this is more work to implement. Then you could have an object selected and highlighted at the same time.

This seems to be the idea to shoot for, although I'll probably won't implement this for the wireframe renderer. Highlighting only stuff that will change the selection on click is implemented though.

One technical advantage: You don't have to keep track, what way segments are "normal" and which are "highlighted", but you could simply draw the highlights additionally at a certain zoom level (say -300).

I'm not sure I understand. Do you mean to put this in some other class or do you mean to simply draw highlights on top of existing ways instead of that if-else juggling?

Yes, what I mean is to draw all way segments normally, and draw the highlight in addition. Either on top, but at the sides of the way or simply below all lines.

I did the latter for the wireframe renderer because I know there won't be graphical glitches. I wasn't sure about the style renderer because there might be problems with transparency where several styles get drawn on top of each other and one ends up with an undefined color. Is that not the case?

Could be, but I'd go for it anyway. The main line style (isProperLineStyle() == true) should usually not be transparent. Any other line styles for the highlighted object could be deactivated. Besides, transparent overlay for bridges / tunnels isn't that great, we could change this to thick / dashed casing.

[xeen]

Seems reasonable, especially if the halo-highlighting is implemented. This would solve the nodes-with-icons problem as well. I'll see about the halo, maybe it's not too complicated after all.

[xeen]

I've implemented a basic function that can draw a highlight similar to the one you suggested:

    private void drawHighlightForLine(Point p1, Point p2, BasicStroke line) {
        final float haloWidth = 10 + line.getLineWidth();
        // calculate orthogonal vector
        Pair<Float, Float> orth = new Pair<Float, Float>((float) p2.y-p1.y, (float) p1.x-p2.x);
        float norm = (float) Math.sqrt(Math.pow(orth.a, 2) + Math.pow(orth.b, 2));
        // normalize and adjust width, offset by p1
        orth.a = p1.x + haloWidth * (orth.a)/norm;
        orth.b = p1.y + haloWidth * (orth.b)/norm;
        final GradientPaint grad = new GradientPaint(p1.x, p1.y, highlightColor, orth.a, orth.b, transparentColor, true);
        g.setStroke(new BasicStroke(2*haloWidth, line.getEndCap(), line.getLineJoin(), line.getMiterLimit()));
        g.setPaint(grad);
        g.draw(new Line2D.Float(p1, p2));
    }

It only works for single 2D line because the gradient has to be calculated for each angle so that it actually fits the way and it's still a little rough. It draws too much at the end of each line/segment and the width settings needs tuning for different thicknesses. Also, I'll have to see if this works performance wise as in its current form it takes up to 2ms per segment.

[xeen]

example of two way segments being highlighted

[bastiK]

There is another method, demonstrated by the following style:

way[highlight]::h02,
way[highlight]::h04,
way[highlight]::h06,
way[highlight]::h08,
way[highlight]::h10,
way[highlight]::h12 { color: cyan; opacity: 0.08; z-index: -5; }

way[highlight]::h02 { width: +02; }
way[highlight]::h04 { width: +04; }
way[highlight]::h06 { width: +06; }
way[highlight]::h08 { width: +08; }
way[highlight]::h10 { width: +10; }
way[highlight]::h12 { width: +12; }

This should work better at the corners.

[xeen]

Isn't that the same as you suggested before you edited your comment? Anyway, I dismissed the idea of drawing the way 10 times because I believed it to be too slow. I implemented it and it isn't faster, but not so much slower either: I get about 2ms max (up to 8ms for whole ways) but it solves all the corner issues and it works the same way to draw whole ways. I guess I'll go with this approach.

[xeen]

using the new highlight-method and with some more bugs fixed

[xeen]

example highlights using the new method. way+its nodes are the hardest to make out, but it's noticable when the nodes get unhighlighted while editing

[xeen]

for those who want to try out, I've uploaded a new version with this patch to ​http://mathphys.fsk.uni-heidelberg.de/~stefan/josm-cursor-and-highlight-party.jar

[bastiK]

Looks good. I suggest to change the default highlight color in select mode from cyan to red (same as selection color). It would be a "potential selection" and wouldn't overly catch the user's eye.

I'm not sure, but the way highlight in select mode could be distracting or even annoying in practice. If you are trying to move way nodes or create crosshair nodes, the way will flicker in between. Maybe you just have to get used to it. One countermeasure would be, to make the way highlight slimmer / more transparent.

[xeen]

I'll clean up the patch and commit in then. I suggest leaving the target highlight on for now and we can fine tune it if it proves to be annoying. If all fails, it could be off by default for select mode. Potlatch 2 has it too and I never found it annoying there -- then again, it follows another concept.

[bastiK]

Sure, let's see how it works. In Potlatch 2 you cannot move nodes directly, you have to select the way first. So yes, it is a different concept. The node and crosshair highlight in select mode seem very natural to me and I wouldn't want to turn it off again. For consistency, way highlight is probably needed as well. It depends also on the performance of your machine: If repaint takes 200ms, it feels a little sluggish when you move the mouse over different objects.

[xeen]

Before I commit this, can you confirm that

if ((p.x < 0) || (p.y < 0) || (p.x > nc.getWidth()) || (p.y > nc.getHeight())) return;

in MapPainter:drawNodeIcon and drawNodeSymbol are not required? At least I commented them out and the code after wasn't executed if there were no nodes of that kind in the viewport (drawNode doesn't have this line either). However, if my testing was flawed this would be a huge perf impact I'd like to avoid :)

[bastiK]

I removed stuff like this already, but it seems, this one slipped through.

For Mercator projection, this condition should be completely superfluous. In other projections like UTM you'll have a small excess because meridians aren't straight lines. But I think it is negligible, especially if you zoom in to street level.

[xeen]

In [4327/josm]:

updates visual appearance of highlights and adds them to select and delete action

in more detail:

• add target highlighting to select action
• add target cursor to select action
• add target highlighting to delete action
• unify ctrl/alt/shift modifier detection in MapMode actions
• highlights are now a halo around the way/node instead of a color change
• default highlight color is now the same as the select color (red)
• ability to highlight WaySegments and VirtualNodes
• various style/whitespace nits
• fixes #2411

This patch touches a lot of areas, so please report any regressions in the map mode
tools. Also please add a comment to #2411 if you find to highlighting in select
mode distracting, so it can be fine tuned (or turned off by default).

[stoecker]

I like this changes a lot! Even virtual nodes included.

NOTE: #6737 may be caused by this, but I could not reproduce.

[anonymous]

Ticket #6749 has been marked as a duplicate of this ticket.

[anonymous]

Replying to anonymous:

Ticket #6749 has been marked as a duplicate of this ticket.

If you use the add mode, push ctrl, shift or alt and move the mouse the mouse icon of the new selection visualisation (r4327) is wrongly shown for some ms.

JOSM 4364 @ windows 7-64 with Java 7-64

[bastiK]

This problem can have its own ticket.