Bug 87621 - SIDEBAR: Break slide transitions into two listboxes - name and variant
Summary: SIDEBAR: Break slide transitions into two listboxes - name and variant
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval, topicUI
Depends on:
Blocks: Sidebar-Slide-Transition
  Show dependency treegraph
 
Reported: 2014-12-23 00:13 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-10-24 12:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
how the variants are separated in other suites (96.17 KB, image/png)
2014-12-30 12:41 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-12-23 00:13:58 UTC
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.
Comment 1 V Stuart Foote 2014-12-23 20:39:15 UTC
@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.
Comment 2 Heiko Tietze 2014-12-30 10:01:09 UTC
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.
Comment 3 Yousuf Philips (jay) (retired) 2014-12-30 12:41:19 UTC
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.
Comment 4 Tor Lillqvist 2015-10-28 15:47:00 UTC
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.
Comment 5 Tor Lillqvist 2015-10-28 15:55:46 UTC
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.)
Comment 6 Bastián Díaz 2015-10-28 23:03:01 UTC
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
Comment 7 Yousuf Philips (jay) (retired) 2015-10-31 01:03:51 UTC
(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.
Comment 8 Bastián Díaz 2015-10-31 03:28:53 UTC
(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
Comment 9 Yousuf Philips (jay) (retired) 2015-10-31 05:07:24 UTC
(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.
Comment 10 Yousuf Philips (jay) (retired) 2015-11-24 13:55:34 UTC
So Tor fixed this now. https://gerrit.libreoffice.org/19797
Comment 11 Robinson Tryon (qubit) 2015-12-16 05:30:50 UTC Comment hidden (obsolete)