*** 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.

Suggested via IRC: Go with "System" instead of "Automatic", see https://postimg.cc/gallery/J77bGN8

Looks like Calc uses the current expert option for marching ants together with a system setting for macOS; all modules disable text animations with the one option and graphic animations (likely animated gif only) with the other plus the macOS thing.

Based on this we could name the option "Reduce Animations" with the options System (or Automatic)/Disabled/Enabled.

Calc:
ScOverlayDashedBorder::ScOverlayDashedBorder()
...
mbAllowsAnimation = (officecfg::Office::Common::VCL::AnimationsEnabled::get() && !MiscSettings::GetUseReducedAnimation());


Generic:
 // check if text animation is allowed.
 bool ObjectContactOfPageView::IsTextAnimationAllowed() const
     return officecfg::Office::Common::Accessibility::IsAllowAnimatedText::get();

 // check if graphic animation is allowed.
 bool ObjectContactOfPageView::IsGraphicAnimationAllowed() const
    // Related tdf#156630 respect system animation setting
    return officecfg::Office::Common::Accessibility::IsAllowAnimatedGraphics::get() && !MiscSettings::GetUseReducedAnimation();

The three settings regarding animations doesn’t seem to have any influence to each other.
1. The current boolean expert setting AnimationsEnabled: It is only used in Calc to switch off the marching ants feature, but it can’t enable it (unless _all_ animations are switched on in the OS’s setting). It isn’t used for anything else than the marching ants feature.

2. The other animations settings are for animated text resp. animated graphics such as GIF images. These options are unrelated to the marching ants feature.

3. The new behaviour having the OS’s all-or-nothing animation setting to override LO’s animation setting was introduced in LO 24.2, also for MS Windows, not just for MacOS. Animations in LO is then effectivly _prohibited_ unless OS’s all-or-nothing animation setting is switched on.
This is the case for both the marching ants feature as well as for graphic animation feature. This behaviour is for the user both surprising and undesirable, IMHO.
The current implementation of both the setting “allow animation images” and expert setting “ AnimationsEnabled” are effectivly deny-animation-settings, with no options to switch them on in LO’s settings.

4. LO’s setting should have precidence over the OS’s settings, not the other way around. 

5. Regarding naming: In MacOS it might be called “reduced animations”, but in MS Windows the OS’s setting for switching on/off animations is an all-or-nothing option called "Show animations in Windows".

6. Current state of work: screenshots from glade:  https://postimg.cc/gallery/JjthJ6J
The alignments are not yet perfect. Please come with feedback.

Screenshot from "Options-->View" was missing with its "System" option: Here included in the gallery: https://postimg.cc/gallery/B2Rb5rx

When solving this bug the following question needs to be answered: 
Should positive or negative logic be used?
a) Enable/Allow e.g. animations
b) Disable/Forbid/Reduce e.g. animations:
Positive logic is generally easier to understand (at least for non-programmers).

2. Then the suitable wording will be clearer.

3. Perhaps a better wording of the label could be: “Enable other Animations”.
“other” meaning other than the animation settings above.

The aligment problem is fixed. See the updated screenshots from glade: https://postimg.cc/gallery/xXrGXcC 
When wordings, ordering, etc are fix, then I’ll update the ui-file.

Not sure how to best represent inheritance (or lack thereof) but I just wanted to say that I support the use of the term "System" to clarify the link with the OS and to be consistent with the View panel.

While we're at it, I would suggest removing the "Options [for]" bits in the headers. Short and to the point is best. We are in the Options dialog after all.
For "Miscellaneous", looks like other panels use "Other" instead.
So with new names and more logical order:

- Animations
- High Contrast
- Other

What do you think?

(In reply to Stéphane Guillou (stragu) from comment #21)
> For "Miscellaneous", looks like other panels use "Other" instead.
> So with new names and more logical order:
> - Animations   - High Contrast    - Other
It’s good with concise names. 
In the other options dialogues I didn’t find any “Other”, so keeping "Miscellaneous" could be an option?

Aligning with the terminology of “Allow animated images”, I suggest “Allow other animations:” with the options “System”/”No”/”Yes”.
Combining the phrase “Enable other animations” with the options “Disable” (and the rest), feels strange to me.

As suggested by Stéphane, I reordered the options (and aligned the allowance terminology). Here’s the result:
https://postimg.cc/gallery/RMCBbKC

What do you think?
Is this agreeable, or other ideas?
(In reply to Stéphane Guillou (stragu) from comment #21)
> Not sure how to best represent inheritance (or lack thereof) but I just
> wanted to say that I support the use of the term "System" to clarify the
> link with the OS and to be consistent with the View panel.
> 
> While we're at it, I would suggest removing the "Options [for]" bits in the
> headers. Short and to the point is best. We are in the Options dialog after
> all.
> For "Miscellaneous", looks like other panels use "Other" instead.
> So with new names and more logical order:
> 
> - Animations
> - High Contrast
> - Other
> 
> What do you think?

(In reply to Stéphane Guillou (stragu) from comment #21)
(sorry for double posting: preview showed wrongly)
> For "Miscellaneous", looks like other panels use "Other" instead.
> So with new names and more logical order:
> - Animations   - High Contrast    - Other

It’s good with concise names. 
In the other options dialogues I didn’t find any “Other”, so keeping "Miscellaneous" could be an option?

Aligning with the terminology of “Allow animated images”, I suggest “Allow other animations:” with the options “System”/”No”/”Yes”.
Combining the phrase “Enable other animations” with the options “Disable” (and the rest), feels strange to me.

As suggested by Stéphane, I reordered the options (and aligned the allowance terminology). Here’s the result:
https://postimg.cc/gallery/RMCBbKC

What do you think?
Is this agreeable, or other ideas?

(In reply to Per99 from comment #23)
> In the other options dialogues I didn’t find any “Other”, so keeping
> "Miscellaneous" could be an option?
Seen in Writer > Print and Writer/Web > Print, but "Miscellaneous" is fine too.
> Here’s the result:
> https://postimg.cc/gallery/RMCBbKC
I'm happy with the mockups, I'd say go ahead and submit a patch!

(In reply to Stéphane Guillou (stragu) from comment #24)
> I'm happy with the mockups, I'd say go ahead and submit a patch!
Cool, thank you. I'll start changing the code.

But we do have an unsolved inconsistency issue regarding animation in Draw and Writer:

@htietze: Thank you for offering support. What I need most is to find an intuitive solution for the normal novice user. 

The current state of the animation options are inconsistent and confusing: 
“Marching Ants” and “allow animation images” (in draw)  can’t be enabled regardless of the OS’s animation setting, as contrary to their “allow” label, they work as a _disable-only_ setting. In Writer “allow animation images” works as the user expects: as allowance setting and doesn’t get overridden by OS’s animation setting. 

Alternative a) The most intuitive way would be skip take the OS’s animation setting into account and have all the animation setting openly on the accessibility option page, IMHO. No use of expert settings, that the user needs to see. If it would have been done in that way from the beginning, we wouldn’t have these issues and inconsistencies now. Best would be to have three options: “Allow animated images”, “Allow animated text” and “Allow other animations: Yes/No”. No OS’s animation setting to bother with. The user has it clearly in their hands in the accessibility dialogue.

Alternative b) If don’t we go with the most intuitive alternative, IMHO, then the label of check-buttons must reflect their behaviour! A disable-only switch should be labelled that way. And the behaviour should also be consistent in both Writer and Draw. In this alternative we would take OS’s animation setting into account and have the labels “_Disallow_ animated images”, “Allow animated text” and “Allow other animations: System/Yes/No”. 

From a User Experience, I regard alternative b) as unintuitive, and would strongly advice alternative a), but if the design team want alternative b) I can implement the code accordingly.

@htietze: I understand your last comment in the #libreoffice-design chat, as that you’re fine with alternative A.  I’ve implemented Alternative A and build and tested it. Here are the screen shots:   https://postimg.cc/gallery/RnG18Kh
What do you think? 
I’ll submit the patch accordingly.

(In reply to Per99 from comment #25)
> Alternative a) The most intuitive way would be skip take the OS’s animation
> setting into account and have all the animation setting openly on the
> accessibility option page, IMHO. No use of expert settings, that the user
> needs to see. If it would have been done in that way from the beginning, we
> wouldn’t have these issues and inconsistencies now. Best would be to have
> three options: “Allow animated images”, “Allow animated text” and “Allow
> other animations: Yes/No”. No OS’s animation setting to bother with. The
> user has it clearly in their hands in the accessibility dialogue.
> 
> Alternative b) If don’t we go with the most intuitive alternative, IMHO,
> then the label of check-buttons must reflect their behaviour! A disable-only
> switch should be labelled that way. And the behaviour should also be
> consistent in both Writer and Draw. In this alternative we would take OS’s
> animation setting into account and have the labels “_Disallow_ animated
> images”, “Allow animated text” and “Allow other animations: System/Yes/No”. 
> 
> From a User Experience, I regard alternative b) as unintuitive, and would
> strongly advice alternative a), but if the design team want alternative b) I
> can implement the code accordingly.

I think we should default to honoring the OS/desktop environment setting, and allow the user to explicitly override it if needed.
In this case, it's particularly relevant for accessibility (people with  vestibular motion disorders), see tdf#155414 and this related MDN article:
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

(In reply to Per99 from comment #25)
> Alternative a) The most intuitive way would be skip take the OS’s animation
> setting into account and have all the animation setting openly on the
> accessibility option page
That's an overly drastic move. We should obey system settings but allow to override in both directions and have to show that. The wording of alternative a) sounds good to me, and the simplicity of the UI too. How about a tri-state checkbox, which indetermined state would be "take it from the OS" (and we make that clear with a tooltip)?

(In reply to Heiko Tietze from comment #28)
> That's an overly drastic move. We should obey system settings but allow to
> override in both directions and have to show that. The wording of
> alternative a) sounds good to me, and the simplicity of the UI too. How
> about a tri-state checkbox, which indetermined state would be "take it from
> the OS" (and we make that clear with a tooltip)?

I think a combobox would be more intuitive than a tri-state combobox, and also in line with what we do elsewhere, e.g. for the "Automatic" option in "Application colors".

(In reply to Heiko Tietze from comment #28)
>  How about a tri-state checkbox, which indetermined state would be "take it 
> from the OS" (and we make that clear with a tooltip)?
I also thought about that option and a clear tooltip, but…
The tooltip is switched off as default - shouldn’t that be changed?

(In reply to Michael Weghorn from comment #29)
> I think a combobox would be more intuitive than a tri-state combobox...
And has a better support for accessibility. Let's go with this solution.

(In reply to Michael Weghorn from comment #29)
> I think a combobox would be more intuitive than a tri-state combobox, and
> also in line with what we do elsewhere, e.g. for the "Automatic" option in
> "Application colors".
Here’s a new alternative C, using comboboxes for "Allow animated images" and for "Allow other animations" similar to:  Options --> View  --> Appearance Mode: “System/Light/Dark.
Here the options “System/No/Yes” seems sensible.
See screenshots: https://postimg.cc/F1yBCjLB

However:
In Draw, the OS’s animation option is honoured for animated images, but not for animated text (e.g. in text boxes).
In Writer, the OS’s animation option isn’t honoured at all.
To care for those people with vestibular motion disorders, shouldn’t we also change that behaviour also for these above not yet honoured cases? 
If so, then I’ll also add a third combobox “Allow animated text” “System/No/Yes” (with System as default).

What do you think about the screenshots and what to honour?

(In reply to Per99 from comment #32)
> What do you think about the screenshots and what to honour?
Sorry wrong link, here's the gallery link: https://postimg.cc/gallery/dwF34pD

(In reply to Per99 from comment #32)
> Here’s a new alternative C...
Looks good (and one picture illustrates the idea sufficiently).

> However:
> In Draw...
Why not fix this?

(In reply to Heiko Tietze from comment #34)
> (In reply to Per99 from comment #32)
> > Here’s a new alternative C...
> Looks good (and one picture illustrates the idea sufficiently).
> 
> > However:
> > In Draw...
> Why not fix this?
Thought so too. Here’s a screenshot of the preview (note that the preview has very minor difference to the rendered GUI):  https://postimg.cc/GH22pG6S

Another topic: The old expert option "AnimationsEnabled" becomes obsolete with these changes. Stephan Bergman wrote in a gerrit comment to this patchset: “If a configuration property becomes obsolete, just mark it as such in the description (or remove it, if/when there is consensus that that's OK). Do not rename it.”
See: https://gerrit.libreoffice.org/c/core/+/170827/1/officecfg/registry/schema/org/openoffice/Office/Common.xcs

The same goes with old boolean options “IsAllowAnimatedGraphics” and “IsAllowAnimatedText”. There we would need another options as enum (xs:short) named like “AllowAnimatedGraphicsEnum” or “AllowAnimatedGraphics”

So what to do with old obsolete options ("AnimationsEnabled", “IsAllowAnimatedGraphics” and “IsAllowAnimatedText”)? Mark in them the description as obsolete or to remove some/all of them?

(In reply to Per99 from comment #35)
> (In reply to Heiko Tietze from comment #34)
> > (In reply to Per99 from comment #32)
> > > Here’s a new alternative C...
> > Looks good (and one picture illustrates the idea sufficiently).
> > 
> > > However:
> > > In Draw...
> > Why not fix this?
> Thought so too. Here’s a screenshot of the preview (note that the preview
> has very minor difference to the rendered GUI):  https://postimg.cc/GH22pG6S

Thanks, looks good to me.

As a side note/question: Is there a particular reason you're not attaching screenshots here in Bugzilla? (In general, I think it's useful to attach to Bugzilla, to ensure files remain available here for future reference.)


> The same goes with old boolean options “IsAllowAnimatedGraphics” and
> “IsAllowAnimatedText”. There we would need another options as enum
> (xs:short) named like “AllowAnimatedGraphicsEnum” or “AllowAnimatedGraphics”

I'd go with just “AllowAnimatedGraphics”.

> So what to do with old obsolete options ("AnimationsEnabled",
> “IsAllowAnimatedGraphics” and “IsAllowAnimatedText”)? Mark in them the
> description as obsolete or to remove some/all of them?

I don't know either what the exact process for deprecation/removal looks like (and neither `configmgr/README.md` nor `officecfg/README.md` seem to describe it from a cursory glance). Maybe best to ask in IRC or on the mailing list if nobody else replies here with more details?

(In reply to Per99 from comment #35)
> The same goes with old boolean options “IsAllowAnimatedGraphics” and
> “IsAllowAnimatedText”. There we would need another options as enum
> (xs:short) named like “AllowAnimatedGraphicsEnum” or “AllowAnimatedGraphics”

You could also keep the name assuming true/false are converted into 0/1- and take everything else as System. Once you have submitted a patch we can present your solution in the ESC.

Created attachment 195505 [details]
LO Draw document with animation of images and text

Created attachment 195506 [details]
LO Impress document with animation of images and text

Created attachment 195507 [details]
LO Writer document with animation of images and text

(In reply to Michael Weghorn from comment #36)
> Thanks, looks good to me.
A small text change in the accessibility option page: It felt sensible to change the text “Allow other animations” into “Allow UI animations”, since the tooltip is disabled as default. (Wouldn’t it make sense, that the tooltip is enabled as default?). Hope you are fine with this, else I can just change it back.

> As a side note/question: Is there a particular reason you're not attaching
> screenshots here in Bugzilla? (In general, I think it's useful to attach to
> Bugzilla, to ensure files remain available here for future reference.)
As long as this is work in progress, and it doesn’t seem to be able to delete any contents here, it seems much clearer to show which version of the screenshot are the current state as the are put in the related comment. The links to the screenshots are valid “for ever”.

> I'd go with just “AllowAnimatedGraphics”.
Thanks for the suggestion, so I did.

> I don't know either what the exact process for deprecation/removal looks
> like (and neither `configmgr/README.md` nor `officecfg/README.md` seem to
> describe it from a cursory glance). Maybe best to ask in IRC or on the
> mailing list if nobody else replies here with more details?
I’ll leave the obsolete configuration variables in the config file for now.

(In reply to Heiko Tietze from comment #37)
> (In reply to Per99 from comment #35)
> > The same goes with old boolean options “IsAllowAnimatedGraphics” and
> > “IsAllowAnimatedText”. There we would need another options as enum
> > (xs:short) named like “AllowAnimatedGraphicsEnum” or “AllowAnimatedGraphics”
> You could also keep the name assuming true/false are converted into 0/1- and
> take everything else as System. 
Thanks for the suggestion.  However, 
1. how would the LO’s database react when a configuration variable/content got changed type/size?
2. IsAllow...  sounds very much as a boolean option, so an enum in it is rather a surprise?
So I chose “AllowAnimatedGraphics”.

>Once you have submitted a patch we can
> present your solution in the ESC.
Here are the current screenshots: https://postimg.cc/gallery/bG5kYcp    (using the text “Allow UI animations”. 
How do you like it?

I uploaded files with animated text and images for testing purpose.

Here is my submitted patch. https://gerrit.libreoffice.org/c/core/+/170827
The UI-file stayed stuck with wrong file mode in git, so I tried many times to submit it.

Here’s the commit message:
tdf#161765 Let user choose which animation settings to use: OS's / LO's

In the accessibility option page, the user can now choose which animation
settings to use (OS's or LO's animation setting) and what animations to allow.

Changes due to this patch:
1. Changes in the GUI of the accessibility option page:
  - New option "Allow UI animations"  (Used for "Marching Ants" animation,
    instead of the old expert option "AnimationsEnabled"), now as enum.
  - Changed option: "Allow animated images", now as enum: "System", "No", "Yes"
  - Changed option: "Allow animated text", now as enum: "System", "No", "Yes"
  - The old animation options in Common.xcs are not renamed, but marked as
    obsolete in their text.
These above changes are in the files: [optaccessibilitypage.ui,
optaccessibility.hxx, optaccessibility.cxx, Common.xcs]

2. Added functions to compute if the animations of images/text/UI are allowed.
If "System" is chosen, then use OS’s animation setting.
See files: [settings.hxx, settings.cxx]

3. Respect the animation settings of animated images/texts in Draw and Impress.
Don't prohibit the user to enable animations in Draw and Impress if the OS's
animations are disabled. See file: [objectcontactofpageview.cxx]
4. Respect the animation settings of animated images in Writer.
See file: [viewsh.cxx]
5. Respect the UI animation setting in Calc ("marching ants" animation).
Don't prohibit the user to enable UI animations in LO if the OS's animations
are disabled. See file: [overlayobject.cxx]

Change-Id: I5173f9b3d8652a17a6ae07164e874143738bcd66

(In reply to Per99 from comment #41)
> (In reply to Michael Weghorn from comment #36)
> > Thanks, looks good to me.
> A small text change in the accessibility option page: It felt sensible to
> change the text “Allow other animations” into “Allow UI animations”, since
> the tooltip is disabled as default. (Wouldn’t it make sense, that the
> tooltip is enabled as default?). Hope you are fine with this, else I can
> just change it back.

Sounds good to me. In order to make the tooltip show by default, the text (or a shorter variant thereof) could be set for the "tooltip" property in the .ui file instead of as the accessible description. Heiko might be able to say more on when that's recommended or not.

> As long as this is work in progress, and it doesn’t seem to be able to
> delete any contents here, it seems much clearer to show which version of the
> screenshot are the current state as the are put in the related comment. The
> links to the screenshots are valid “for ever”.

When uploading an attachment, you can mark previous ones as obsoleted by that one. It's not completely deleted then, but shown as obsolete, which makes clear what the current state is, but still allows seeing older versions if desired, e.g. to follow the previous design discussion leading to the current version.

I'll also comment on the Gerrit change.

Thanks a lot for working on this!

(In reply to Per99 from comment #43)
> “Allow UI animations”
This label is misleading as we use the term UI for just the interface and none of any attributes in the documents. It could be understood as some progressive opening/closing animation of menus, maybe as blinking on keypress, etc. but would probably never be assumed to be marching ants.

(In reply to Heiko Tietze from comment #45)
Waiting with the review until the merge conflict is solved.

(In reply to Michael Weghorn from comment #44)
> (In reply to Per99 from comment #41)
> > Wouldn’t it make sense, that the tooltip is enabled as default?
> In order to make the tooltip show by default, the text
> (or a shorter variant thereof) could be set for the "tooltip" property in
> the .ui file instead of as the accessible description. Heiko might be able
> to say more on when that's recommended or not.
Both the "tooltip" property as well as "extended_tip" property are used in the ui-files. 
Clarification: It is the extended tip that is disabled as default.
> 
> Thanks a lot for working on this!
Thank you for the kind feedback!

(In reply to Heiko Tietze from comment #45)
> (In reply to Per99 from comment #43)
> > “Allow UI animations”
> This label is misleading as we use the term UI for just the interface and
> none of any attributes in the documents. It could be understood as some
> progressive opening/closing animation of menus, maybe as blinking on
> keypress, etc. but would probably never be assumed to be marching ants.
OK, understand. I changed it back to "Allow other animations".

How about using the "tooltip" property in this optaccessiblepage-UI instead of "extended_tip", as the extended_tip is disabled by default?

The merge conflict is dissolved.

Here are the screenshots of the current GUI:  https://postimg.cc/gallery/NHHj8TN

Created attachment 195607 [details]
GUI of optaccessibilitypage showing selectable options

Created attachment 195608 [details]
GUI of optaccessibilitypage showing the extended_tip

Created attachment 195609 [details]
Screenshot of expert options showing the extended_tip of the obsolete property 'AnimationsEnabled'

Per99 committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ef7429f86788f0616db5b274ec77eb67cd41cb3d

tdf#161765, tdf#115688 Let user choose which animation settings to use

It will be available in 25.2.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.

(In reply to Per99 from comment #47)

> Both the "tooltip" property as well as "extended_tip" property are used in
> the ui-files. 
> Clarification: It is the extended tip that is disabled as default.

Indeed, that's what I was trying to say: If the "tooltip" property is set, it will be shown by default. If the "accessible-description" property (also used for the extended tip) is set, it will only be shown when showing extended tips is explicitly enabled.
(There's no "extended-tip" property AFAICT, as that's something LO-specific, not one of the usual properties that are set in a GTK 3 .ui file. "extended_tip" is often mentioned in the "context" for that property, though),

> How about using the "tooltip" property in this optaccessiblepage-UI instead
> of "extended_tip", as the extended_tip is disabled by default?

@Heiko: What do you think? (That could be done in a separate change.)


> The merge conflict is dissolved.

Thanks! Merged now.

(In reply to Heiko Tietze from comment #46)
@Heiko:
1. How about using the "tooltip" property in this optaccessiblepage-UI instead of "extended_tip" [/"accessible-description"], as the extended_tip is disabled by default?

2. Or to let the ExtendedTip property be allowed as default?
(Currently it's not, see ExtendedTip property  in Common.xcs).

3. How about to change the importance to "medium normal", so it can be integrated earlier than in version 25.2?
To me it *is* a bug, that the user can't enable in LO the animation of images and "marching ants" animation if the OS's setting "allow [all] animations" is not enabled. I do understand, that until there isn't a fix, such issues can seem unimportant and bothersome. Well, now we have an merged fix, so that's not an issue.
[For old behaviour of Draw and Impress, see following code line https://opengrok.libreoffice.org/xref/core/svx/source/sdr/contact/objectcontactofpageview.cxx?r=0cc4333e#388 ]

4. Thanks to all for all work together finding a good solution!

(In reply to Per99 from comment #53)
> 3. How about to change the importance to "medium normal", so it can be
> integrated earlier than in version 25.2?

Regardless of the importance, one challenge is that the change includes both string and UI changes and we're way past the string and UI freeze for 24.8 [1]. So that would need exemption from that (and translators taking care of translating to all languages), which usually only happens for critical things.

[1] https://wiki.documentfoundation.org/ReleasePlan/24.8

The tooltip explains the function on unlabeled controls such as icon-only buttons. The extended tooltip aims to explain the functionality. I would leave it as it is- and focus on update of the online help.

The dropdown controls are not aligned, which will become obvious with translation.

Thanks for the patch!

If you are up for it, a description of the change in the release notes would be much appreciated: https://wiki.documentfoundation.org/ReleaseNotes/25.2

(In reply to Heiko Tietze from comment #55)
> The dropdown controls are not aligned, which will become obvious with
> translation.
Grrr, as I read your line, I thought, oh, oh, I didn't think about the translations and aligning... Thanks! 
I would align all four Comboboxes. Here's a screenshot: https://postimg.cc/bZrw0qS4
(I don't want to clutter/noise the bug "conversation" with uploading a preview-screenshot. The postimg link is valid "for ever".)

> The tooltip explains the function on unlabeled controls such as icon-only
> buttons. The extended tooltip aims to explain the functionality. I would
> leave it as it is- and focus on update of the online help.
Thank you for the explaination. I understand.

A question again: What about having the extended tooltip (ExtendedTip property) enabled as default?
That could be of big help for new users, and easily to disable if unwanted.
If there are no big objections, I would suggest so.

I would prefer to submit the new GUI-version with a new change-ID, so there are less risks for another merge conflict. There will be a change to just the optaccessibilitypage.ui file.

(In reply to Per99 from comment #57)
> I would align all four Comboboxes. Here's a screenshot:
The question is rather how you solve the problem. GtkAlignment is one option, the other to unscramble the nested boxes/grids. I would place image/label/dropdown etc. in the cells of one grid.

> A question again: What about having the extended tooltip (ExtendedTip
> property) enabled as default?
> That could be of big help for new users, and easily to disable if unwanted.
> If there are no big objections, I would suggest so.
While I was looking for arguments against changing the default, the idea is actually not so bad. But it is a different topic and you should create a new ticket.

(In reply to Per99 from comment #58)
> I would prefer to submit the new GUI-version with a new change-ID, so there
> are less risks for another merge conflict. There will be a change to just
> the optaccessibilitypage.ui file.

Yes, that's the (only) correct way to do this as the previous change has been merged already.

(In reply to Heiko Tietze from comment #59)
> (In reply to Per99 from comment #57)
> > I would align all four Comboboxes. Here's a screenshot:
> The question is rather how you solve the problem. GtkAlignment is one
> option, the other to unscramble the nested boxes/grids. I would place
> image/label/dropdown etc. in the cells of one grid.
Thank you Heiko for the suggestion.
Before wanting to ask how to do it, I wanted to spend some effort/hours to find a solution myself searching how other has solved the aligning problem. In the optviewpage.ui they use GtkSizeGroup for both the labels (aligning vertically) as also for the comboboxes (aligning the width of the comboboxes). That solution I implemented yesterday. It seems to work well and the screenshot is from that solution. It looks good to me and feedback is welcome.

> > A question again: What about having the extended tooltip (ExtendedTip
> > property) enabled as default?
> > That could be of big help for new users, and easily to disable if unwanted.
> > If there are no big objections, I would suggest so.
> While I was looking for arguments against changing the default, the idea is
> actually not so bad. But it is a different topic and you should create a new
> ticket.
Thank you! I would highly appreciate that and I'd gladly submit a bug ticket and implement is timely.

(In reply to Per99 from comment #61)
> GtkSizeGroup ... looks good to me and feedback is welcome.
Fine for me.

It's just bad style to nest multiple boxes and grids but I'm not aware of any actual negative impact.

(In reply to Per99 from comment #61)
> > > A question again: What about having the extended tooltip (ExtendedTip
> > > property) enabled as default?
> > > That could be of big help for new users, and easily to disable if unwanted.
> > > If there are no big objections, I would suggest so.
> > While I was looking for arguments against changing the default, the idea is
> > actually not so bad. But it is a different topic and you should create a new
> > ticket.
> Thank you! I would highly appreciate that and I'd gladly submit a bug ticket
> and implement is timely.

opened as bug 162296

(In reply to Heiko Tietze from comment #59)
> The question is rather how you solve the problem. GtkAlignment is one
> option, the other to unscramble the nested boxes/grids. I would place
> image/label/dropdown etc. in the cells of one grid.
(In reply to Heiko Tietze from comment #62)
> It's just bad style to nest multiple boxes and grids but I'm not aware of
> any actual negative impact.
First a summary:
In order to have an even clearer grouping (see explanation below, see screenshot: https://postimg.cc/xqckQfwt) I’ve submitted a patch (also with aligned comboboxes), but set it as Work in Progress (but it is ready to be merged), as I’m waiting for feedback here.

Skip reading the following section, if you’re uninterested in GUI-design with Gtk-widgets.
I tried out how it would look like using just one grid.
In short: It did work out, but the alignment was definitely suboptimal:
1. If I put the section label (e.g. “Animations - with BigGrid”) also in the grid to the very left, then the option labels (e.g. “Allow animated images:”) get aligned to start after the end of the section label. Clearly not what we want.
2. So I put the section labels in a GtkBox followed by a GtkGrid for the options. It looked somewhat OK, but the alignment of the section labels in between (“High Contrast”, “Miscellaneous”) wasn’t good: They were to far away from the section to where the belong, thus reducing a clear grouping.
Resume: Even if “It's just bad style to nest multiple boxes”, it serves better the purpose of having a clear grouping. For the interested reader: Here are screenshots for comparison: https://postimg.cc/gallery/FQRSrLb (See file names for explanation).


My preference is to have an even clearer grouping between the section labels (here: “High Contrast”) and the previous section and its own options. So I changed this vertical alignment in v0.9.4, see screenshot. https://postimg.cc/xqckQfwt

I’ve submitted a patch for this GUI with clearer grouping and also with aligned comboboxes (https://gerrit.libreoffice.org/c/core/+/171388), but set it as Work in Progress (but it is ready to be merged), as I’m waiting for feedback here. 
If there isn’t any objections, I just put the patch status to active and ask for it to be merged.

Per99 committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3afc933ca3d7b88e6f9d3283baed9ef4e3ce2000

tdf#161765 part 2: In optaccessibilitypage.ui, align the Comboboxes.

It will be available in 25.2.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.

This issue is fixed by the commits from comment 51 and 65
-> Closing