<image> context menu item 'Edit externally…' ignores current selection

[su_v]

Using the context menu entry to externally edit a linked bitmap image ignores the current selection and always edits the bottom-most linked image under the current cursor position.

Steps to reproduce:
1) open new document
2) import 2 bitmap images (link)
3) arrange them to partially overlap
4) select the one on top
5) position the cursor inside the region where the two images overlap
6) use context menu 'Edit externally…' to open the linked image in an external bitmap editor

Expected result:
The currently selected linked bitmap image is opened in the external bitmap editor

Actual result:
The bottom-most image with a non-transparent region at the current cursor position is opened in the external bitmap editor.

Reproduced with Inkscape 0.48.x and current trunk on Mac OS X 10.5.8 and OS X 10.7.2.

[su_v (suv-lp)]

Shell script used to verify the path/file name passed to the external editor attached (Preferences > Bitmaps > Bitmap Editor).

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 11098.

Similar issues with Create Link and Remove Link menu items (and maybe others).

[jazzynico (jazzynico)]

Inconsistent with the behavior of Set/Release Mask/Clip in the context menu (they use the selected objects).

[jazzynico (jazzynico)]

First patch, yet to improve a bit. Now edit the selected image. If no image is selected, select the one sent to the context menu (unfortunately the bottom one on the canvas) and edit it.
Work in progress.

[jazzynico (jazzynico)]

The remaining issue seems to be unrelated to a specific menu entry. Looks like the right click always returns the bottom item on the canvas.

[jazzynico (jazzynico)]

Patch v0 doesn't work with more than one object selected...

[Kris (kris-degussem)]

Just wanted to add that I am working on rewriting the context menu code for something unrelated (Bug #910529). This, just to make sure that when you intend to significantly modify the context-menu.cpp code no work would be lost...

[jazzynico (jazzynico)]

A better patch, with multi-selection support.

The right button on unselected items issue is out of the scope of that report IMHO, and affects other menu entries too. I'd like to close the report as soon as it's confirmed fixed, and open a new one for the remaining issues.

[jazzynico (jazzynico)]

@Kris - Do you prefer me to wait before committing the patch? That's not a huge modification, and I hope it won't interfere with your current work.
BTW, I tend to write patches with the same coding style as the rest of the file. It could be worth reviewing the patch so that it's consistent with your changes.

[Kris (kris-degussem)]

@jazzynico: no I do not want you to wait for committing. This indeed is a minor modification. When reading comment 5 I did not know whether this would require major modifications to the context-menu code, hence my reaction. ;-)

[jazzynico (jazzynico)]

Committed in the trunk, revision 11115.

While it's always possible to prevent the command from launching (or remove the menu entry) when no object is selected, I finally think it would be better to fix the automatic selection.

[su_v (suv-lp)]

> I'd like to close the report as soon as it's confirmed fixed,
> and open a new one for the remaining issues.
(…)
> status: In Progress → Fix Committed

While the patch addressed a specific use case (linked bitmap images stacked on top of each other), it's still not possible to edit a selected linked bitmap image externally if it is stacked on top of any other object type (the current selection is ignored -> the context menu entry to 'Edit externally…' never turns active and there is no alternative way to call the command).

Do we already have a more general report discussing the scope of the context menu?

[su_v (suv-lp)]

> Looks like the right click always returns the bottom item on the canvas.

AFAICT based on tests with archived builds, this is a regression in current trunk - introduced between r10577 (acts on top-most or selected) and r10581 (ignores selection and acts on bottom-most) - possibly with the merge of the rendering cache branch (GSoC 2011) in r10579. Needs verification.

[su_v (suv-lp)]

Follow-up report filed as
Bug #979567 "Object context menu (right-click) acts on bottom-most instead of top-most object under cursor position"