[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #16 from Heiko Tietze --- The topic was on the agenda at the design meeting but did not receive further input. It's easy to switch into the edit mode, in edit mode you cannot go to another cell, and the idea has flaws regarding multiple cells. The workflow not not overwrite content is not the common one, and would be a fact for multiple cells anyway. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 Roman Kuznetsov <79045_79...@mail.ru> changed: What|Removed |Added CC||79045_79...@mail.ru --- Comment #15 from Roman Kuznetsov <79045_79...@mail.ru> --- I disagree with this proposal. If you want to be in edit mode just double click on needed cell before pasting. It works so in any spreadsheet software and we shouldn't change this behaviour -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 Heiko Tietze changed: What|Removed |Added Severity|normal |enhancement --- Comment #14 from Heiko Tietze --- (In reply to Jim Avera from comment #12) > I'm not sure I understand this question. We have to balance your workflow with how the average user deals with the program. I believe there are as many scenarios where "overwriting" is desired. And the other questions were kind of rhetorical to illustrate potential inconsistencies. But anyway, we will discuss the proposal in the design meeting. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 QA Administrators changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 --- Comment #13 from QA Administrators --- [Automated Action] NeedInfo-To-Unconfirmed -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 --- Comment #12 from Jim Avera --- > [pasting] multiple-cells content, eg. "123"? Doesn't the same thing happen if you type those 5 keystrokes instead of pasting them, i.e. a tab advances to the next cell? If not, what is the desired difference in behavior (between pasting multiple cells and typing 12 etc.)? > What if the clipboard contains an image? What should happen, for the best user experience? Current behavior is anomalous: If you click once in a cell and paste an image, the image overlays any text in the cell, but the image is anchored *to the page* not to the cell so the image will move to cover random other cell(s) when row heights change; If you double-click to enter edit mode, then LO refuses to paste an image (Ctl-V does nothing). My first thought is that images should by default be treated like characters, so mixing characters and images can be done usefully: If in edit mode, then Ctl-V with an image in the cb would paste the image and anchor it to the preceding character, offset horizontally to start just after that character; if there is no preceding character then anchor to the cell at the upper-left corner. I don't understand why anchoring to the page is ever useful, but a user could always change the "Anchor" property after pasting if they wanted that. > What scenario makes it necessary to modify the pasted content (thinking of > the opposite where users definitely do not want to change the pasted data but > have to press escape to leave the edit mode)? I'm not sure I understand this question. I'm saying LO should *not* modify the pasted content (currently it does -- it *deletes* pasted content when something else is input). If a user pastes and then types backspace, then yes the pasted content should be modified; but in that case the user explicitly initiated the modification. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO --- Comment #11 from Heiko Tietze --- What do you expect to happen for multiple-cells content, eg. "123"? And what, if the clipboard contains an image? What scenario makes it necessary to modify the pasted content (thinking of the opposite where users definitely do not want to change the pasted data but have to press escape to leave the edit mode)? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 154781] Pasting into a cell should make it change to edit mode
https://bugs.documentfoundation.org/show_bug.cgi?id=154781 Buovjaga changed: What|Removed |Added Keywords||needsUXEval CC||libreoffice-ux-advise@lists ||.freedesktop.org Summary|Keyboard input un-does |Pasting into a cell should |paste (if cell was |make it change to edit mode |previously empty) | --- Comment #10 from Buovjaga --- A very controversial proposal, alerting UX team -- You are receiving this mail because: You are the assignee for the bug.
