After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323405 - Control buttons at top or use of real toolbar (with mock up)
Control buttons at top or use of real toolbar (with mock up)
Status: VERIFIED WONTFIX
Product: totem
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: General Totem maintainer(s)
General Totem maintainer(s)
: 337492 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-06 22:14 UTC by Amadeus
Modified: 2006-04-06 15:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Mock up of Totem with control buttons at the top. (52.85 KB, image/png)
2005-12-06 22:15 UTC, Amadeus
Details
Screenshot of Rhythmbox CVS from 6/12-2005 with real toolbars with respect global Gnome text on buttons. Here turned off. (47.09 KB, image/png)
2005-12-06 22:17 UTC, Amadeus
Details

Description Amadeus 2005-12-06 22:14:47 UTC
Would it be a good idea, to have the control buttons at the top of the UI?

I suggest this for consistancy with the other Gnome applications. See mock up.

Use of real toolbars have just been commited to Rhythmbox CVS.

Would this be a good idea for Totem aswell?
Comment 1 Amadeus 2005-12-06 22:15:27 UTC
Created attachment 55704 [details]
Mock up of Totem with control buttons at the top.
Comment 2 Amadeus 2005-12-06 22:17:44 UTC
Created attachment 55705 [details]
Screenshot of Rhythmbox CVS from 6/12-2005 with real toolbars with respect global Gnome text on buttons. Here turned off.
Comment 3 Bastien Nocera 2005-12-06 22:38:22 UTC
Consistency with other movie players is more important, IMO. Any other reasons
why you would want to do that?
Comment 4 Amadeus 2005-12-06 23:59:28 UTC
It is consistancy with all the other Gnome applications that I was thinking of.

I know QuickTime, WMP, Real, etc. all have the toolbars at the buttom, but I
think they can better get away with it, as they are not part of an application
suite like Totem is.

Comment 5 Bastien Nocera 2005-12-07 18:23:04 UTC
All the video players on every platform (apart from a couple of outcasts) have
their controls at the bottom of the window. The most important part of the UI is
the video canvas, so the video should be at the top (which is why the statusbar
is at the bottom, and should not be used for important messages).
And it's also for Totem to stay consistent with itself. In fullscreen mode, the
controls are at the bottom, so they should really be as well in the windowed mode.
Comment 6 Amadeus 2005-12-09 04:41:28 UTC
I agree, that it is important that Totem stay consistant with full screen mode.

But what if the controls in full screen mode also was at the top?

I think it make sense to have the controls at the buttom in OS's that have their
menu at the buttom, E.g. like Windows does.

Gnome have desided to have the Gnome menu at the top, initally because of the
moment required in the menus, but I think it is a hamomic solution to have the
application's menu bar, toolbars, and Gnome bar close to each other.

That way all important buttons are at the top.
Comment 7 Amadeus 2005-12-16 21:15:21 UTC
Changing status to reopened.
Comment 8 Evandro Giovanini 2005-12-16 21:35:37 UTC
"I know QuickTime, WMP, Real, etc. all have the toolbars at the buttom, but I
think they can better get away with it, as they are not part of an application
suite like Totem is."

QuickTime and WMP are part of Mac OS and Windows respectively, and both suites
also place toolbars at the top. It was obviously not the goal of WMP developers
to be consistent with other applications in that suite, but that's not the case
for other video players that also have the controls in the bottom.

"(which is why the statusbar is at the bottom, and should not be used for
important messages)"

Bingo! I don't use the controls at all most times I launch Totem; it plays the
video, and then I close the window. The controls are not important, the video is
important.

Totem does not have a toolbar, and the controls are not at the top of the
window. And I think that's good. It doesn't make it more consistent with other
GNOME applications but it makes it a better application.

My 2 cents.
Comment 9 Amadeus 2005-12-18 17:14:20 UTC
Closing the bug as WONTFIX without giving me a change to reply, indicates that you are aware of, that your arguments doesn't hold.

An application can only improve, if the the best argument wins.
Comment 10 Bastien Nocera 2005-12-18 18:09:43 UTC
*Sigh*
I made my point, and Evandro explained it again. Following those explanations, I will not change the controls to be a toolbar. Feel free to reopen if you have a strong counter-argument.
Comment 11 Amadeus 2005-12-23 11:51:01 UTC
> QuickTime and WMP are part of Mac OS and Windows respectively, and both
> suites also place toolbars at the top. It was obviously not the goal of WMP
> developers to be consistent with other applications in that suite, but that's
> not the case for other video players that also have the controls in the
> bottom.

But isn't that in flavor for having the controls at the top?

>> "(which is why the statusbar is at the bottom, and should not be used for
>> important messages)"

> Bingo! I don't use the controls at all most times I launch Totem; it plays
> the video, and then I close the window. The controls are not important, the
> video is important.

Mozilla don't think that. Firefox have the toolbars at the top, and the browser below.

> Totem does not have a toolbar, and the controls are not at the top of the
> window. And I think that's good. It doesn't make it more consistent with
> other GNOME applications but it makes it a better application.

Why doesn't toolbars at the top make consistancy with Gnome?


I have changed status to varified, as this is the only option I can select. 

Comment 12 Bastien Nocera 2006-04-06 15:37:44 UTC
*** Bug 337492 has been marked as a duplicate of this bug. ***