Bug 151343 - Inconvenient to drag an animation effect to the end of the list
Summary: Inconvenient to drag an animation effect to the end of the list
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Sidebar-Animation
  Show dependency treegraph
 
Reported: 2022-10-04 15:59 UTC by Eyal Rozenberg
Modified: 2022-10-10 16:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast (47.66 KB, image/gif)
2022-10-10 09:10 UTC, Heiko Tietze
Details
Screencast with GTK3 (60.88 KB, video/mp4)
2022-10-10 09:21 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-10-04 15:59:33 UTC
Suppose you have a list of multiple animation effects for a slide, which exceeds the height of the effects list display.

In this case, when you click one effect, keep the mouse clicked, and drag - you will se an indicator of where your effect will moved: A line between the two effects between which it will be placed. However, if you try to move the effect to the end of the list, and you use gtk3, the effect will "hover" while dragged, hiding the bottom of the list, and you'll have a hard time seeing what's going on. 

Additionally, the marking line is much thinner and less pronounced than with kf5, and this easier to miss.
Comment 1 Telesto 2022-10-06 13:02:48 UTC
(In reply to Eyal Rozenberg from comment #0)
> Suppose you have a list of multiple animation effects for a slide, which
> exceeds the height of the effects list display.
> 
> In this case, when you click one effect, keep the mouse clicked, and drag -
> you will se an indicator of where your effect will moved: A line between the
> two effects between which it will be placed. However, if you try to move the
> effect to the end of the list, and you use gtk3, the effect will "hover"
> while dragged, hiding the bottom of the list, and you'll have a hard time
> seeing what's going on. 

I can't confirm this exact bug. However drag & drop for top or bottom of the list is very bad, on Windows too. Not sure if equals GTK3.. 

> Additionally, the marking line is much thinner and less pronounced than with
> kf5, and this easier to miss.

The marking is so, so. I personally would mimic the behaviour of the slide panel  for sorting slides.
Comment 2 Eyal Rozenberg 2022-10-07 09:32:15 UTC
(In reply to Telesto from comment #1)
> I personally would mimic the behaviour of the slide
> panel  for sorting slides.

That would be nice, since the slide side-panel  moves existing items up and paints a slide placeholder below the last one. A much easier experience dragging.
Comment 3 Heiko Tietze 2022-10-10 09:10:51 UTC
Created attachment 182933 [details]
Screencast

Not sure what you mean with hover. The fact that this horizontal line is not showing for the very last item?
Comment 4 Eyal Rozenberg 2022-10-10 09:21:47 UTC
Created attachment 182934 [details]
Screencast with GTK3

(In reply to Heiko Tietze from comment #3)
> Created attachment 182933 [details]
> Not sure what you mean with hover. The fact that this horizontal line is not
> showing for the very last item?

Your screencast corresponds to what we see with kf5. With gtk3, I see a  rectangle, a "piece" of the list, hover above the list. And it sometimes covers the entire bottom of the list so you can't see a horizontal line whether it's showing or not.
Comment 5 Heiko Tietze 2022-10-10 09:33:45 UTC
Caolan, what do you think? If this is Gtk default behavior how about a semi-transparent background?
Comment 6 Caolán McNamara 2022-10-10 16:28:48 UTC
This is the built-in gtk behavior, we don't create this icon shown during drag.

It is sort of theoretically possible to set a replacement icon there, and also to use the same rendered image but make it semi-transparent instead. In practice however this is presumably a very unused code path and my efforts to set the hotspot to make it place right seems to be basically impossible once the original icon was created (esp under wayland)