GNOME Bugzilla – Bug 617905
Get rid of status bar
Last modified: 2016-11-12 12:29:13 UTC
Created attachment 160442 [details] Hylke's mockup Removing the status bar would mean: - moving the buffering display to the main video canvas (as the video will be paused when buffering anyway) - moving the time text to the main chrome, near the time slider - make the sidebar button smaller and use an icon
I like the mockup. Some comments: Maybe we could also use the GtkInfoBar for the buffering message. We will also lose the menu entry help which is also displayed in the status bar. But I won't miss it as the help is not much more than the menu entry in a sentence form. And I would guess most users don't even notice it, as the focus is on the menu when browsing through the entries.
(In reply to comment #1) > I like the mockup. Some comments: > > Maybe we could also use the GtkInfoBar for the buffering message. Urgh, no. Buffering can happen quite a lot for live streams, and you'd see the window resize when that happens. We need feedback in a part of the UI that wouldn't "move". The added benefit of using the video canvas is that it would also work in fullscreen, or when controls are hidden. > We will also lose the menu entry help which is also displayed in the status > bar. But I won't miss it as the help is not much more than the menu entry in a > sentence form. And I would guess most users don't even notice it, as the focus > is on the menu when browsing through the entries. Right, and there's nothing stopping the menus from hiding the part of the status bar where the text is.
(In reply to comment #0) > Created an attachment (id=160442) [details] > Hylke's mockup > > Removing the status bar would mean: > - moving the buffering display to the main video canvas (as the video will be > paused when buffering anyway) Planning on showing how much is buffered anywhere?
We can show that in the spinner. We could using something like the default spinner when doing download buffering (because the progress is already shown in the time slider), and show a circle filling itself up for cases where percentages are used (eg. for streams).
(In reply to comment #4) > We can show that in the spinner. We could using something like the default > spinner when doing download buffering (because the progress is already shown in > the time slider), and show a circle filling itself up for cases where > percentages are used (eg. for streams). Yea, a spinner would be nicer than just text. We can sho the percentage under it.
I like the mockup, too. One idea for the buffer indicator. Since I really appreciate the current progress bar buffer fill indicator that only appears when buffer is low or refilling when I watch arte.tv, may I suggest that you replace the timecode under the seekbar with the progress bar fill level whenever it is necessary? Overlaying a »Buffering ...« onto the video has really strong negative associations with the olden RealPlayer[1,2]. And besides, it invades the video, which users generally dislike (cf. Youtube annotations). [1] http://www.urbandictionary.com/define.php?term=realplayer [2] http://euroross.blogspot.com/real-buffering.jpg
(In reply to comment #6) > I like the mockup, too. > > One idea for the buffer indicator. Since I really appreciate the current > progress bar buffer fill indicator that only appears when buffer is low or > refilling when I watch arte.tv, may I suggest that you replace the timecode > under the seekbar with the progress bar fill level whenever it is necessary? > > Overlaying a »Buffering ...« onto the video has really strong negative > associations with the olden RealPlayer[1,2]. And besides, it invades the video, > which users generally dislike (cf. Youtube annotations). You are right, let's do that instead :) Most people won't know what "Buffering" means anyway
(In reply to comment #6) > I like the mockup, too. > > One idea for the buffer indicator. Since I really appreciate the current > progress bar buffer fill indicator that only appears when buffer is low or > refilling when I watch arte.tv, may I suggest that you replace the timecode > under the seekbar with the progress bar fill level whenever it is necessary? We already do that. But this will only ever work for streams that have a finite length, and if we support download buffering for that type of file. That won't work for a live stream (say, from icecast/shoutcast). > Overlaying a »Buffering ...« onto the video has really strong negative > associations with the olden RealPlayer[1,2]. And besides, it invades the video, > which users generally dislike (cf. Youtube annotations). We could always use an "on the video" status bar, a-la Chrome/Chromium, though the original problem of drawing on top of an xvimagesink stays.
Created attachment 164172 [details] mock: move buffering note to below seekbar Bastien, I think you mean the color indicating buffer in the actual trough of the seekbar? I mean the other, older buffer indicator that looks like a progress bar inside the status bar. See attachment. (Sorry for the sloppy mockup job.)
(In reply to comment #9) > Created an attachment (id=164172) [details] > mock: move buffering note to below seekbar > > Bastien, I think you mean the color indicating buffer in the actual trough of > the seekbar? I mean the other, older buffer indicator that looks like a > progress bar inside the status bar. No, I mean the "hover over links" "statusbar". Which is also what Epiphany does nowadays.
No, did you mean this > http://www.hadess.net/2009/11/notice-anything.html with this: > We already do that. But this will only ever work for streams that have a finite > length, and if we support download buffering for that type of file. That won't > work for a live stream (say, from icecast/shoutcast). I meant that other thing (that appears for underrun live streams too).
(In reply to comment #11) > No, did you mean this > > > http://www.hadess.net/2009/11/notice-anything.html > > with this: > > > We already do that. But this will only ever work for streams that have a finite > > length, and if we support download buffering for that type of file. That won't > > work for a live stream (say, from icecast/shoutcast). > > I meant that other thing (that appears for underrun live streams too). I think we're getting a bit confused. We already use the through on the seekbar for non-live streams when GStreamer supports it. We would only show a statusbar (the same one that chrome and epiphany use now, on top of the video canvas) for live streams, or ones with a finite length that GStreamer does not support.
(In reply to comment #12) > I think we're getting a bit confused. True. Sorry for introducing noise. > We already use the through on the seekbar for non-live streams when GStreamer > supports it. We would only show a statusbar (the same one that chrome and > epiphany use now, on top of the video canvas) for live streams, or ones with a > finite length that GStreamer does not support. Your proposal of an overlaid (let’s call it) banner came after my suggestion to display the buffer fill level as a progress bar – when needed – below the seekbar (not under or in it; my attachment shows what I mean). Your way works too (minus the compositing issues) and I just wanted to point out, and there seems to be agreement, that an indication of buffer fill/ETA is good user feedback as opposed to just »buffering ...« or a spinner. And putting it where it would not pop-in-and-out over the video would be less unsettling.
exhibit b: http://i.imgur.com/RGviR.png
Is there a way to do this where the time slider is vertically aligned with the center of the buttons? I think that would be much prettier. Could we, for example, display the time text in a tooltip and have the buffering display replace the time slider while buffering?
The status bar is gone in master.