It is very hard to select a line in front of an image. The cursor changes to the "grab hand" as soon as it moves over the picture. It is not really clear where the "active point" of this cursor is and the cursor does not change when it moves over a line.
Steps to Reproduce:
1. Insert an image into Impress.
2. Draw a line in front of the image.
3. Click outside the image to deselect everything.
4. Try to select the line.
The cursor is the "grab hand" when over the image. There is no clear indication that the cursor is above the line. It is also not clear where the "active point" of the "grab hand" cursor is.
Either change the cursor to signal that it is over the line.
Or highlight the object under the cursor.
Or give an indication of the "active point" of the "grab hand" cursor.
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
There was a complaint about this before, but it was not kept open. I have a method to make selection precise in a comment: https://bugs.documentfoundation.org/show_bug.cgi?id=95841#c4
As this keeps coming up, let's ask UX. Does the hit area of lines need to be increased? Or any other improvements you can think of?
One thing that popped to my mind is pre-selection highlighting: the line would light up in a different color/shade, when the mouse is over the hit area.
Thank you for the link to the previous report. I missed that one!
The workaround is really a bit clumsy. And if you forgot to name the element it, you run into very same problem.
I can think of two possible improvements:
1. Make the pick cursor the arrow and not the grab hand. Change the cursor to the grab hand only if the main mouse button is clicked to show that the object can be moved now.
2. Highlight the object under the cursor.
I believe that option 2 is the better one. It also follows current practice in CAD programs. Maybe it's also possible to combine 1 and 2?
I wouldn't increase the hotspot area, at least not in general. Perhaps it could be adjusted according the zoom factor, if it isn't yet. Issues with object selection are known and the proposed solution is to have a simple alternative with the navigator: https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/
(In reply to Heiko Tietze from comment #3)
> I wouldn't increase the hotspot area, at least not in general. Perhaps it
> could be adjusted according the zoom factor, if it isn't yet. Issues with
> object selection are known and the proposed solution is to have a simple
> alternative with the navigator:
So what is your view on pre-selection highlighting that me and the original reporter proposed? I'm sure there are some extremely complex cases, where the navigator is invaluable, but I guess most of the time a hands-on visual hint would be the best.
(In reply to Buovjaga from comment #4)
> So what is your view on pre-selection highlighting that me and the original
> reporter proposed? I'm sure there are some extremely complex cases, where
> the navigator is invaluable, but I guess most of the time a hands-on visual
> hint would be the best.
You mean the line color turns into red or a fancy glow effect appears around it? And what happens in case of a red line or when the object is shining by default? Hard to imagine that we find a general solution for all objects and all drawings that is better than turning the cursor from pointer into the grab hand.
(In reply to Heiko Tietze from comment #5)
> You mean the line color turns into red or a fancy glow effect appears around
> it? And what happens in case of a red line or when the object is shining by
> default? Hard to imagine that we find a general solution for all objects and
> all drawings that is better than turning the cursor from pointer into the
> grab hand.
Everything is possible. The shading or glow color can be made relative. This is ancient technology to all 3D artists.
No further input on this ticket. The original issue of picking a line in front of an image being hard because cursor doesn't change from default to grab has a workaround with the Navigator. Don't think we can come up with an innovative solution (highlighting the hovered object). And in the end, I don't see too much interest in this topic anyway.
Reverting status change.
A video example of what preselection highlighting in 3D software looks like: https://www.youtube.com/watch?v=OmfyRi7yx1w (Blender)
Thanks for sharing the video. But I still think it's not a needed feature as a) typically objects are not stacked like on 3D scenes or lines over images, b) most users have not so many objects on the canvas (see also https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-part-2-how-libreoffice-draw-is-expected-to-evolve/) and c) we provide selection per Navigator (and should invest effort there).
But in case someone wants to implement it, I could imagine a temporary frame around the object similar to when it is selected, maybe in a slightly different color. Same happens for selections in lists, trees etc. eg. the Gallery.
I still believe, that there should be a visible clue to show the element under the cursor. Nearly every program dealing with (vector) graphics does it. Personally, I don't have any preference how the element-to-be-selected is highlighted.
The alternative is to have a cursor where it's clear, where the "active" spot is. IMHO the hand cursor used is notoriously bad in this regard.
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I can confirm, that this bug is still present on:
Build ID: 1:6.3.2-0ubuntu0.18.04.1~lo1