Background: Impress supports 72 slide transitions (including 3D transitions on Linux). They are presented in a long list without any icons, categories or groupings of similar variants of transitions. It can be very confusing to find the right transition. From a user perspective, this can easily be improved. Please add categories, icons or groupings of similar variants of slide transitions. As a comparison, competing presentation programmes are doing a better job in this regard. There is a bug entry for this issue in the OpenOffice.org bugzilla: http://openoffice.org/bugzilla/show_bug.cgi?id=108270.
I'm working on this bug
I haven't had the time for this in a long time. So for now I´ll quit.
sd/source/ui/animations/SlideTransitionPane.hrc is the file where the transitions are displayed.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This request for enhancement is still valid in the current version of LibreOffice. Isn't this an EasyHack? I added "ProposedEasyHack" to the Whiteboard.
I'm halfway through fixing this at the moment -- categories work, but I still need to add some names for them, and fix a minor UI issue.
As it has been picked up and there seems to be good progress, making this a real EasyHack. Also CC'ing thorsten for Impress mentoring if needed.
Is this one going into LibreOffice 3.6? The last comment was two months ago. Thanks!
Resetting this to default due to inactivity
@ A. Hunt: Thanks for working on this bug. Was it possible for you complete this enhancement? If not, please upload your half-done work to this bug report, so that another person can start off from your work. This would be great. Thanks!
Hi. Sorry that patch got a bit lost... I've started working on this again. (Changing the flat list into a tree-listbox is done, I just need to decide how to best to store the categories for the transitions themselves and implement their retrieval.)
I've been working on implementing this as a tree of transitions, but looking at the current Custom Animations Dialog (Implemented in CustomAnimationList.cxx afaict) it looks like it might be better just to have dividers in the list instead of having a tree with categories needing expanding? I.e. I'm wondering whether we'd prefer: Tree: *No Transition *->Category1 |->Transition 1 |->Transition 2 *->Category2 |->Transition X |->.... Vs List: *No Transition --Category 1-- *Transition 1 *Transition 2 --Category 2-- *Transition X *.... I think the list is probably easier to use and doesn't require clicking on individual categories to expand them, on the other hand the transition list is quite long, so this would still required lots of scrolling.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
For this section the short term, I think there should be two drop down menus in the sidebar. On the one hand showing the type (name) of the transition and the other variants of transitions. This would shorten far the long list that is currently displayed.
I guess the only consensus is that the current situation is not good. A list that is not sorted in any meaningful way (even if there is some "clustering" of similar transitions, but then for instance two different dissolves in widely separate locations). So something needs to be done, and (as always) preferably in small steps that can be achieved without large amounts of work (which might not be available). For instance, I don't think I have the skills or time to design graphical UI elements for categories of transitions. (Hint, hint.) Would a good first step be to divide the list into parts, with dividers, as suggested in the second example in comment #12? I guess, especially taking L10N issues into consideration, that my minimal patch that simply sorts the current list https://gerrit.libreoffice.org/#/c/19648/ is not a good idea, as it might move related transitions (that currently luckily are grouped) far from each others in languages where the more specific subtype of a transition comes first in its name?
(In reply to Tor Lillqvist from comment #15) > Would a good first step be to divide the list into parts, with dividers, as > suggested in the second example in comment #12? > Yep, from my side.
Moving variants to a separate listbox is suggested in bug 87621. Alphabetically sorting the list and also grouping them is suggested in bug 87613.
No easy hack at all
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=95e13b89ecb70eb0a03a0c68f0f1e41d02acef22 tdf#36946: Organise transitions hierarchically It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.