Re: Feature proposal: Alternative input system based on low-cost webcam

On 10/23/2011 02:11 AM, Matthias Clasen wrote:
> On Fri, Oct 21, 2011 at 12:28 PM, Piñeiro <apinheiro igalia com> wrote:
>> And finally, the main concern could be about the graphical toolkit.
>> eViacam uses wxWidgets [3][4], in order to ensure a native look and feel
>> on both Windows and Linux systems. wxGTK is the most common wxWidgets
>> port, meaning that it will be using Gtk+ native widgets wherever
>> possible. This feature proposal would include the proposal of wxWidgets
>> as a external dependency.
> I think both sourceforge and wxWidgets are disqualifying problems.

There are other apps included on GNOME moduleset but not at GNOME git
(ie: inkscape is also hosted at sourceforge).

As I said, wxWidgets was the main concern here.

> But I think the proposal needs some clarification anyway. What exactly
> is being proposed here ? The initial description made it sound like a
> special input method that is taylored to a11y needs. I don't really
> see how wxWidgets comes into this at all - shouldn't this be a session
> service that analyzes the webcam input and drives the mouse ? Where
> does UI come into this ?

The application provides that UI (here [1][2] for some screenshots) in
order to:
  * Configure the application (on the screenshot the Configuration dialog)
  * A main window showing the input of the webcam, in order to get some
feedback (ie: if the head region was properly set)
  * And finally, some visual elements are required to be present
continuously. On that screenshot, the icons at that kind of top panel,
called the click window. It is used to allow the user the kind of click
(left, right, drag&drop, etc)

wxwidgets come to this discussion because it is how this UI is
implemented right now.

> On the other hand, the UI that _is_ needed here is a new switch in the
> shell universal access menu and
> some support in the a11y panel in the control-center. Neither of these
> can be done using wxWidgets, obviously...

For the shell case, it is also required the equivalent to the click
window. If this service is active that UI is also required.

But, for the fallback mode, current UI is valid IMHO.

> Just adding some standalone application using a foreign toolkit
> doesn't make this an integrated feature.

As I implied on the original mail, we were aware that this feature
proposal would have opposition. But we felt that the proposal worth it,
in order to explain the current status and get the feedback from the
community about what would be required to bring that feature to GNOME.



Alejandro Piñeiro Iglesias

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