Created attachment 35653 [details]
mockup

The volume button was taken from Rhythmbox and should work the same way.

Why do you think it's too thick? Do you know that you can hide the controls
altogether?

I just think that simple functionality like changing the volume shouldn't take
that much space on the UI. The way rhythmbox and the Volume Control applet
handle it seems better ie. you click a button and a vertical slider pops up.

Created attachment 45313 [details]
mockup2

Here is my case for a different kind of volume control point by point:

1. The current volume slider takes too much space especially when watching
widescreen movies (ie. it gets insanely long).
2. Volume is something people think of as going up and down, not left and right.
3. Many other GNOME apps (rhytmbox, Muine, Volume Applet) use a volume button
with a popup vertical slider.
4. It's just simply prettier.

Please take a look at the new mockup.

Comment on attachment 45313 [details]
mockup2

I moved the playlist and volume control to the right.

I like the idea of using a button instead of a slider, it's more consistent
w.r.t Rhythmbox, the panel, etc. I think I've talked about this before with
Bastien, and he doesn't like the fact that it needs a click to change volume;
therefore, importantly, does it react on a scroll event? The panel, for example,
does.

I'm not sure whether I like all controls next to each other, it looks a bit busy
(because it's so long) now; especially for small movies. This is better in the
current approach, where the buttons are one row below the time slider.

Unless somebody can come up with a widget that actually allows click and slide
(not click, release, click to slide, release), we can't really use this smaller
widget. I'll also point to a few different media players that have horizontal
volume bars:
http://images.apple.com/quicktime/home/images/qt65propromo121803.gif (Quicktime)
http://images.apple.com/itunes/images/playliststopwin04272004.jpg (iTunes)
http://download.freshmeat.net/screenshots/42116.png (Helix Player)
http://users.skynet.be/maycosplace/ss1.png (Windows Media Player Classic)
http://bugzilla.gnome.org/attachment.cgi?id=34906&action=view (Real Player on
Windows)

I agree that it should be just click and slide. (In Volume Applet and Muine it's
actually even more complicated: click, release, click to slide, release, click
to close.) I think I'll go pester the rhythmbox guys for a widget like that.

The volume applet is different, since it is on the panel, so you cannot randomly
place the widget.

I'll try to work on a widget... I think this is not the first time I've said that.

*** Bug 119775 has been marked as a duplicate of this bug. ***

Created attachment 46087 [details] [review]
something like this

So, this is an attempt to make the volume slider a button in windowed mode. It
stays a slider in fullscreen mode because the popup slider may partially fall
out-of-screen, which is not good [tm], and besides, the space isn't a problem
in fullscreen mode anyway.

In windowed mode, it'll be a button which, when pressed, will popup a slider
window. On quickclick, the slider window will stay up until one clicks outside
the window. On press-and-drag, it will instantly change the volume.

Current problems:
* on quickclick, the volume is changed, which is bad
* there's some warnings on console, don't know why exactly

More:
* I'd like +/- buttons for the quickclick mode
* Of course, after this patch is applied, we still need to re-arrange the
controls so that the control actually becomes smaller. This patch is just a
pre-condition for that.

Created attachment 46090 [details] [review]
new

Changes:
* add +/- buttons

Todo:
* volume is changes on quickclick, which is because the slider is positioned
wrongly (no margins taken into account, trough not subtracted correctly, ...).
This exposes better now that we have +/- icons. I'll look at this next.
* still warnings on console

Oh goodie, more TODO items:
* add copyright headers
* use event->time instead of g_get_current_time()

Created attachment 46091 [details] [review]
update

I think this fixes all of the above, please have a look. I suggest to test this
for a few days to test the "feel" of the whole thing, since it is quite
different from the previous behaviour. If we like it, we'll apply and do the
control area rearranging. If we don't, we'll have to come up with something
else.

Missing include for abs(), missing configure-time require for gnome-icon-theme
>= 2.10.0.

The mockup from comments 1 and 4 wouldn't really be possible, making the time
slider too small.

Created attachment 46158 [details]
mockup3

Removed the time slider label.

I removed the time slider label to alleviate to the time slider too small
problem. (The label isn't really needed if there is only one slider.) Making the
minimum width of the totem window a little bigger would also help.

That's still too small a slider, compared to it taking the full window width.
And frankly, complaining that the controls portion of the window is too thick,
and then asking for a wider window doesn't sound very useful.

Use the space where it says No File for the timeslider instead.
The no file should be obvious from the title of the application, eg Totem:
musicvideo.mpg or just Totem Media player, it is a media player btw :)

Created attachment 46165 [details]
mockup

What about smth like this

I like the volume slider as it is. The only thing I would change is its size,
mainly with widescreen movies, making it fixed.
A mockup and a small patch are provided.

Created attachment 46166 [details]
fixed volume slider mockup

Created attachment 46167 [details] [review]
fixed volume slider patch

Created attachment 46172 [details] [review]
right aligned fixed volume slider patch

I dislike the slider for various reasons:
* it's large compared to other parts of the interface, especially given its
function (imo, important parts should be large and unimportant parts small)
* other GNOME apps use a button + icon (e.g. RB, panel-volume-applet)

Bastien's main concern about the button was the press-drag-release behaviour,
which my widget allows. Are there other reasons why we would prefer a slider
over a button? Current problems I see:
* sometimes the popup slider falls partly off the screen, e.g. if your Totem
window is right at above the bottom panel.
* the popup isn't placed aligned above the top of the button or below the bottom
of the button, but on top of the button, which may be slightly ugly

Given this list, I'd still prefer the button, though... I like the behaviour,
but that's probably partly because I coded it. ;).

Bastien, I don't want the window to be wider. That was just in reply to your
comment about the slider being too short. I'm fine with a shorter slider,
especially since it's only going to be short when watching small movies. As for
the fixed width volume slider, the problem with it is that it creates a big
empty space on the UI that is essentially wasted space.

I'm testing Ronald's new volume widget and the only thing I dislike is the fact
that it is a button and buttons are made to be clicked. Every other volume
button in major gnome media players (Rhythmbox, Muine...) are really buttons,
and when clicked show a volume slider at the bottom of the button (or at the
top, in case of not enough space). Ronald's volume button instead, if clicked,
displays a slider, altering a bit the volume, which stays there untill you click
something else. There is no way to know you have to press the button, make it
pressed, drag the volume slider and release it. It is really a great volume
widget, I think this is the correct way, but the starting point, imho, shouldn't
be a button, but something else. *blink* It could be a very nice enhancement for
panel-volume-applet *blink*.

As for the button, yes, you're right. I don't know which widget would be more
appropriate, though. I'm open for suggestions. Anything specific you were
thinking of?

The volume panel applet doesn't need the click-and-slide behaviour, and
particularly suffers from the fact that part would be displayed off-screen. If
we can fix that, I'll happily use it there, too, but for now, that disadvantage
is too large because it is always at the border of the screen...

Created attachment 46195 [details] [review]
flat totem volume button

No, I don't know which widget could be used. Maybe a flat button, but i'm not
really sure. Attached one-line-patch, so other people can try that too.

For the panel-volume-applet, you are right, the slider is mouse cursor aligned,
so half of it will be off-screen :(

The widget still has a bug: if you pop it up using a quickclick, and then click
outside the window, it does not disappear. apparently, the grab/ungrab cycles
still don't hold all grabs...

I'm late as always but I just wanted to take a step back and look at the big
picture of this bug.

The title says "Control area is too thick", which if it's a real problem could
be improved by squishing items or removing items.  I'm not doubting that this is
a real problem, but too thick is pretty subjective without hard evidence. 
Comment #5 seems to be the last discussion on whether this is a real problem or
not, after that we jump right into doing it.  So here's my responses:

> 1. The current volume slider takes too much space especially when watching
>   widescreen movies (ie. it gets insanely long).

This can be changed, I'm sure this can be fixed to no longer expand beyond a max
size.

> 2. Volume is something people think of as going up and down, not left and 
> right.

Yeah, but not a big deal with some visualization.  Otherwise you could argue
that people could never understand a volume knob, which they do.

> 3. Many other GNOME apps (rhytmbox, Muine, Volume Applet) use a volume button
> with a popup vertical slider.

Having a similar interface for these could be a good thing.

> 4. It's just simply prettier.

Right... This is kind of subject and the old volume control could get some
prettying up.

The new widget looks cool, I'd just like to understand the need for creating a
new interface which performs the same operation as the old, but isn't the old. 
Cheers.

Bryan, all this is definitely subjective and mainly an aesthetic matter, so I'm
not sure what the "hard evidence" you are looking for could be, but here is one
small tidbit of information: let's assume we have a movie file with the
dimensions 640 x 360 (aspect ratio 16:9). Opening it in Totem would create a
window with the dimensions 642 x 502 (using size 10 font and excluding window
manager stuff). From the equation ((642 x 502 - 640 x 360) / (642 x 502)) x 100
= 28,5 % we see that with that particular file the controls would take 28,5 per
cent of the window area. (Someone please check my math.) I don't know about you,
but I think that's a lot and to me it would seem like a good idea to make the
controls as unobtrusive (yet immediately accessible) as possible and put the
content center stage. This is the closest to hard evidence I can think of, but
like I said this is mainly an aesthetic matter and opinions are bound to vary.

Ok I'll try to be clearer.  Percentage size of the interface is a tough metric
to use for Totem since if you have a large movie you could end up with a small
percentage and a small movie could mean a huge percentage of the window.  What I
was looking for was beyond aesthetics for now.

Something like the following:  With the controls the way they are, is it
difficult for you to change the volume at certain sizes?  Is there a specific
size where it is most difficult change the volume?  A size where it's easiest?

I'm looking for anything beyond aesthetic nature of this first, then I can just
defer to someone else... Does this look better than that? :-)

Yeah, you can't really compare the size of the interface to anything, but it
does matter to people with small screens.

I guess one usability issue with a very long volume slider is that minimizing
and maximizing the volume requires long mouse movements. People with slow mouse
acceleration need to go back and forth to avoid the mouse falling off the mouse
pad or they finger hitting the trackpad edge. (But this is pretty much an ad hoc
explanation and not the actual reason I filed this bug.)

Bryan, this probably doesn't help at all, but as far as I'm concerned, this is
about aesthetics and consistency (with other GNOME apps)... I don't see any huge
usability issues with the current slider, really.

Created attachment 49001 [details] [review]
bladiebla

Changes:
* Update against CVS
* Thanks to the help of Kristian Rietveld, hiding of the dock now works as it
should
* as a test, I made the thing relief-none, which looks a bit weird, but maybe
it's cool
* remove tmw_title_label, takes space and the window title is set anyway

Anyway, this thing can be tested properly now. Let's see what you guys think.

Screenshots:
http://ronald.bitfreak.net/priv/totem-base.png (base layout)
http://ronald.bitfreak.net/priv/totem-volume.png (volume dock popped up)

Thanks Ronald, it is starting to look really nice. However, I still think it
would be better if all the buttons (Previous, Play/Pause, Next, Volume and
Sidebar) were the same shape and size and all the controls were lined up
horizontally. Now there is even the added bonus of looking very similar to Sound
Juicer and I think having similar user interfaces for the various media players
would be a Good Thing.

Created attachment 49005 [details]
mockup4

An updated mockup. I used the old playlist icon for the Sidebar button because
the new > icon would look confusingly similar to the Play button on its own.

Teppo, you'll need to update your CVS, there's no playlist button anymore.

Actually, I'd argue that important buttons, so the playlist and play/pause ones,
should be larger. We have some free space to play with now, I'd like to use this
space. At least the play/pause buttons should get a label, since they will be
used most often. I don't care much for all buttons being square or the same size.

Also, the time slider really will stay on top, Bastien has already argued that.
Only for large movies is it really interesting to place the time slider between
the buttons, for all other cases, it becomes too small.

I just meant that the current Sidebar button (with the > icon) looks confusingly
similar to the Play button, but its not a big deal.

I don't agree about the time slider becoming too small. I think it would still
be accurate enough for normal seeking (except maybe in rare cases where the user
is watching a really long movie that has really small dimensions but even then
the user would probably resize the window to 2:1 and get a bigger slider).

For me the whole point of changing the volume slider to a button was to be able
to place all the playback controls on line horizontally like most GNOME media
players do and get a nice and tight controls area. If that is not going to
happen, I actually prefer having a big volume slider instead of a big empty space.

Bastien and me have agreed on committing this patch to totem and the mozilla
plugin. So the controls area is somewhat smaller now, but not as small as it
could be.

Now, we could do a few things:
* leave it as is and close bug
* have seek slider above the buttons for small movies and in between buttons for
"wide" movies (or, well, window size)

Either way, I think we should add a "play" and "pause" label to the play button,
since often-used buttons should be larger according to the HIG, IIRC...

> * have seek slider above the buttons for small movies and in between buttons for
> "wide" movies (or, well, window size)

I could definitely live with that. 

If you are going to add a label to the Play button, please consider changing the
button order to Play, Previous, Next like Muine has. I think that would look
better and then the Play button would be at the exact same location in both
Totem and Sound Juicer which would be great for consistency.

Different interfaces depending on the length of the stream? Arf. No way.
Apart from the Play/Pause button changes, there's nothing else to be done.

Not depending on the length of the stream, just the width of the window. And it
wouldn't be a different interface, the time slider would just fall into place if
the width of the window is changed.

<hadess> BBB: if you implement the "slider moves depending on the width of the
window", you're officially not allowed to commit to totem anymore ;)
<hadess> if you follow this, your rights are soooo revoked ;)

I guess I won't be doing this anytime soon. :). Mumble-mumble about benevolent
dictators and such. :).

OK, you can close this now. I can always twiddle with the glade file myself.

I haven't checked latest cvs version yet, but from a screenshot posted by Ronald
with the new volume widget (btw, I like it :) it can be seen that there is a
vertical separator next to 'next track' button, which should be no more neeeded,
since there isn't any widget to separate from on the right.

Created attachment 50270 [details] [review]
totem.glade patch for the play button

Move the play button before the |< and |>, and give it a label.

Created attachment 50271 [details]
screenshot

Looks like what we had 3 years ago :)
http://www.hadess.net/files/shots/10-06-2002.1.jpg

Hi Michaël, I think the button should read "Play" when not playing and "Pause"
when playing like Sound Juicer does.

So, are we applying Michael's patch after the 2.12 branch? I like the current
interface...

No, the label should correspond to what the icon says.

I have been looking into this, and it seems a easy one, but there is one
problem, because of some dark reason, calling gtk_button_set_label removes the
image (tmw_play_pause_button_image), because the next time it is accessed, i get a

(lt-totem:11617): Gtk-CRITICAL **: gtk_image_set_from_stock: assertion
`GTK_IS_IMAGE (image)' failed

message, also there is no image on the button...

gtk_button_set_label() removes and dereferences any current contents and adds a
label. If you want to keep them alive, keep a reference before adding them to
the button (using g_object_ref (image)).

gtk_button_set_label (button, GTK_STOCK_MEDIA_PAUSE);
gtk_button_set_label (button, GTK_STOCK_MEDIA_PLAY);

should make your life easier...

Hmm, it still doesn't work, and google doesn't give me any usefull information...

It's this part:

	image = glade_xml_get_widget (totem->xml,
			"tmw_play_pause_button_image");
	button = glade_xml_get_widget (totem->xml, "tmw_play_pause_button");

	g_object_ref (image);
	gtk_button_set_label (GTK_BUTTON (button), "Play");
//	g_object_unref (image);
	gtk_image_set_from_stock (GTK_IMAGE (image), id, GTK_ICON_SIZE_BUTTON);

AFAIK, this should reference the image (so gtk_button_set_label() doesn't kill
it?), give the button a label, and give it a stock icon.

The result however is an button with "Play", but without an icon, and there are
no messages on the stdout. If I uncomment the unref, i get errors, and it makes
sense to not unref it since gtk_button_set_label does that already.

It _removes previous content_. So if you want both image and label, do not use
gtk_button_set_label(), or use a stock item on gtk_button_set_label(), as in my
example above.

Created attachment 50567 [details] [review]
patch

This patch places the Play/Pause button before the |< and >|, the label states
what the action is (Play or Pause, not Play/Pause). The label is set in main()
before the Widgets are shown to avoid flickering (and so you don't have to
translate the Play in the glade-file since it is already in stock).

I also made the button a bit bigger to overcome "jumping" of the |< and >|, but
I don't think giving it a fixed width is a good choise. Is there a different
way to make it not jump, but to give it the width needed for the longest word
(Play or Pause, in English, it should be the width of Pause, but it can differ
in different languages)?

Other then that, I think it looks quite nice :)

It would be nice if the Play/Pause button had the same width as the Play/Pause
button in Sound Juicer.

As the new volume control is in, and there doesn't seem to be much consensus on the path to follow, status quo it will be.

If you have specific problems with the UI, with use cases to match, please file separate bugs. Thanks.

In response to Comment #30 about using the widget for the volume icon, I think I have figured out a way to use it anyway without breaking anything. I created bug 332079 about it, please scroll to the last comment.
Feedback would be appreciated.

*** Bug 552378 has been marked as a duplicate of this bug. ***