Calc mimics the behavior of MS Excel: start typing into a cell, and you get into 'Enter' mode (enter/tab/cursor keys commit and step to an other cell), and F2 activates 'Edit' mode (only enter/tab commit changes). However, Excel shows the current state in the status bar, whereas Calc doesn't. This is highly confusing. UI: this whole Enter/Edit distinction seems totally wrong to me, but it's worth keeping for compatibility with Excel.
confirmed. enhancement request. inherited from OOo. how exactly Excel gives such a visual clue? could you provide a screenshot or description?
In excel the cell mode is shown in the bottom left corner (on the statusbar). See http://office.microsoft.com/en-au/excel-help/excel-status-bar-options-HA010222505.aspx
Any update on this? I think this is a major usability problem in Calc.
*** Bug 116447 has been marked as a duplicate of this bug. ***
Adding needsUXEval to discuss the possible implementation(s) within the design/UX team.
Don't see the use case when this status bar information would be needed.
(In reply to almos from comment #2) > In excel the cell mode is shown in the bottom left corner (on the > statusbar). See > http://office.microsoft.com/en-au/excel-help/excel-status-bar-options- > HA010222505.aspx A selected cell has a clear border indication. A cell in editing mode, does not have that. So how clear do you want to show the difference :) For me changing is not adding relevant user feedback. A WFM, I would say.
We discussed this topic in the design meeting. While "Edit"/"Enter" resp. F2/"just type" makes arrow effective or not, and the "Point" information shown in formula edit mode, are different modes, it's quite clear what action you started. Plus, it's barely usable to require a glimpse at the statusbar. And since we also have quite a lot information in the statusbar, we decided to not implement the feature.
Here is a request that the UX Team please consider my points on why this is actually a valuable feature. For the sake of clarity, let's call the mode where arrow keys move the cell cursor "cell-cursor mode" and the mode where arrow keys permit navigation within the edited text "text-cursor mode". Let's say that they're both cursor modes. Let's call the cell whose formula you're editing "formula cell". These cursor modes are relevant when you are editing the formula of a particular cell. While cell-cursor mode is the default when you start entering a formula into a cell by pressing "=" and is very useful for referencing nearby cells by navigating towards them with the arrow keys, text-cursor mode is necessary for modifying previously entered parts of your formula. Even if you never make mistakes when entering your formulae, you might need text-cursor mode to make modifications to formulae if you want to use them for a slightly different purpose elsewhere. Now, if while entering the formula in a cell, you happen to switch back-and-forth between text-cursor and cell-cursor modes several times, it is not impossible that you'll forget which mode you're on. This is where a visual indication of what mode you're in would be useful. Having it is not _essential_, but certainly can improve the user experience: if you think you're in text-cursor mode and press an arrow key, but you're really in cell-cursor mode, you will insert at least 3 characters (the address of the cell which your cell-cursor presently points at) in the formula cell which you will have to delete. Having a visual indication can prevent this, arguably without negatively impacting user experience. Now, I don't think MS Excel's approach is actually that useful: in the past I've preferred winging it and possibly deleting some characters than looking at the status bar to see which mode I'm in. (I've criticised in the past when people have argued that a feature shall not be implemented in LO simply because MS Excel doesn't have it.) I think some not terrible ways to implement this cursor mode visual indicator would be: * Changing the cursor in the cell formula between a line and a block, where a block cursor indicates you're in cell-cursor mode. * Adding a border to the formula cell, albeit one styled differently than the cell-cursor border. For example, the formula cell border during cell-cursor mode could have a dashed stroke. * Changing the background color of the formula cell slightly according to the cursor mode. * Adding arrow icons in all four directions of the cell under the cell-cursor while on cell-cursor mode; removing these icons while in text-cursor mode. Anyway, these are just some ideas. I'm sure the UX team can come up with something better. Sorry for the long comment.
(In reply to Severo Raz from comment #9) > Now, if while entering the formula in a cell, you happen to switch > back-and-forth between text-cursor and cell-cursor modes several times, it > is not impossible that you'll forget which mode you're on. Not a big deal, and you likely never look at the statusbar or other peripheral places when editing a formula. But admitted, it happens that you press the arrow accidentally. > * Changing the cursor in the cell formula between a line and a block, where > a block cursor indicates you're in cell-cursor mode. We change the cursor in edit mode from Default to IBeam but only when over the cell. And leaving the edit mode does not immediately update the cursor. That could be improved. > * Adding a border to the formula cell, albeit one styled differently than > the cell-cursor border. For example, the formula cell border during > cell-cursor mode could have a dashed stroke. Don't think we should mess with decorations because the cell might be user-formatted. And any format is prone to fail for not being accessible or not fitting into the personal preferences. > * Changing the background color of the formula cell slightly according to > the cursor mode. Same as above but less strict. > * Adding arrow icons in all four directions of the cell under the > cell-cursor while on cell-cursor mode; removing these icons while in > text-cursor mode. Sounds like over-engineering to me.
I think that it comes down to personal preferences and habits. I often switch repeatedly between editing mode and entering mode when editing longer formulas. Therefore, I would find a clear status indicator very useful. I often look at that indicator when working with Excel. I miss such an indicator when working with LibreOffice Calc.
We discussed the topic again in the design meeting and welcome your idea to change changing the background color when in edit mode. This should be an option for Tools > Options > Application Colors where default is None meaning the current behavior. But the user can change it to any color and have this as background then when in edit mode. Another outcome is to have the cursor updated immediately. Better another ticket.
*** Bug 160312 has been marked as a duplicate of this bug. ***
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1cfc2e2c92e1259341ee18cf87be63c4dcebd33d tdf#63374 Change cell background color when in edit mode It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Find "[ ] Edit cell background highlighting" under tools > options > calc > view. It will toggle the cell background to the color defined under tools > options > application colors > Spreadsheet: Cell Focus (but only for single selections). All kudos to Sahil for the patch!
@heik(In reply to Commit Notification from comment #14) > Sahil Gautam committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 1cfc2e2c92e1259341ee18cf87be63c4dcebd33d > > tdf#63374 Change cell background color when in edit mode > > It will be available in 24.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Possibly, I misunderstand the essence of the fix. I was under impression that the idea was to provide a visual guide (background) to differentiate between the «Edit» mode and the «Quick-entering» mode (the one where user does not hit F2 first; no idea what is the official term for it) at any given moment while typing. As it is now the cell background turns blue in any case, no matter whether F2 had been pressed before the typing commenced. Either I am missing something, if so, I am sorry, or the issue can't be counted as resolved. I tested it on this version: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9ad0eb9a62b572b15ae0bfd31674aedd77eb4761 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: CL threaded
(In reply to Sergey Nemna from comment #16) > As it is now the cell background turns blue in any case, no matter whether > F2 had been pressed before the typing commenced. I confirm that. The original request here and in duplicates was to have a visual indication that Cell Edit Mode is active(i.e. activated by F2, or double-click, or Edit > Cell Edit Mode), to differentiate from "quick edit/overwrite mode" (in which an arrow press exits the cell). Sahil, can you make it so the highlight is only active when Edit Mode is on?
(In reply to Sergey Nemna from comment #16) > to differentiate between the «Edit» mode and the «Quick-entering» mode There is different edit mode, you either overtype the content with what you call quick entering or go into the same edit mode by keeping the content, aka F2. The patch just (optionally) highlights the cell when in edit mode. => fixed
(In reply to Heiko Tietze from comment #18) > (In reply to Sergey Nemna from comment #16) > > to differentiate between the «Edit» mode and the «Quick-entering» mode > There is different edit mode, you either overtype the content with what you > call quick entering or go into the same edit mode by keeping the content, > aka F2. > > The patch just (optionally) highlights the cell when in edit mode. => fixed I am not sure I understand. Is this patch about highlighting the cell where user is currently typing in? If so, it seems the aim has been reached (not sure why blinking cursor is not enough, but this extra functionality certainly does not hurt anyone). But is there any possibility to have this blue (configurable) background applied when in the edit (F2) mode only? It would provide visual guidance, so the user would know which mode he works in. I thought the issue was all about this...
(In reply to Heiko Tietze from comment #18) > The patch just (optionally) highlights the cell when in edit mode. => fixed I checked with gtk3, kf5 and gen VCL plugins: it highlight both in Cell Edit Mode _and_ in "quick entering" mode. OPs request was to differentiate between the two, which is not the case here.
(In reply to Stéphane Guillou (stragu) from comment #17) > (In reply to Sergey Nemna from comment #16) > can you make it so the highlight is only active when Edit Mode is on? So show the "Edit highlight" only when cell enters edit mode via F2 press?
(In reply to Printf Debugging from comment #21) > (In reply to Stéphane Guillou (stragu) from comment #17) > > (In reply to Sergey Nemna from comment #16) > > can you make it so the highlight is only active when Edit Mode is on? > > So show the "Edit highlight" only when cell enters edit mode via F2 press? Yes (or via double-click, or via Edit > Cell Edit Mode – but I assume the path does not matter in the implementation?). That would be what OP here, and in bug 116447 and bug 160312, were asking: being able to easily, visually differentiate between Edit Mode and "quick edit/overwrite".
Yes, I get it now. So we want a way to know when the arrow keys move the caret "|" ("🥕" --> " 🥕") and when they move the cell focus i.e. committing the changes we made. And the highlighting means that the 🥕 will move instead of the box.
Printf Debugging committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3eb427b31e624af9b2fe2bd68fee859d3d76a661 Resolves tdf#63374 and tdf#160908 It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 194112 [details] Enlarged active cell rectangle
The fix does work as expected. Thank you very much! However, it may have had unintended consequences. The rectangle designating the active cell is now somewhat larger than the cell itself (please, see the scree-shot). Tested on: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 47664e282da4999b8e471a6a916d7ec80414ac18 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19044); UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: CL threaded
(In reply to Sergey Nemna from comment #26) > The fix does work as expected. Thank you very much! > > However, it may have had unintended consequences. That is not an unintended consequence. See tdf#143733. It is a fix for separate enhancement request.
(In reply to Printf Debugging from comment #27) > (In reply to Sergey Nemna from comment #26) > > The fix does work as expected. Thank you very much! > > > > However, it may have had unintended consequences. > That is not an unintended consequence. See tdf#143733. It is a > fix for separate enhancement request. I see, my bad. Thank you again for the good work.
I have noticed that the editing mode highlighting can't be seen in case a style with background is applied to the cell. Logically, it would be desirable to have such cells highlighted while being edited as well.
Yes, that is because it might look ugly to show a blue shaded edit cell, which might be a part of some bigger colored region. Same with the highlighting. But if it hinders the UX, then ... @Heiko what do you say?
Highlighting ==> Selection Highlighting
(In reply to Printf Debugging from comment #30) > @Heiko what do you say? Edge case, not worth effort. And there is prolly no ultimate solution anyway, thinking of hatched with cell background and highlight color for 99% of the scenarios.
Thanks Sahil! In release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F24.8&type=revision&diff=752779&oldid=752778 Verified in: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1f15d097cace14ca6e44e7652f460aa3fa7bd150 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded