gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] /srv/bzr/gnash/trunk r12341: Refactored input device


From: Rob Savoye
Subject: Re: [Gnash-commit] /srv/bzr/gnash/trunk r12341: Refactored input device support for the framebuffer GUI.
Date: Fri, 30 Jul 2010 07:37:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2 Thunderbird/3.1.1

On 07/30/10 07:23, Benjamin Wolsey wrote:

> Surely not! Using the library functions is by far the easiest way
> for compatibility and reliability.

  I agree with you mostly... Using the standard libraries makes the most
sense, but the linux input event devices support things like
accelerometers, which I don't think the standard desktop does. So the
idea was to *maybe* use the input events with GTK/KDE for things that
aren't a mouse or keyboard. Don't freak out yet. :-)

> I think it would be best to allow building the FB gui without it 
> affecting the other GUIs. Even when configure is fixed to detect my 
> missing tslib, enabling one GUI shouldn't affect the way the others
> are built.

  Well of course the FB GUI shouldn't effect anything else. However we
*do* want touchscreen support with GTK/KDE, cause there are these things
called tablets that seem to be getting popular. Some touchscreens work
like a mouse, and others have their own drivers. I'll have a fix for the
tslib problem in a bit, working on it now.

> I always did, and there were no warnings. That's not to say it was in
> a good state before, but it was entirely warning-free.

  I've always gotten warnings from that code on my platforms, but
whatever, cleaning it all up in the near term is on the schedule.
Getting rid of all the warnings while still doing major refactoring
seems counter productive, especially for code almost nobody uses.

        - rob -



reply via email to

[Prev in Thread] Current Thread [Next in Thread]