| Summary: | EDITING: Copying cells in Calc doesn't show marching ants animation, neither in default configuration nor regardless of the expert option "AnimationsEnabled", unless the OS’s "Show animations" setting is switched on. | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Per99 <solare99> |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | heiko.tietze, m.weghorn, stephane.guillou, telesto, vsfoote |
| Priority: | medium | Keywords: | accessibility |
| Version: | 24.2.0.0 alpha0+ | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=161748 https://bugs.documentfoundation.org/show_bug.cgi?id=155414 https://bugs.documentfoundation.org/show_bug.cgi?id=115688 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
*** Bug 161748 has been marked as a duplicate of this bug. *** @Michael, Could you please take a look at this? Basically, the issue is related to how Calc deals with OS's settings regarding accessibility (replaces tdf#161748). (In reply to ady from comment #2) @ady, could you please confirm the bug and put the status accordingly? (In reply to Per99 from comment #3) > @ady, could you please confirm the bug and put the status accordingly? I'd like to hear from Micheal first, or at least someone from the QA Team. As it is now, it might be considered a bug, or instead a change/enhancement, or... As I mentioned in tdf#161748, I agree that LO/Calc should rather prevail over whichever (accessibility) setting comes from the OS. Every time that the OS has imposed its settings on LO/Calc, my UX has been impacted negatively. I am hoping this tendency could be reverted, starting with this report. Believe this is intentional to allow os/DE to assert its a11y settings controlling "reduce motion". As implemented for bug 155414 by Patrick L. did for macOS [1] and a Michael W. for other os/DE [2]. IMHO => NAB =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/154752 //macOS [2] https://gerrit.libreoffice.org/c/core/+/154887 //gtk3 https://gerrit.libreoffice.org/c/core/+/154888 //kde https://gerrit.libreoffice.org/c/core/+/154889 //win While request of bug 115688 for a checkbox control in UI (Tools -> Options -> Accessibility) for LO to configure the AT is still valid, but less needed since we are honoring os/DE AT config now cross platform at 24.2 A I mentioned in tdf#161748, taking the OS's setting as default for each installation makes sense, but users should be able to set the animation settings in LO/Calc according to their needs. The OS's settings either allow or block _all_ animations. Some animations are more about "fancy" things (usually making the system relatively slower), but other animations are desired for accessibility reasons (e.g. marching ants). So many users (myself included) would like to reduce the "fancy" stuff but allow the accessibility-related items. Taking the OS's settings as base is OK. Not allowing the accessibility items, especially on systems that already need every cycle in order to help real accessibility needs (and reducing the load caused by "fancy" items) is counterproductive. This is just an example. My point is, allow LO's settings that used to be relevant, instead of making the OS's settings an "all-or-nothing" condition. It is interesting that there is a valid case both FOR marching ants being on for accessibility and also OFF for accessibility, depending on your personal accessibility problem. I hadn't thought of that. I echo @ady 's sentiment that having LO honor the OS setting as the default makes sense, while also having explicit control over the setting in LO. I also believe, like I asserted in bug 115688, that having the marching ants control exposed in Tools -> Options -> Accessibility and not just in hidden/buried in Expert options would be even more helpful. (In reply to crxssi from comment #8) > It is interesting that there is a valid case both FOR marching ants being on > for accessibility and also OFF for accessibility, depending on your personal > accessibility problem. I hadn't thought of that. > > I echo @ady 's sentiment that having LO honor the OS setting as the default > makes sense, while also having explicit control over the setting in LO. I > also believe, like I asserted in bug 115688, that having the marching ants > control exposed in Tools -> Options -> Accessibility and not just in > hidden/buried in Expert options would be even more helpful. I've been thinking about this today. I am a big fan of accessibility so I had the same surprise as @crxssi. I can see reasonably well with correction but I am quite annoyed by the marching ants. I just got accustomed to hammering the Escape key immediately after pressing Command-C. I implemented the native setting integration when I realized 1) others felt the same as me and 2) it would be controlled by a very specific macOS accessibility setting. Seemed like a low risk of upsetting existing users. :/ I can definitely see how useful the marching ants are especially if you need to copy and paste a lot. For me, the marching ants are a quick way to locate the last cell copied when I want to verify that I pasted what I intended to). So where do we go from here? I'm no accessibility expert at all, but maybe the problem is that the marching ants really just doesn't work for a lot of people but we need a different way to highlight the cell last copied. I admit that while I dislike the marching ants I took a look at Microsoft Excel and they have a much slower, thicker marching ants. Unfortunately, I'm no UI expert either so maybe there is a better solution that is easy for someone like me to implement such as a solid rectangle but different color than the selected cell? Personally, I like how drawing of the marching ants' rectangle is contained within the cell so (just like Microsoft Excel) so that it looks slightly smaller than the selected cell. Just my thoughts. (In reply to Patrick Luby (volunteer) from comment #9) > So where do we go from here? I'm no accessibility expert at all, but maybe > the problem is that the marching ants really just doesn't work for a lot of > people but we need a different way to highlight the cell last copied. I > admit that while I dislike the marching ants ...they serve a use for some users and/or some tasks. (In reply to crxssi from comment #8) > I echo @ady 's sentiment that having LO honor the OS setting as the default > makes sense, while also having explicit control over the setting in LO. The challenge is that the existing "AnimationsEnabled" setting is a boolean, i.e. it can only be true or false, which doesn't provide the flexibility we'd need when we want to allow explicitly using or overriding the system-provided value in addition. Could it make sense to replace that with a new setting that would allow setting either of "Enabled"/"Disabled"/"Automatic" instead, with the latter being the default? That would be similar to what we have for Light/Dark mode in "View" -> "Appearance" -> "Mode", or for "Accessibility" -> "High Contrast". (In reply to Patrick Luby (volunteer) from comment #9) > I took a look at Microsoft Excel and they have a much slower, thicker > marching ants. Unfortunately, I'm no UI expert either so maybe there is a > better solution that is easy for someone like me to implement such as a > solid rectangle but different color than the selected cell? Personally, I > like how drawing of the marching ants' rectangle is contained within the > cell so (just like Microsoft Excel) so that it looks slightly smaller than > the selected cell. Adding the design team: Any thoughts/suggestions? (In reply to Michael Weghorn from comment #11) > Could it make sense to replace that with a new setting that would allow > setting either of "Enabled"/"Disabled"/"Automatic" instead, with the latter > being the default? Was my first idea too. (In reply to Patrick Luby (volunteer) from comment #9) > a solid rectangle but different color than the selected cell Please keep in mind that different solid colors are also a potential conflict with colors of other UI artifacts (grid lines, borders, background, font, dark theme...), and it is also an accessibility issue (e.g. different types of color blindness). For some users, having the movement of "ants" helps differentiate the copied area from other "static" non-solid styles of lines. For other users, the animation can be an unnecessary distraction – I am talking about really bothering user's ability to concentrate, not just some minor issue. Both cases could be meaningful for each group of users, while the other possible OS animations might be set to either ON or OFF according to other needs (e.g. hardware resources). The opposing needs is the reason that the behavior must rely on LO/Calc settings, taking the OS's setting as a base only. A minor reminder: when the animated ants is allowed, users can press [ESC] to stop both the animation and the dotted line, while the clipboard is still available for further pasting actions. This could be at least a partial workaround for the group of users that are slightly bothered by the "ants", although IMO the accessibility aspects are still very relevant anyway. |
Description: Copying cells in Calc doesn't show “marching ants” animation, neither in default configuration nor regardless of the expert option "AnimationsEnabled", unless the OS’s "Show animations" setting is switched on. In previous versions including 7.6.7.2 the OS’s "Show animations" setting was disregarded. Starting with LibreOfficeDev_24.2.0.0.alpha0/alpha1, this setting is suddenly not only used in LibreOffice (for just the "marching ants" animation), but it in fact overrides expert option "AnimationsEnabled" set to “true”. Starting with LibreOfficeDev_24.2.0.0.alpha0/alpha1 , one is able to turn _off_ the "marching ants" animation in LO by using the expert setting "AnimationsEnabled", regardless of the state of "Show animations in Windows". However, the problem is, than one is not able to turn _on_ the "marching ants" animation in LO by using the expert setting "AnimationsEnabled", regardless of the state of OS’s "Show animations" setting. For visual impaired people (e.g. elderly people), or just having bad light conditions, the "marching ants" animation is really helpful and this helpful feature is known from MS Excel. The OS’s "Show animations" setting turns on _all_ animations in the OS and makes a slow computer even slower. Also for people using Remote Desktop, having to enable _all_ animations in the OS just for having the “marching ants” animation in LO is a bad idea. The copied cells have not any more a "marching ants" animation copy border starting with LibreOfficeDev_24.2.0.0.alpha0/alpha1 , but have just a "sleeping ants" border, if the OS’s "Show animations" setting is switched off. The expert option "AnimationsEnabled" doesn't have an effect, neither “true” nor “false” activate the "marching ants" animation. Note: the page break / print area also uses the same "sleeping ants" border, which is confusing to non-experts. There are likely very few people having to have all the OS's animation turned on (by the OS's animation setting turned on), and then in LO to switch off the "marching ants" animation - unless the problem is, that quite some people didn't know about this expert setting. Suggestion: There should be an option to have the LO animation "Always on" or "Always off" regardless of the OS's animation setting. a) The default behaviour of copying cells should be the old "marching ants" animation, when the expert setting "AnimationsEnabled" is “true”, regardless of the state of OS’s "Show animations" setting. I do understand that there might be people feeling annoyed by "marching ants" animation, but the option to switch on/off the animation ("AnimationsEnabled") must be respected. Or b) Perhaps it would be an even better idea to have a new LO tristate-option (perhaps "AnimationsEnabledTristate") with three alternatives: “Always on”, “Always off” and “Use OS’s animation setting” In any case, it needs to be documented how to switch the "marching ants" animation on/off. Searching in the code for "AnimationsEnabled" I found (among others): https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/overlayobject.cxx?r=9d68c794#41 Change request: Changing the line of code: https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/overlayobject.cxx?r=9d68c794#41 mbAllowsAnimation = (officecfg::Office::Common::VCL::AnimationsEnabled::get() && !MiscSettings::GetUseReducedAnimation()); into: mbAllowsAnimation = officecfg::Office::Common::VCL::AnimationsEnabled::get(); Expert option "AnimationsEnabled" specifically: I changed this setting using: “Tools” -> “Options” -> “LibreOffice” -> “Advanced” -> “Open Expert Configuration” -> Type: animat "org.openoffice.Office.Common" -> "VCL" -> "AnimationsEnabled". The problem occurred with the patch discussed in tdf#155414 comment 7. https://bugs.documentfoundation.org/show_bug.cgi?id=155414#c7 It is still present in 24.2.4.2 and got introduced in 24.2.0.0.alpha0/alpha1. However, in 7.6.7.2 the "marching ants" animation worked as usual. Note: The bug is also present in 24.8.beta1. Before it makes sense to change the code, how do you see the above suggestion and change request? Steps to Reproduce: 1. Preferable use a windows-OS, but this bug should also be present in MacOS. 2. Set the OS’s animation setting to switched _off_. For Windows do the following: Details for "Show animations in Windows" in "Ease of Access" setting in WindowsOS: (English: Windows OS -> Settings -> "Ease of Access" -> "Display" -> "Simplify and personalise Windows" -> "Show animations in Windows") (German: Windows OS -> Einstellungen -> "Erleichterte Bedienung" -> "Bildschirm" -> "Windows vereinfachen und personalisieren" -> "Animationen in Windows anzeigen") 3. At least on WindowsOS, wait up to 30 seconds for the change of the animation setting to take effect. 4. Make sure that the OS’s animation setting is switched off and have taken effect. 5 (If needed) Install a parallel installation of 7.6.7.2 win x86_64. 6. (If needed) Install a parallel installation of 24.2.4.2 win x86_64 7. Create a new Calc document. 8. Select a group a cells and select "Copy" 9. Repeat the tests with different setting of expert option "AnimationsEnabled": “true”/false”. Actual Results: In 7.6.7.2: The copied cells have a "marching ants" animation border as usual, regardless of the state of the OS’s animation setting. In 24.2.4.2: The "marching ants" animation does not work: The copied cells have a "sleeping ants" border (the same as the page break / print area). This provided that the OS’s animation setting is switched _off_ and have taken effect. In 7.6.7.2: The expert option "AnimationsEnabled" gets respected: "true" means "marching ants" animation border. "false" means "sleeping ants" border. In 24.2.4.2: The expert option "AnimationsEnabled" gets disregarded. Both "true" as well as "false" means "sleeping ants" border provided that the OS’s animation setting is switched _off_ and have taken effect. In 24.8.0.0.beta1+: The same result as in 24.2.4.2. Testing restarting in Safe Mode with hardware acceleration turned off produced the same result as above (with 24.2.4.2 and 24.8.0.0.beta1+) Expected Results: 1. The default behaviour should be that the copied cells have a "marching ants" animation as usual until and including 7.6.7.2. 2. The expert option "AnimationsEnabled" must get respected, even if the OS’s animation setting is switched off. "AnimationsEnabled" set to "true" means "marching ants" animation border. "false" means "Sleeping ants" border. Reproducible: Always User Profile Reset: Yes Additional Info: Details of my parallel installations of LO: (the were freshly installed with a new user profile in: UserInstallation=$ORIGIN/../Data/settings ) Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: dcaf9c147a1cfea268db49952171338555379794 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded ********************************************************** Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded This bug is in effect regardsless if advanced experimental features are enabled or not. See also the fixed bug report tdf#156506. See also the fixed bug report tdf#155414 Before it makes sense to change the code, how do you see the above suggestion and change request?