In GTK and in Windows there's a system-wide general setting to disable unnecessary UI animations (most importantly, it exists to reduce seizures in sensible subjects). I think the system-wide setting *should* be honored, but I would also favor adding a switch in the general preferences dialog. Also, I strongly dislike poorly though-of UI animations. They introduce unnecessary delays in the UI, sometimes glitching the UI if you click too soon while the animation is completing the cycle (which is *always* the case). I'm not speaking about document animations (which can already be disabled), but about UI animations in all the LibreOffice components. One such example I discovered today, is the animation of the "Comments" header of LibreWriter. Open a new writer document, enable the top ruler and document comments. On the right side of the ruler, a Comments pane/header can be toggled by clicking on it. Clicking results in immediate action (the comments are shown/hidden immediately), while the header takes a full second to complete the fade in/out cycle due to the hover effect, that you cannot skip. After a second, the comments header is also shrunk, which reduces the ruler size and thus repositions the rule in a delayed manner. Besides feeling odd, it's also completely unnecessary (the system hover style/timing/color is not respected).
Let's show this to the UX folks.
I think we need a developer insight instead. I am pretty sure ux-team would favour either of the two options in the following order: 1) if there exists a way to disable this current unwanted animation (and others which we might also have), this would likely be preferred 2) if the first cannot be achieved for technical reasons, we ought to disable all animations (functionality before eyecandy and it would require no "enable anyway" button)
(In reply to mahfiaz from comment #2) > ... Sounds like there's actual discussion towards a change going on in this bug report, so it's no longer all hypothetical Status -> NEW > I think we need a developer insight instead. I am pretty sure ux-team would > favour either of the two options in the following order: I'll leave that decision-making up to the UX Team. Markup the bug as you see fit.
LibreOffice has to respect the individual system settings. As mahfiaz says, if we cannot determine the system setting the best choice is to not animate things. (Introducing a switch to show or hide them anyway bloats our options.)
Agree with mahfiaz that we'd have to find the list of such UI animations and then check with a developer on what is possible. A toggle in the options dialog to disable such animations wouldnt be unreasonable, especially for those with older hardware and those who dont care for the eye candy.
(In reply to Yousuf (Jay) Philips from comment #5) > ... A toggle in the options dialog to disable such animations Definitely against such an option if it's provided by the OS/DE. We must not clutter our options by tweaking the system settings again.
(In reply to Heiko Tietze from comment #6) > Definitely against such an option if it's provided by the OS/DE. We must not > clutter our options by tweaking the system settings again. My suggestion wasnt related to the OS or DE level setting.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
Changing to Enhancement.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
I don't think it's LO's animation. It's animation by OS-level (GTK) Caolan, does LO have own UI animations?
wrt "does LO have own UI animations?", it has a few, the comments fade in mentioned in comment #1, and the header/footer fade-in/out thing in writer as well are LibreOffice's own effects. The system-animations for the gtk backend are mostly the checkbox ticking, the resize effect in insert->toc->entries, and scrollbar fade in on hover. They differ depending on the theme of course so different themes have different effects.