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".
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
> @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.
(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)?
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.
@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.
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 ;-)
*** Bug 50817 has been marked as a duplicate of this bug. ***
Created attachment 63281 [details] Sample Document
That was a feature: http://cgit.freedesktop.org/libreoffice/core/commit/?id=4866b20ec6205b04cd21077fd00d68c4d4bb2c1b Kendy?
Confirmed on Debian Lenny x86, changing platform accordingly. Quite annoying behaviour.
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.
(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