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

[Cesar Mauri <cesar crea-si com>]

Hi,

> To integrate this feature properly in Gnome and make users feels like
> it's truly a part of it, I feel like the application would need to be
> split in several UI components connected in the right places in the
> Gnome UI and a service which would read to the webcam and do the head
> tracking.
>
> That would give the following UI parts :
> - Configuration dialog for eviacam, since it's a settings global to
> the desktop it would make sense to have it in the control center.
> - A dialog which show the webcam output with overlay, for
> feedback/testing purpose. That's configuration and can probably go in
> the control center applet too.
> - Indicator elements and buttons to simulate mouse clicks, since they
> need to be always showed up when the service is enabled, it would make
> sense to have them in the shell top bar.
> - Button for Enabling/Disabling the feature, this will probably go
> directly in the accessibility menu
>
> I guess that integrating in the control center will require a rewrite
> of most of the the UI and the shell integration will be a shell plugin
> so the current wxWidget implementation won't really be a problem.
>
> Then we will need a separated service (probably dbus controlled) based
> on the existing code which does the actual tracking and move the
> mouse.
>
> So the questions now are : Is it easily possible to separate the
> existing program in those parts?And is someone willing to step up
> and do the work?

eViacam has been designed trying to separate the internal logic from the 
UI. However, such a redesign would require a considerable effort, not 
only to integrate into GNOME but also to provide a "fallback" UI for 
other environments and the appropriate communication protocols between 
logic and UI. This will also impact further development dramatically.

Additionally, one detail to take into account is that to send mouse 
commands and provide visual feedback (i.e. dwell time countdown and 
other hints) it is necessary to have a Display handler. Can a service 
have access to a Display?

Perhaps a cheaper option could be to maintain the current UI for camera 
overlay (i.e. the main window) but disable other UI features and control 
them "remotely" from external UIs which better fit into the GNOME 
ecosystem. Note that this does not remove the dependency with wxWidgets, 
but reduces efforts significantly and allows to save CPU (is not 
necessary to serialize/deserialize camera frames which can be a costly 
operation). What do you think?

Regards,

César