'Object Attributes' dialog for hovered images and links does not update as expected

[su_v]

UI inconsistency in current trunk when using context menu entries of hovered objects (object under the current mouse pointer position, not actually selected):
- context menu entries like 'Fill & Stroke', 'Text and Font', 'Object Properties' select the object under the current pointer position, and display the object's data in the opened dialog
- context menu entries like 'Image Properties' and 'Link Properties' open the 'Object Attributes' dialog, but do not automatically select the object under the current mouse pointer position. The data in the dialog is either empty (dialog may initialise with zero width/height) or shows the values of the previous selection (but insensitive).

In current stable 0.48.x - with the old floating dialogs for object attributes - the hovered object isn't selected either, but the menu entry each time opens a new dialog window which displays the data of the hovered object.

Solution for current trunk could be
a) make the dockable 'Object Attributes' dialog behave like 'Object Properties' (select hovered object and update data in dialog)
or
b) keep 'Object Attributes' as special case: update only the data in 'Object Attributes' without actually selecting the object

[su_v (suv-lp)]

Sample SVG file used for tests to compare stable and current trunk r11674 (after the fix for bug #979567).

[Kris (kris-degussem)]

Dialog entries are never updated when hovering over the object, do they?
All dialogs show expected and similar behaviour, except for the object properties dialog that changes object selection when:
- second object is not selected
- you richt-click on the second object and choose the menu option "Object properties"
Not updating is expected, because if it would be updated how do you know to which object the data shown corresponds (if selection is not changed)?

(Vista 64 bit, r11675)

[su_v (suv-lp)]

> Dialog entries are never updated when hovering over the object, do they?

Not when hovering an object (I didn't state it does so, nor claim it should).

1) The content of the context menu is sensitive to what is beneath the current cursor position (and not to the current selection).
2) One can open 'Fill and Stroke' for an object underneath the current cursor position, or 'Text and Font' for a text under the current cursor position, or 'Object Properties' for any object without selecting the object first (click with LMB) before opening the context menu (click with RMB). Each of these actions then automatically selects the object beneath the current cursor position and displays the data of the now selected object in corresponding dialog.
3) Context menu entries which call (or reuse) the 'Object Attributes' dialog (for example for links and bitmap images) behave differently (aka inconsistent compared to other context menu entries) as in that no object selection occurs, and the 'Object Attributes' dialog either opens empty (no width/height), or keeps the data of the last selected object which was displayed in the dialog.

[su_v (suv-lp)]

Overall, the scope of the context menu entries is somewhat confusing - the entries in the context menu seem to vary depending on the object underneath the current cursor position (and not depending on the current selection), but the data then displayed in the called dialog apparently depends on whether a current selection (e.g. a different object elsewhere on canvas) exists (dialog shows content for prior selected object) or not (the object beneath the current pointer position is selected, and its data displayed in the corresponding dialog).

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 12836.