Description: Inside the Notes View: Mouse cursor changes to the 4-arrowed "move element cursor" ... - even though the mouse is placed within the text element. - even though the focus (current cursor) is *inside* the text. Steps to Reproduce: This might be an Enhancement request. I can't judge at the moment. 1. Open Notes View ( Menu -> View -> Notes ) 2. Write some random notes. E.g. Hello hello abcdefghijklmnopqrstu aaaa bbbb cccc dddd 3. Click with the mouse at about "kl" 4. Move the mouse a little down to the next row ("aaaa"), but don't move it left. Actual Results: Cursor changes to "four direction arrow" for moving the notes element. Expected Results: Cursors stays the "pipe cursor" for editing text. ( This cursor "problem" actually also happens, when the mouse is on the rather right side of the notes element. ) Reproducible: Always User Profile Reset: Yes Additional Info:
I think it isn't a bug. All notes area is a shape. And if you move mouse point into center of notes then you can always see "4 arrow" cursor for moving of shape. When you move mouse point between text rows you get on empty space of shape and you see the same "4 arrow" cursor.
(In reply to Roman Kuznetsov from comment #1) > I think it isn't a bug. > All notes area is a shape. > And if you move mouse point into center of notes then you can always see "4 > arrow" cursor for moving of shape. If I understand you correctly, you're saying: "because it is implemented as a shape, it should be as it is now"? If the current implementation for a shape is as it should be, maybe the implementation for notes as "shape" should be reconsidered(?) I'd like to hear some other opinions on this topic, so I set it back to "unconfirmed". > When you move mouse point between text rows you get on empty space of shape > and you see the same "4 arrow" cursor. Sorry, I didn't understand this sentence. Could you explain more?
I think this is a balancing act. The user should be able to select the text box conveniently even though every line has text. I would expect us to close this as WONTFIX. Currently there is a "buffer" after the end of a paragraph, where the mouse cursor does appear as "edit text". So if you move the mouse below "abc" in "Hello hello abcdefghijklmnopqrstu" and to the left, the cursor will change. Let's swing this by the design team.
The cursor changes to a pointer when outside the (note) shapes and to the "i-beam" when at the text area (only in this case you can directly switch to editing per single click otherwise you need to double click the shape). So the problem boils down to how we detect a text area under the cursor. This is a technical limitation not really a bug but admittedly unexpected as the shape is seen as a text box. Unfortunately it's not solvable - and in other situations the expected behavior.
An idea to reduce this problem: - mouse-up within the text area => go to text edit mode - mouse-down and hold within textbox area (, perhaps move cursor around) => select text box and drag around (no edit mode) - ctrl + mouse-up within textbox area => select text box (multiselect, if others were selected before) - mouse-down / up on border of text box => select text box If you're willing to think about it, I could provide a simple html example of that behaviour for UI experience testing.
(In reply to BottleOnTheGround from comment #5) > An idea to reduce this problem... Websites are not desktop applications and this change would feel like moving from Windows or Linux to macOS. You learned interactions respective single/double click are completely different.
(In reply to Heiko Tietze from comment #6) > (In reply to BottleOnTheGround from comment #5) > > An idea to reduce this problem... > > Websites are not desktop applications and this change would feel like moving > from Windows or Linux to macOS. I'm not sure what you are trying to say in regard of websites. If it regards to my "html offer": That was just for having a UI prototype to see, if it "feels" right. In which regard would the behaviour change I suggested feel like macOS? As I see it, there is no change in standard behaviour (you select what you click), but only a change in advanced behaviour (shortcuts) (?) > You learned interactions respective single/double click are completely different. Could you explain this again?
Created attachment 156604 [details] Attachment shows the grabable area when in edit mode
Created attachment 156624 [details] Example implementation for handling textboxes
Created attachment 156625 [details] Video showing the features of the example impl
This topic has now a lot facets: 1. How to get into move vs. edit mode (indicated per cursor) * Current situation: click on the frame selects the objects for moving, click the text to get into the edit mode; for objects without text you can enter text per double-click * Proposal: click and move = drag, single click w/o moving = edit (double-click selects the text); clicking the frame allows to move while in edit mode => Your proposal surely works but I don't see much benefit (mostly because the issue is not clear in terms of "I want to move a notes object but always get into the edit mode accidentally", or "I use to stack objects and struggle to move them around", both should be covered). An alternative solution could be to always move per ctrl+click. 2. What area is treated as the object * Current situation: respects the z-order and what's on top is the target (you can click through the stack per alt+click; for the "hidden gems of Draw" (same applies to Impress) see https://www.youtube.com/watch?v=QuQSZSCOtAY) * Proposal: ignore transparent areas => Again, the issue is not clear. It sounds like considerable effort for not much benefit. 3. Adjust the cursor according the actual action (of course) 4. Replace shapes (text boxes) in Impress by fix areas for text Putting all together I believe we have some though not perfect but working means to deal with edit/mode mode. Resources are scarce and that's why I suggest to not put more effort in this. We are a community project and you can reopen the ticket if you disagree. I will not close it again but remove the UX flags as input has been given. If you are able to code and want to implement the idea we will look for the red carpet.
A short summary of this report: - "RESOLVED WONTFIX" does not mean "thrown away" - Currently there is a working solution (it might not be perfect) - If someone is willing to work out a nice rounded-up concept, he/she is welcome. - If someone is willing to implement a/the nice concept, he/she is welcome. - In case something new is concepted/implemented, it's important to think of the overall image and corner cases.