Re: GNOME 3.2: mapping extra mouse buttons

On Wed, Mar 23, 2011 at 01:17:58PM -0600, Federico Mena Quintero wrote:
> On Wed, 2011-03-23 at 01:10 +0000, Sergey Udaltsov wrote:
> > These days there are many many mice with > 5 buttons (3 + scroll). For
> > a moment the only solution for them is not very user-friendly imwheel.
> > Would it make sense to provide mapping for those extra buttons? On
> > windows, people use them for switching apps, copy/paste, back/forward
> > etc. Why cannot we provide comfortable GUI for that configuration?
> > Could it be done within keyboard panel - or do we need extra panel (or
> > extra tab in the "Mouse" panel)? Should we map "buttons->actions" or
> > "buttons->keys" (so shortcuts would be picked automatically)?
> Definitely buttons->actions, for the reasons which Peter mentioned.
> Right now we don't have a generic way to tell an app (or the focused
> window) to "do an action" - there is no central system of verbs.
> However, we *do* have GtkActions, and stock names, and such.  It would
> be a good exercise to grab a bunch of common actions (copy, paste, etc.)
> and to see if they can be mapped to buttons easily.
> 1. Make a list of stock names which are used in many apps (cut, copy,
> paste, zoom in, etc.)

just because zoom is mentioned here: zoom, rotate and a few other actions
are actions that are ideally continuous. Rotate isn't just "rotate" but
"rotate by X degrees". as such, they are difficult to map to pure
actions unless you also provide the angle, direction, velocity, etc.

an example where we already did it wrong are scroll wheels that are mapped
to button clicks (though we're working on exporting those as valuators). so
when considering actions, please don't forget that they may be more complex
than just a "zoom in" action.

other than that, I thnk the concept of "actions" is a good one, especially
when looking a bit further ahead with touch gestures and their potential
mapping to actions.


> 2. Figure out a way to locate the things created by a GtkUIManager.
> This may involve adding something like gtk_window_list_actions().  Talk
> to the GTK+ people about this.
> 3. Once you have the things from (2), you can get their respective
> GtkActions and invoke them once you get a button event.
> This glosses over a *lot* of detail, but it's a start :)
>   Federico

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]