[RFC v4] Introduce output zoom.

Scott Moreau oreaus at gmail.com
Thu Feb 23 18:23:38 PST 2012

On Thu, Feb 23, 2012 at 3:54 PM, Kristian Hoegsberg <hoegsberg at gmail.com>wrote:

> On Wed, Feb 22, 2012 at 02:21:41PM -0700, Scott Moreau wrote:
> > Ideally, we would want to use <modifier>+Scroll binding but that will
> have
> > to wait for axis events. For now we just use keybindings. Zoom in/out
> with
> > Super+Up/Down.
> Applied with a minor edit to really fix the code-before-declaration
> thing.  With your change we still end up with
> weston_output_update_zoom(struct weston_output *output, int x, int y)
> {
>         if (output->zoom.level <= 0)
>                 return;
>        float ratio;
>        ...
> That is, the ratio variable is declared after the if statement.
> That's what we don't want.

Ah ok. So all declarations should come before code. Clearly I didn't pay
attention to the meaning of code-before-declaration.

> Anyway, enough nit-picking, it works well where, but we need to fix
> the binding issue.  We need to swallow the key press that triggers the
> binding and we also need to swallow the corresponding key up.  What
> I've been thinking is that we could let the binding handler return a
> value to indicate whether or not to swallow the event.  The tricky
> part is going to be swallowing the release event, since that may come
> many key events later.  We could just maintain a per-device list of
> "keys that are down, and we need to swallow the release event", but
> that's kinda gross.  I don't really think there's a nicer way though.
> And all this applies to pointer buttons as well.
> Kristian

Yes, this is a problem with all keybindings currently. I was thinking the
same about eating the actual keybinding when the pressed/clicked but I
hadn't given much thought about the corresponding release event(s). It does
seem like we'd need some kind of state tracking for this. I haven't looked
into it yet but maybe when a binding is detected, we could set something
(possibly on the binding list or similar?) to listen for release of the
events involved. I haven't given much thought to this nor have I looked
into it yet but will do so.

Also, is this a blocker? I don't see the patch in weston yet.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120223/faf1958a/attachment.html>

More information about the wayland-devel mailing list