Bug Hunting Session
Bug 51231 - UI: Slide thumbnail overlay "start presentation, disable slide, copy slide" position depends on slides pane scroll slider position and mouse way
Summary: UI: Slide thumbnail overlay "start presentation, disable slide, copy slide" p...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:3.6.1 target:3.7.0
Keywords:
: 50817 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-06-19 05:16 UTC by daniel.schaaaf
Modified: 2013-01-03 22:50 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Describes buggy behaviour of slide thumbnail overlay (264.10 KB, application/vnd.oasis.opendocument.text)
2012-06-19 05:16 UTC, daniel.schaaaf
Details
Sample Document (11.04 KB, application/vnd.oasis.opendocument.presentation)
2012-06-20 22:29 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description daniel.schaaaf 2012-06-19 05:16:10 UTC
Created attachment 63225 [details]
Describes buggy behaviour of slide thumbnail overlay

The slide thumbnail overlay "start presentation, disable slide, copy slide", that gets blended in when the mouse cursor was being moved over a slide thumbnail, interferes with the user's work flow.

The bug(s) is explained easily in the attached file, which might be more comprehensible than the following description.

Apparently the position of the overlay depends on the point of entry of the mouse cursor onto the slide thumbnail. When the cursor is being moved onto a thumbnail from the bottom, the overlay will appear in the upper part of the thumbnail. But when the user rests the cursor in that upper part and clicks to activate/edit that slide, an unexpected action is carried out because the user will click on one of the commands of the overlay instead!
The position of the overlay should depend on the position of the mouse cursor, and not on the point of entry onto the slide thumbnail.
Furthermore, there is a bug with the overlay position. When the the thumbnail view is scrolled down a little, the overlay always appears in the upper part of a thumbnail, independently of the point of entry.

And as usual, this should be optional! The user should be able to enable/disable the overlay from a context menu of any slide thumbnail and in an "advanced" menu in the options window.
From a design point of view, the way the overlay blends in soothes the eye, but this can be annoying when a "special effect" takes to long to "do its thing".
Comment 1 Rainer Bielefeld Retired 2012-06-19 06:11:08 UTC
Second part of report (Overlay Position) [Reproducible] with Master " 3.7.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 1d1c70d]" (tinderbox: W2008R2@20, pull time 2012-06-18 08:23:14).

Limiting Bug report to this cofirmed observation.

Overlay only appears at bottom of the thumbnail (as I have been used to see it) as long as the slides pane scroll slider is at the top position. If it's only a very little bit down overlay will appear at the top of the thumbnails of all slides (except most top one.

Same effect in Outline View

Already [Reproducible] 
with Server installation of Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 7175cee]" (tinderbox: Win-x86@6-fast, pull time 2012-05-16 22:07:37), so Master bug,

Works fine with:
[Reproducible] with Server installation of  Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 475d0c5-829fc92-39746e8-206648e-fefd87]" (2012-02-14)
and older

@daniel.mania@umb.no
I can't reproduce your very sophisticated explication, for me it's simply related to scroll slider position. 

Can you confirm effect for Outline View?

What Operating System did you use?

If this Bug report does not represent all your buggy observations please submit an additional. Please write your observations with clear short sentences similar to example in Bug 43431
Comment 2 daniel.schaaaf 2012-06-20 02:31:41 UTC
> @daniel.mania@umb.no
> I can't reproduce your very sophisticated explication, for me it's simply
> related to scroll slider position. 

Maybe I should bring this up in [Libreoffice-ux-advise]? The issue is that I get unexpected results from my work flow.
Usually I do not position the mouse cursor precisely because I would have to divert my attention towards that process fully. A thumbnail has a big surface area and interaction should be correspondingly easy. But since the overlay position solely depends on the point of entry, I have to pay attention to where I stop the mouse movement to not click on the overlay accidentally because I expect to click on the thumbnail.

OK, here are simple instructions:

1) Move mouse cursor onto slide thumbnail from (outside) bottom of thumbnail
2) Stop cursor in upper part of thumbnail

What I (=user) expect:
   Overlay appears at bottom and mouse click will activate the slide for editing.

What actually happens:
   Overlay appears at top of thumbnail and mouse click executes one of its three commands.
This forces the user to focus on the thumbnail to aim at a part without overlay in order to not get unexpected results (e.g. disabling a slide instead of activating it for editing). Since the overlay blends in after some time, the user is also forced to wait that time before clicking anywhere.

I agree, this is probably not a bug but a "not that optimal" approach to blend in the overlay.
Comment 3 Rainer Bielefeld Retired 2012-06-20 02:50:35 UTC
(In reply to comment #2)
I can't imagine what of your problem remains when this bug here will have been fixed.

BTW: I believe you wanted to say: 
"Problem if place of appearance is not reliable: When I use thumbnails to select sheets, I might accidentally click the overlay instead of thumbnail itself" (what is some shorter than Comment 2)?
Comment 4 daniel.schaaaf 2012-06-20 03:30:41 UTC
Sorry, my mind is somewhere else these days.

> "Problem if place of appearance is not reliable: When I use thumbnails to
> select sheets, I might accidentally click the overlay instead of thumbnail
> itself"

Yes, that is what I meant! :-)
But I would stretch it a little to "... appearance is not reliable/expected ..."

1) As you said, "not reliable" is connected to a real bug when the slides pane scroll slider is not at the top position.

2) With "not as expected" I mean to say that the overlay can appear under the mouse cursor because its positioning does not rely on the cursor position but the point of entry.


Again, I am sorry for this lengthy report. It should have been more precise to not waste anyone's time.
Comment 5 Rainer Bielefeld Retired 2012-06-20 03:38:40 UTC
@rodo:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf.
Comment 6 Rainer Bielefeld Retired 2012-06-20 21:59:20 UTC
More research in "Bug 50817 - Thumbnail overlay to start presentation, disable slide or duplicate it is in wrong position"  with parallel installation of Master "LOdev " 3.7.0.0.alpha0+   - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8d39b7]" (tinderbox: W2008R2@16-minimal_build, pull time 2012-06-20 04:38:46) showed an additional aspect of this bug. 

Result of following tests: "Place of appearance of overlay depends on scroll slider position AND from where mouse pointer reaches thumbnail".

That makes place of appearance more or less "unpredictable"

Steps to reproduce:
1. Download / Open attached sample presentation. Not full size window, so that
   left LibO window margin is some cm away from lef monitor margin will ease
   tests
2. if necessary, make visible 'Slides Pane' (similar to view in 
   attached "Describes buggy behavior of slide thumbnail overlay" 
   so that several thumbnails will be visible, Slide Pane is docked at the left 
   and it's width includes width of 3 Menu bar items "File - Edit - View"
3. Move Scroll slider down so that top half of top thumbnail disappears
4. Now we can test influence of mouse pointer way
5. Start mouse pointer at Menu Item view and move down slowly (10 seconds from
     one thumbnail center to the next.)
   Overlay appearance: 
   "Slide 1 Thumbnail"  at the bottom of Thumbnail after Mouse pointer has left
           Thumbnail area
   All further slides at the *top* of the Thumbnail a short moment after 
           Mouse Pointer has reached Thumbnail area
6. At center of last but one thumbnail return and move mouse pointer slowly 
   upwards. 
   Overlay appearance: For all Thumbnails at the *bottom* 
   
11. With remaining scroll slider position now test concerning mouse pointer 
    comes from the right outside the slide pane and hovers the slide pane 1/5 
    Thumbnail height from top thumbnail margin
    Overlay appearance: For all Thumbnails below mouse pointer 
    As expected results as in 4.1.
12. Now move mouse point from the right outside the slide pane and hover the 
    slide pane 1/5  Thumbnail height from bottom thumbnail margin
    Overlay appearance: For all Thumbnails below mouse pointer, now at the
    *bottom* of the thumbnails

All the same when mouse pointer comes from the right outside the LibO Window.

20. Move Scroll slider to the most top position
21. Redo tests 11, 12:
    Now mouse pointer will not hit overlays, they appear at the opposite end 
   (top or bottom) of the thumbnail


That makes using overlay and thumbnails a lottery ;-)
Comment 7 Rainer Bielefeld Retired 2012-06-20 22:00:42 UTC
*** Bug 50817 has been marked as a duplicate of this bug. ***
Comment 8 Rainer Bielefeld Retired 2012-06-20 22:29:00 UTC
Created attachment 63281 [details]
Sample Document
Comment 9 Ivan Timofeev (retired) 2012-06-22 02:19:41 UTC
That was a feature:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b

Kendy?
Comment 10 Mihkel Tõnnov 2012-06-22 17:13:34 UTC
Confirmed on Debian Lenny x86, changing platform accordingly. Quite annoying behaviour.
Comment 11 Not Assigned 2012-08-02 20:39:56 UTC
Ivan Timofeev committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ee1ee06ec96c6db87203970bf05dd6cd7513f674&g=libreoffice-3-6

fdo#51231 Revert "Slidesorter: Show the buttons on the opposite side..."


It will be available in LibreOffice 3.6.1.
Comment 12 Jean-Baptiste Faure 2012-08-02 21:26:16 UTC
(In reply to comment #11)
> [...]
> fdo#51231 Revert "Slidesorter: Show the buttons on the opposite side..."

It's a pity, I liked this feature. :-(

Best regards. JBF