GNOME Bugzilla – Bug 338390
Rework the fullscreen popup's UI
Last modified: 2010-11-14 15:42:12 UTC
Please describe the problem: When beeing in Fullscreen, there are problems with the scale adjustments. But I don't know if this is only in the german translation version. Hard to explain for a non native speaker ^^ Steps to reproduce: 1. Go fullscreen 2. Now click on the scale thing and hold down the mouse 3. Now you can see, that the scalebar is smaller now than before. This is because of the "jump to" text, wich appears next to it. Actual results: Expected results: The scale should always stay the same size. Because, if you are new the end of a film, and then click on the scale widget, the scale widget gets smaller, and your mouse sets the scale on the end of the film Does this happen every time? yes Other information: If you don't know what I mean, then please ask. I can make pictures to explain it.
Yeah, I don't understand... What is this scale widget you're talking of? There shouldn't be any scaling when in fullscreen AFAIK....
Created attachment 63413 [details] 1st picture
Created attachment 63415 [details] 2. picture This is the bar, that appears when moving the mouse in fullscreen. You see the problem? If you now thing "that is no real problem", then try it out: Try to move the movie to a special position near the end with this scale.
*** Bug 339753 has been marked as a duplicate of this bug. ***
Created attachment 70342 [details] [review] Small fix I found this bug annoying, hence I have done a quick patch Personnal comment: would it be nice to have a layout with more ratios/constraints of widgets ? The time slider might have a fixed size too to solve the quirks when a label change.
The fullscreen toolbar is an absolute pain layout-wise. I've tried many times to make it smoother but failed each time. Other takers welcome.
*** Bug 350648 has been marked as a duplicate of this bug. ***
*** Bug 349402 has been marked as a duplicate of this bug. ***
*** Bug 353271 has been marked as a duplicate of this bug. ***
*** Bug 393590 has been marked as a duplicate of this bug. ***
Variant 1: -------------------------------------------- | | Leave Fullscreen | | -------------------- | | | | | | | | | | | | | | | | | | | | -------------------------------------------- | < || > Time: [---------] Volume [----] | -------------------------------------------- | 0:00 / 1:10:20 | -------------------------------------------- Variant 2: In case we would use a monospace font for the time and save enough space the scroller should not bump.
(In reply to comment #11) > Variant 1: <snip> > Variant 2: > In case we would use a monospace font for the time and save enough > space the scroller should not bump. It's not so much how it could look, but how will it look/how will it be implemented. Ie. No mockups allowed, only glade patches :) (Actually, mockups allowed if somebody is interested in working on a cairo-based/compositing-fu popup, see bug 397824)
*** Bug 445178 has been marked as a duplicate of this bug. ***
*** Bug 458495 has been marked as a duplicate of this bug. ***
Created attachment 95316 [details] [review] OneLiner: set fixed size for time label in fullscreen mode (25 char) 25 chars is open for discussion - but strings like "99:59:59 / 99:59:59" can already get 19 chars long - so 25 should be min. for most languages - and still be okay in normal situations...
*** Bug 518776 has been marked as a duplicate of this bug. ***
Bastien marked my bug as duplicate but this bug is about clutter and little space for progress slider, while I proposed NEW fullscreen overlay [ie. clutter-libs based].
(In reply to comment #17) > Bastien marked my bug as duplicate but this bug is about clutter and little > space for progress slider, while I proposed NEW fullscreen overlay [ie. > clutter-libs based]. This bug is actually about a whole new UI.
O rly? > there are problems with the scale adjustments
is it possible to make totem use clutter fullscreen through a plugin? rather than adding that dependency for everyone
I believe this BUG has already been fixed. I am using Totem 2.22.1 in Ubuntu Hardy, and clicking and dragging the POSITION BAR (called by the submitter as SCALE) does not make this bar smaller anymore, as it used to happen in previous versions. Please, confirm this and mark the bug as FIXED. Steps to confirm: 1. Open any movie in Totem 2.22.1 or later. 2. Enter fullscreen mode by pressing 'F' 3. Click on the slider in the POSITION BAR to advance/rewind the movie and check if this bar resizes. It shouldn't.
Indeed, was already fixed as part of bug 469413 (in 2.21.0, and probably some 2.20.x update). 2007-08-25 Bastien Nocera <hadess@hadess.net> * src/totem-menu.c: (skip_forward_action_callback), (skip_backwards_action_callback): * src/totem.c: (totem_seek_time_rel), (totem_action_seek_relative), (totem_action_seek_time), (totem_action_remote), (totem_action_handle_key_release), (totem_action_handle_seek), (totem_action_handle_key_press), (totem_action_handle_scroll): * src/totem.h: Clean up the seek to time functions, and don't set the statusbar or the full screen label as seeking when there's no MRL loaded (Closes: #469413)
Sorry, I can't confirm that this bug is fixed, the position bar still gets smaller when seeking with the slider because the text "Seek to" or "Zu ... springen" appears. I tried Totem from trunk as well as 2.24.2 and both in German and English.
(In reply to comment #23) > Sorry, I can't confirm that this bug is fixed, the position bar still gets > smaller when seeking with the slider because the text "Seek to" or "Zu ... > springen" appears. I tried Totem from trunk as well as 2.24.2 and both in > German and English. Indeed. I mistakenly tested this in a patched version that removed the "Seek to" text. It was my bad and I really apologize for the error. I just tried 2.24 and the bug is still there. When the text "Seek to" appears, it does resize the POSITION BAR. Please, reopen the bug. Thank you Robin.
This is the best we can do without changing the layout of the fullscreen popups. Fixed in gnome-2-24 and trunk 2008-10-22 Bastien Nocera <hadess@hadess.net> * src/totem.c (seek_slider_pressed_cb): Don't show seeking to label when we can direct seek (Closes: #338390)
*** Bug 634797 has been marked as a duplicate of this bug. ***
is it necessary to show 'seek'? wouldn't the after effect of scrolling itself tell the user what happened?
(In reply to comment #27) > is it necessary to show 'seek'? wouldn't the after effect of scrolling itself > tell the user what happened? I believe it's necessary to give the user feedback that their seek operation is happening. It's only shown for streams where Totem can't do a direct seek (i.e. it may take an unbounded amount of time for the seek to complete).
> It's only shown for streams where Totem can't do a direct seek (i.e. > it may take an unbounded amount of time for the seek to complete). I see it with every audio/video file