cursor modifiers use only two colors under Linux systems

icon for mouse over a point in delete mode

icon for delete mode and shift (delete line/segment)

Misses two modes:

• Ctrl --> delete including references (i.e. node and ways through node)
• Alt --> only way, no nodes

Clearify: delete_l.png should be used in case shift is used and way is selected.

I'm not quite sure about the function of ALT and CTRL, could you specify more precisely their use?
I noticed that CTRL and ALT seem to have the same function when applied to way-segments: they delete the way and keep the nodes.

• When applied to a Node, ALT seems to be the same as normal left-click (delete the Node and keep rest of the way plus it's nodes)
• CTRL deletes the one node clicked plus all ways used by this node but keeps the rest of the nodes.

I personally think that this is advanced behaviour that 99,7 % of JOSM-users don't even know of. If you can provide an explanation to what it does (or confirm above described, but ALT doesn't seem to make something exclusively that can't be achieved by either normal click or CTRL) I will be pleased to make some icons for this too.

I was using JOSM 1486 for this test.

Your obervations are right. About the 99% your right too. That's why the icons are required :-)

Also see Shortcuts

OK, here is another icon which should be used for deleting just the way and leave the nodes. (delete_way.png)

icon to delete just the way and leave the nodes

alternative icon for delete way-segment (suits better together with newly added)

alternative icon for delete way and keep nodes

alternative icon for alternative icon ;-)

icon to delete node and way but keep the other nodes

OK, here is a summary of how the icons were intended to be used:

normal click on way: current delete icon: deletes complete way and all nodes that are not used otherwise

normal click on node OR click on node+ALT OR click on node+SHIFT: delete_p: deletes just this node

click on way + shift: delete_l2: deletes way segment

click on node + ctlr: delete_p+way: deletes clicked node and way, keeps rest of nodes

click on way + ALT or click on way + CTRL: delete_way_alternat: delete way, keep nodes

There are some duplicate / alternative icons:
instead of delete_way_alternat you could also use delete_way2_alternat OR you could use delete_way (not recommended but maybe could be tried) OR you could use delete_way2
the delete_l icon is not used because of delete_l2 icon (thus could be used as alternative, not recommended, the displayed line-symbol is shifted in respect to delete_l2 and delete_way)
These alternatives should/could be tested, to decide which one suits best. Maybe it could also be required for consistency to modify delete_p+way (make remaining nodes red like in delete_way_alternate). If so, please contact me.

noone for this? Do you want me to modify the icons?

It's not to modify icons. It about changing the code like the draw code has been changed by xeen, so the code always knows which icon to display. The icons are fine, that's not the problem.

For me there have always been more urgent issues than this one till now. But as long as it is a Trac issue it will not be forgotten.

This patch only implements the cursors, but not highlighting as known from the drawn mode. It would require WaySegment to be highlightable, but that's currently not implemented. Highlighting might need a revamp anyway, I'm not sure using 1 byte for each OsmPrimitive (+WaySegments) is the right way to go if like 99.9% of the time all these variables default to false. But well, that's out of scope of this bug.

I'll attach the icons in a zip file, I hope I got them right. If not, please update the icons. Naming logic:

• node: exactly 1 node
• segment: exactly 1 segment
• way_node_only: only deletes the node+way directly under the cursor
• way_only: only deletes the way directly under the cursor
• way_normal: delete way plus unused nodes

The patch contains one fixme: setCursor and the cursor-enum stuff are similar for delete/drawAction. They are not the same because I improved the logic for this patch. If dieterdreist provides icons for selectAction I'll update all actions and move setCursor to mapmode as stated in the patch.

Patch logic: do not re-implement the "deciding" logic for what gets deleted (drawAction marked me). Instead, I modified all deleteActions that pop up dialogs to not show these dialogs if "simulate" is set to true. This way, almost the same function can be used for the actual deletion as well as updating the cursor. "Almost" because it's not easily possible to decide between way_node_only and way_normal from the result. Both contain a way + node(s).

From my experience with drawAction, I guess this will probably need some baking, too. So please don't create a new stable too soon :).

xeen
PS: cakes welcome ;)

The patch.

the renamed icons. Unzip them to /JOSM/images/cursor/modifier.

nice :-)

applied in r2026

there seems to be an error, not all icons have been used (e.g. the ones with the red elements don't seem to be there). E.g. when you shift-delete a segment (delete_l.png) there has to be a different icon as when you ctrl-delete (all segments but leave the points, delete_way.png).

There is also an issue on ubuntu: the alt-key is not working, but instead alt-gr is working, but the icon doesn't change for alt-gr.

Please verify the patch.

The patch is fine. The "red icons" do get used but for some reason the red in them is not decoded properly.

ALT key works for me on Debian. ALT GR has no special purpose but icons work never the less. Only on key down or key up the "delete way only" icon is shown although ALT GR behaves like "delete way normal". The ALT-problem should be persistent everywhere in JOSM though, the patch didn't touch that code. Except for the additional events in case of ctrl/alt/shift/… press the same code is used.

Please provide the following (you can use xev):

• the output when you press, hold and release the ALT button
• same for the ALT GR button

Be careful to select the "right blocks" because a new event is produced for every mouse move. Probably use something like {{{xev > bug2163.txt}} so the interesting events aren't pushed out of the scrollback.

I've got no idea why the icons don't show up correctly though. They do for gthumb. JOSM's png decoder seems to be pretty broken…

Replying to xeen:

The patch is fine. The "red icons" do get used but for some reason the red in them is not decoded properly.

strange. Is there anything I can do about? I also noted that one icon (delete point) has a small white dot (1 px) in the upper right corner. I checked the original icon and it is not there. Do you know, where this comes from?

ALT key works for me on Debian. ALT GR has no special purpose but icons work never the less. Only on key down or key up the "delete way only" icon is shown although ALT GR behaves like "delete way normal". The ALT-problem should be persistent everywhere in JOSM though, the patch didn't touch that code. Except for the additional events in case of ctrl/alt/shift/… press the same code is used.

Please provide the following (you can use xev):

• the output when you press, hold and release the ALT button

ALT does change the icon, but unsurprisingly is not working on ALT-click as this is the predefined action to move windows on my system. It is not a bug here.

• same for the ALT GR button

This behaves strange. It does not change the icon on hold, but when you start to move the mouse on hold it is changing. The ALTGR+click does exactly what I expect (like ALT), but the icon is strange: it also changes the icon on ALT-press and then release, and until you then move the mouse (after release) it keeps displaying the ALT-Icon. The function (kind of delete) does in the case of ALT GR not (or just coincidentally) relate to the displayed icon (if the icon displays delete just ways and you click and don't hit ALT GR, it will still delete the nodes as well).

Be careful to select the "right blocks" because a new event is produced for every mouse move. Probably use something like {{{xev > bug2163.txt}} so the interesting events aren't pushed out of the scrollback.

actually I'm sorry that I don't understand this xev-Stuff :(

I've got no idea why the icons don't show up correctly though. They do for gthumb. JOSM's png decoder seems to be pretty broken…

:( maybe this is worth another bug?

The patch is fine. The "red icons" do get used but for some reason the red in them is not decoded properly.

strange. Is there anything I can do about?

There seems to be some problem with Java + Linux + colored Cursors.
Google spit this out: ​http://en.allexperts.com/q/Java-1046/2008/7/Custom-Java-cursor-Linux.htm

I also noted that one icon (delete point) has a small white dot (1 px) in the upper right corner. I checked the original icon and it is not there. Do you know, where this comes from?

Yes, it is. You have to look closer. :)
Attached the corrected image.

ALT key works for me on Debian. ALT GR has no special purpose but icons work never the less. Only on key down or key up the "delete way only" icon is shown although ALT GR behaves like "delete way normal". The ALT-problem should be persistent everywhere in JOSM though, the patch didn't touch that code. Except for the additional events in case of ctrl/alt/shift/… press the same code is used.

Cannot reproduce. ALT GR works the same way ALT should work.

This behaves strange. It does not change the icon on hold, but when you start to move the mouse on hold it is changing. The ALTGR+click does exactly what I expect (like ALT), but the icon is strange: it also changes the icon on ALT-press and then release, and until you then move the mouse (after release) it keeps displaying the ALT-Icon. The function (kind of delete) does in the case of ALT GR not (or just coincidentally) relate to the displayed icon (if the icon displays delete just ways and you click and don't hit ALT GR, it will still delete the nodes as well).

It's perfectly normal on my machine. Are you aware the curser changes, when hovered above a Node / Way?

Be careful to select the "right blocks" because a new event is produced for every mouse move. Probably use something like {{{xev > bug2163.txt}} so the interesting events aren't pushed out of the scrollback.

actually I'm sorry that I don't understand this xev-Stuff :(

Not necessary - there is no bug as ALT click is reserved on Ubuntu.

please put in cursor/modifier/

This thread seems to offer a solution: ​http://forums.sun.com/thread.jspa?threadID=5312876.
Either we use this method or set different 2 color-cursors under Linux.

I’ve looked into this more closely and believe we should “wontfix” this bug. Java’s XToolkit implementation uses xcreatepixmapcursor internally, which only supports setting a fore- and background color. As far as I can tell the xcursor extensions support setting cursors in ARGB format, which would allow a lot of colors as well as alpha transparency. However, it is not implemented. Therefore we would have to patch the JVM or ship our own xcursor implementation/bindings to gain hardware support. I’ve opened a feature request for just that(1).

The thread linked above is 404 by now, but the “solution” likely was to hide the cursor using a transparent image and instead paint it onto a glass pane yourself. This works, but the cursor will be rendered less often if the content behind the glass pane takes longer to paint. This is very similar to the way the helper line works, if it lags for you now, so will the cursor. I haven’t tested exactly, but my system would be fast enough if target highlighting is deactivated. The small delay caused by the highlights is already enough to make the cursor feel sluggish. For slower systems it might lag behind regardless if highlighting is on or off.

Thus it would not be possible to turn on the “colored cursor hack” for X systems by default, making this a niche solution. Plus, the workaround is ugly.

If anyone wants to try, I’ve attached a hacked GlassPaneDemo that has this implemented. The larger the window, the more buttons to draw, the laggier the cursor. JOSM’s map drawing works a little bit different, so it’s not exactly comparable, but it’s enough to get an idea.

Long story short: waiting for upstream to fix this is probably the best solution. If anyone objects, please reopen the bug.

(1) ​http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158547 (404 as of writing, but the mail said it should be online in a few days)