In Impress, the slide transitions tab has a long list of entries in a single listbox and it would be better to separate the slide transition name from the slide transition direction/variant. So a user would first look through the slide transition names/type listbox (Wipe, Wheel Clockwise, Uncover, etc) and once they select a name (e.g. Wipe), the second listbox will be populated with its variants (e.g. Up, Right, Left, Down). This separation of name and variant can also be found in MS Powerpoint, iWork Keynote and Corel Presentations. This idea was also suggested by two users of the recent impress survey.
@Jay, Yes this would probably improve UX to split transition types from sub-types into a dropdown. The transition types and sub-types are defined in http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/animations/TransitionType.idl http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/animations/TransitionSubType.idl And against those we have http://opengrok.libreoffice.org/xref/core/slideshow/source/engine/transitions/transitionfactorytab.cxx http://opengrok.libreoffice.org/xref/core/slideshow/source/engine/transitions/slidetransitionfactory.cxx With a smattering of UI/XCU and XML definitions. Unfortunately, looking at transitionfactorytab.cxx, we merge both the Transition type and sub-type when defining the transition effect--calling against that listing. So while they can be identified in the list, a number of transitions in the list are not implemented and indexing could be painful. So, not sure they can be efficiently split into a type and a sub-type for a listbox and dropdown UI widgets. Getting it done would depend on how much work it requires. Still I think it is a good UI enhancement.
Two controls for the same feature is not so good. I would rather organize the one listview using (not selectable) separator lines for categories of options (transitions, animations, etc.) that we have to define. For instance, * No transition * Random transition Movement * Slide up * Slide down * Swirl Fade * Fade black * Fade white * Cross-fade next slide Artistic * Rochade * Memory It's not too important how well options get categorized.
Created attachment 111512 [details] how the variants are separated in other suites We do follow this same break up of direction from effect type in custom animations or else the custom animation dialog which is already fully packed across 5 tabs, would be humongous. (Opened bug 87813 to try and incorporate the dialog into the sidebar) We have 8 variants of Cover and Uncover, 5 of Wheel Clockwise, 4 of Diagonal Squares, Split, Wipe, and Push, 3 of Shape, 2 of Random Bars, Checkerboard, Box, Venetian Blinds, Dissolve, and Split Vertically. Having a shorter list to look through, which hopefully would automatically set the most popular variant by default, will make it easier and faster to complete this task.
https://gerrit.libreoffice.org/#/c/19648/ has a small change to the transition list (makes it sorted). Not a huge improvement, and actually I am not even sure if it is worth it (read commit comment). (But was trivial, code-wise.) Reviews welcome.
Re: comment #1: Unfortunately the type/subtype classification that exists in the code is not usable directly as basis for hierarchy in the UI, as for the (in theory optional) OpenGL transitions that were added in 2007 or so, we use an arbitrary mapping of invalid type-subtype pairs to transition types. Nominally most of these "new" transitions are of type "misc shape wipe" even if they have nothing to do with a shape wipe... with subtypes like "left to right", "top to bottom" etc that also have no relation to how the transitions actually look. (That these "new" transitions are implemented using OpenGL is an implementation detail which of course should not affect how they show up in the UI at all. Why they are "optional" is not entirely clear to me.)
I think this report is very similar to this: https://bugs.documentfoundation.org/show_bug.cgi?id=36946 Duplicate? The idea seems good, there are several transitions and its variants. Viewing on two lists greatly improve usability and time to search for a particular transition. Cheers
(In reply to Tor Lillqvist from comment #4) > https://gerrit.libreoffice.org/#/c/19648/ has a small change to the > transition list (makes it sorted). Not a huge improvement, and actually I am > not even sure if it is worth it (read commit comment). (But was trivial, > code-wise.) Reviews welcome. I believe your patch is related to bug 87613, which is about sorting and grouping the transition list, while this list is to remove variants from the transition list and place them in a separate list, so all entries in the transition list are unique transition types. This is similar to how we have a separate drop down list for transition speed. (In reply to Bastián Díaz from comment #6) > I think this report is very similar to this: > https://bugs.documentfoundation.org/show_bug.cgi?id=36946 > > Duplicate? Bug 87613 is partially a duplicate of bug 36946.
(In reply to Yousuf (Jay) Philips from comment #7) > (In reply to Bastián Díaz from comment #6) > > I think this report is very similar to this: > > https://bugs.documentfoundation.org/show_bug.cgi?id=36946 > > > > Duplicate? > > Bug 87613 is partially a duplicate of bug 36946. OK. I think there are several related reports. I have tracked for this feature long ago. Do you think necessary to create a meta-bug?. So designers can choose the best alternative to reorganize the selection of transitions (alphabetical, by variants, categories, etc.). Thanks
(In reply to Bastián Díaz from comment #8) > OK. I think there are several related reports. I have tracked for this > feature long ago. They have all been linked together with See Also. :D > Do you think necessary to create a meta-bug?. So designers can choose the > best alternative to reorganize the selection of transitions (alphabetical, > by variants, categories, etc.). Meta bugs are useful when you have a large number of related bugs, else See Also is more than sufficient to link related bugs together.
So Tor fixed this now. https://gerrit.libreoffice.org/19797
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]