Re: Multimedia widgets in GTK+?
- From: "Martin Meyer" <elreydetodo gmail com>
- To: "Michael Natterer" <mitch gimp org>
- Cc: gtk-devel-list gnome org, Ross Burton <ross burtonini com>, Xavier Bestel <xavier bestel free fr>
- Subject: Re: Multimedia widgets in GTK+?
- Date: Wed, 21 Mar 2007 09:52:25 -0400
You're right of course that scroll bars should not exhibit the
click-to-positon behavior, but I wouldn't like to see Totem creating a
custom widget action because I feel it's probably not a unique
requirement. Should every app that wants this ability have to add
those hooks into the button press event? Come to think of it, are
there any others or is Totem the only one?
How about the volume changer applet? It uses a slider too, but it
doesn't immediately change to wherever you click, it just moves a
little closer. This is the same (or similar) behavior to a regular
scroll bar. Maybe an attribute for the widget would be appropriate
like you said. Are there any possible behaviors other than
click-to-position or click-get-closer?
Martin
On 3/21/07, Michael Natterer <mitch gimp org> wrote:
On Wed, 2007-03-21 at 08:46 -0400, Martin Meyer wrote:
> The slider is something that primarily annoys me in Totem. When Totem
> is in full screen mode the slider/position bar is huge. You might have
> to move your mouse several inches out of the way to get over to where
> the slider current position is, then move it right back to where it
> was before when you realize you can't click there and expect it to
> move.
>
> There are two valuable points to making the slider click-to-go-able.
> 1) Reduces arm fatigue from moving the mouse too much. I know this
> might sound like BS but it really can get annoying and tiring having
> to move the mouse to find the right spot to click. 2) This is
> consistently something Windows users bicker at me about when trying to
> use my computer to watch videos. And to make it worse, I bicker right
> along with them because I hate its current behavior.
Do you want this behavior in all scrollbars? Also in text editors and
in your browser? A click on a stream position indicator is simply
different from a click on a real *scroll*bar. It should definitely
not be the default behavior of GtkRange.
Why can't totem simply fix that by itself? The most trivial way
is to connect to button-press-event and button-release-event
and change GdkEventButton::button from 1 to 2 in the callback
and return FALSE.
Another option is to add a property for that in GtkRange itself.
ciao,
--mitch
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]