Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, I think that this raises an important point about inclusion of accessibility features: they are often very innovative, and they enhance the experiences of average users. For example, the on-screen keyboard can be adapted for use on touch-screen devices (at least this is my understanding from discussions I had with Nohemi Fernandez while we were in Montreal) - as long as someone extends the code :) I agree with that, but we should always keep in mind who is the primary target, because sometimes people with disabilities need specific features which people without disabilities don't (imagine, for instance, a filter for the on-screen keyboard to remove unwanted keystrokes due to poor hand control). Since the trends right now are moving away from mouse use, it might be helpful/interesting to ask ourselves whether or how cameras can be used to replace them. Are there situations in which a camera would be more useful than a touch screen or track pad? Certainly it can be for certain users with disabilities, but we might want to explore other use cases, as well. IMHO (I'm not an expert) we are still in the stone age of the machine vision based interaction and we will see great innovations in years to come. So, sure, there is much to explore and have fun! BTW: if someone is interested in playing with this, she might find interesting/useful another project called SITPLUS [1] in which we try to find other uses of camera based interaction for people with (severe) disabilities. [1] http://sitplus.appctarragona.org > I -think- that for this to work properly we'd need a bunch of things: > first, we need to track not only head movement but also your eyes and > several facial muscles so that we can have accurate tracking and hints > about your AFAIK, eViacam developers plans to add support for more facial gestures in the future. Yes. Some users requested to detect facial gestures [2] and there had been some efforts regarding blinking detection [3]. We hope to have time (and resources) to add/improve them soon. [2] https://sourceforge.net/tracker/?func=detail&aid=2883828&group_id=248049&atid=1199431 [3] http://eviacam.git.sourceforge.net/git/gitweb.cgi?p=eviacam/eviacam;a=shortlog;h=refs/heads/blink_detect > intentions. Well, this requires cameras with resolutions much higher > than VGA, which is the current standard for these. Then, someone needs > to figure out how to track all these elements real-time with little > cpu usage. As it is, we With higher resolution cameras the behaviour would be better. But please, read again the feature proposal name "Alternative input based system based on *low-cost* webcam". About performance, it is something that was always one of the priorities for eViacam developers, and the reason that the configuration wizard allows you to tweak so many parameters. > can't even maintain a Mexican hat over ones head in Cheese without it > lagging 3 seconds behind. And finally for this to work we'de need > pretty good AI to be able to understand what you really want so that > you don't end up sending a draft-mail just because you glanced at that > gorgeous girl that just passed in front of you. See my previous comment about performance. Performance has always been a primary goal. In fact, is not a coincidence that we chose C/C++, used multiple threads and wrote custom code for the camera capture. And, in my experience, there is no noticeable delay in the capture - control loop is the camera is properly set up. In fact, I still remember running earlier versions on a PIII 450Hz laptop without problems. I also think that performance and facial gesture support will most likely improve faster if this is included and available to more users and developers. Sure. Regards, César ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, > > > I think that this raises an important point about inclusion of >> accessibility features: they are often very innovative, and they enhance >> the experiences of average users. For example, the on-screen keyboard >> can be adapted for use on touch-screen devices (at least this is my >> understanding from discussions I had with Nohemi Fernandez while we were >> in Montreal) - as long as someone extends the code :) >> > > I agree with that, but we should always keep in mind who is the primary > target, because sometimes people with disabilities need specific features > which people without disabilities don't (imagine, for instance, a filter for > the on-screen keyboard to remove unwanted keystrokes due to poor hand > control). > > I completely agree with you here. I think that it is crucial that GNOME have a culture that supports and understands Universal design. At the same time, I also think that our accessibility community needs to put some more effort into talking to our community about access, and in communicating with the community about how to best integrate features so that they do not interfere with the average user's experience. > > Since the trends right now are moving away from mouse use, it might be >> helpful/interesting to ask ourselves whether or how cameras can be used >> to replace them. Are there situations in which a camera would be more >> useful than a touch screen or track pad? Certainly it can be for certain >> users with disabilities, but we might want to explore other use cases, >> as well. >> > > IMHO (I'm not an expert) we are still in the stone age of the machine > vision based interaction and we will see great innovations in years to come. > So, sure, there is much to explore and have fun! > > BTW: if someone is interested in playing with this, she might find > interesting/useful another project called SITPLUS [1] in which we try to > find other uses of camera based interaction for people with (severe) > disabilities. > > [1] http://sitplus.appctarragona.org > > > > I -think- that for this to work properly we'd need a bunch of >> things: >> > first, we need to track not only head movement but also your eyes >> and >> > several facial muscles so that we can have accurate tracking and >>hints >> > about your >> >>AFAIK, eViacam developers plans to add support for more facial gestures >>in the future. >> > > Yes. Some users requested to detect facial gestures [2] and there had been > some efforts regarding blinking detection [3]. We hope to have time (and > resources) to add/improve them soon. > > [2] > https://sourceforge.net/tracker/?func=detail&aid=2883828&group_id=248049&atid=1199431 > > [3] > http://eviacam.git.sourceforge.net/git/gitweb.cgi?p=eviacam/eviacam;a=shortlog;h=refs/heads/blink_detect > > > >> > intentions. Well, this requires cameras with resolutions much higher >> > than VGA, which is the current standard for these. Then, someone >>needs >> > to figure out how to track all these elements real-time with little >> > cpu usage. As it is, we >> >>With higher resolution cameras the behaviour would be better. But >>please, read again the feature proposal name "Alternative input based >>system based on *low-cost* webcam". >> >>About performance, it is something that was always one of the >> priorities >>for eViacam developers, and the reason that the configuration wizard >>allows you to tweak so many parameters. >> >> > can't even maintain a Mexican hat over ones head in Cheese without >> it >> > lagging 3 seconds behind. And finally for this to work we'de need >> > pretty good AI to be able to understand what you really want so that >> > you don't end up sending a draft-mail just because you glanced at >>that >> > gorgeous girl that just passed in front of you. >> >>See my previous comment about performance. >> > > Performance has always been a primary goal. In fact, is not a coincidence > that we chose C/C++, used multiple threads and wrote custom code for the > camera capture. And, in my experience, there is no noticeable delay in the > capture - control loop is the camera is properly set up. In fact, I still > remember running earlier versions on a PIII 450Hz laptop without problems. > > > I also think that performance and facial gesture support will most >> likely improve faster if this is included and available to more users >> and developers. >> > > Sure. > > Best wishes, Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, > I think we are missing the important bit here. > > > > Tracking your head with a webcam to drive a mouse results in a bad > > experience. It doesn't work even remotely well. > > Some users already find this feature/application really useful. > > > Someone will, in the future, figure out how to do this properly and > > then it won't be called an accessibility feature but something > > everyone will want to use. > > It would be good to have it for general use for the feature. But for the > moment it is just a specific accessibility tool. > I think that this raises an important point about inclusion of accessibility features: they are often very innovative, and they enhance the experiences of average users. For example, the on-screen keyboard can be adapted for use on touch-screen devices (at least this is my understanding from discussions I had with Nohemi Fernandez while we were in Montreal) - as long as someone extends the code :) Since the trends right now are moving away from mouse use, it might be helpful/interesting to ask ourselves whether or how cameras can be used to replace them. Are there situations in which a camera would be more useful than a touch screen or track pad? Certainly it can be for certain users with disabilities, but we might want to explore other use cases, as well. > > > > > I -think- that for this to work properly we'd need a bunch of things: > > first, we need to track not only head movement but also your eyes and > > several facial muscles so that we can have accurate tracking and hints > > about your > > AFAIK, eViacam developers plans to add support for more facial gestures > in the future. > > > intentions. Well, this requires cameras with resolutions much higher > > than VGA, which is the current standard for these. Then, someone needs > > to figure out how to track all these elements real-time with little > > cpu usage. As it is, we > > With higher resolution cameras the behaviour would be better. But > please, read again the feature proposal name "Alternative input based > system based on *low-cost* webcam". > > About performance, it is something that was always one of the priorities > for eViacam developers, and the reason that the configuration wizard > allows you to tweak so many parameters. > > > can't even maintain a Mexican hat over ones head in Cheese without it > > lagging 3 seconds behind. And finally for this to work we'de need > > pretty good AI to be able to understand what you really want so that > > you don't end up sending a draft-mail just because you glanced at that > > gorgeous girl that just passed in front of you. > > See my previous comment about performance. > I also think that performance and facial gesture support will most likely improve faster if this is included and available to more users and developers. Regards, Meg Ford > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On 10/25/2011 03:56 PM, Jan Jokela wrote: > I think we are missing the important bit here. > > Tracking your head with a webcam to drive a mouse results in a bad > experience. It doesn't work even remotely well. Some users already find this feature/application really useful. > Someone will, in the future, figure out how to do this properly and > then it won't be called an accessibility feature but something > everyone will want to use. It would be good to have it for general use for the feature. But for the moment it is just a specific accessibility tool. > > I -think- that for this to work properly we'd need a bunch of things: > first, we need to track not only head movement but also your eyes and > several facial muscles so that we can have accurate tracking and hints > about your AFAIK, eViacam developers plans to add support for more facial gestures in the future. > intentions. Well, this requires cameras with resolutions much higher > than VGA, which is the current standard for these. Then, someone needs > to figure out how to track all these elements real-time with little > cpu usage. As it is, we With higher resolution cameras the behaviour would be better. But please, read again the feature proposal name "Alternative input based system based on *low-cost* webcam". About performance, it is something that was always one of the priorities for eViacam developers, and the reason that the configuration wizard allows you to tweak so many parameters. > can't even maintain a Mexican hat over ones head in Cheese without it > lagging 3 seconds behind. And finally for this to work we'de need > pretty good AI to be able to understand what you really want so that > you don't end up sending a draft-mail just because you glanced at that > gorgeous girl that just passed in front of you. See my previous comment about performance. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
To give my 2cents and recenter the discussion a bit since I think it would be a nice feature to have in Gnome3 (but keep in mind that's just my opinion from informations I gleaned from the eViacam website and that I'm not volunteering to do any works on this) As I see it right now the problem is not really wxWidget, gstreamer or sourceforce but that the whole feature is implemented in one big monolithic application in one separate UI, providing it's own always displayed toolbar, etc.. as a result including it as is won't fit in the whole Gnome experience, especially given that's an accessibility aid that interact with the whole desktop and not a separate application that user launch, use and close like inkscape. 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? On Mon, Oct 24, 2011 at 10:49 PM, Cesar Mauri wrote: > > Hi, > >>> The application provides that UI (here [1][2] for some screenshots) in >>> order to: >>> * Configure the application (on the screenshot the Configuration dialog) >> >> I am not a designer but I would somehow wonder if they would consider >> this a good user-interface design. > > Those screenshots are quite outdated and the current version also includes a > configuration wizard. See the eViacam's help files (included in the source > tarball) for updated versions. > >>> * A main window showing the input of the webcam, in order to get some >>> feedback (ie: if the head region was properly set) >> >> Does this use gstreamer? In general, is the application using gstreamer >> as de-facto standard for webcams in Linux/GNOME? > > No, eViacam does not use gstreamer. It uses its own capture layer on top of > v4l2 because needs access to the settings of the camera (i.e. to allow to set > exposure time and other parameters). > > Regards, > César > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Olivier Lê Thanh Duong Phone : +32487892093 Jabber: oleth...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi, The application provides that UI (here [1][2] for some screenshots) in order to: * Configure the application (on the screenshot the Configuration dialog) I am not a designer but I would somehow wonder if they would consider this a good user-interface design. Those screenshots are quite outdated and the current version also includes a configuration wizard. See the eViacam's help files (included in the source tarball) for updated versions. * A main window showing the input of the webcam, in order to get some feedback (ie: if the head region was properly set) Does this use gstreamer? In general, is the application using gstreamer as de-facto standard for webcams in Linux/GNOME? No, eViacam does not use gstreamer. It uses its own capture layer on top of v4l2 because needs access to the settings of the camera (i.e. to allow to set exposure time and other parameters). Regards, César ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
I think we are missing the important bit here. Tracking your head with a webcam to drive a mouse results in a bad experience. It doesn't work even remotely well. Someone will, in the future, figure out how to do this properly and then it won't be called an accessibility feature but something everyone will want to use. I -think- that for this to work properly we'd need a bunch of things: first, we need to track not only head movement but also your eyes and several facial muscles so that we can have accurate tracking and hints about your intentions. Well, this requires cameras with resolutions much higher than VGA, which is the current standard for these. Then, someone needs to figure out how to track all these elements real-time with little cpu usage. As it is, we can't even maintain a Mexican hat over ones head in Cheese without it lagging 3 seconds behind. And finally for this to work we'de need pretty good AI to be able to understand what you really want so that you don't end up sending a draft-mail just because you glanced at that gorgeous girl that just passed in front of you. Cheers, Jan Jokela On Mon, Oct 24, 2011 at 2:49 PM, Piñeiro wrote: > On 10/24/2011 09:16 AM, Vincent Untz wrote: > >> There are other apps included on GNOME moduleset but not at GNOME git > >> (ie: inkscape is also hosted at sourceforge). > > That's the difference between core and non-core. For proper integration > > with GNOME (which includes integration in gnome-shell, g-c-c, etc.), > > this feature would need to be in core, which has additional > > requirements. > > I was aware of those difference. But it is true that I missed to do a > analysis in this aspect in relation of both eViacam and Dasher (in a > different thread) (so thanks for the reminder) > > > > > Inkscape, on the other hand is not part of GNOME core -- it's a great > > application, but it doesn't need any deep integration with the core of > > the desktop. > > In this aspect, and taking into account the know problems with the > integration of eViacam and Dasher, it is clear that we can't ask them to > be accepted as GNOME core, at least for the moment. But both are really > great applications and cover functionality that we feel are we lack > right now. And we feel that it would be easier to improve their > integration with the core if we include them on GNOME ecosystem. Or > explaining this from other POV. If someone ask for that feature and ask > on #a11y channel for an app solving this, we will recommend those. > > And in this aspect, and in relation with what I said about a missing > analysis, after thinking a little on all the accessibility features > proposed, it is clean (IMHO) that there are two different groups: > > * Valid as core, so valid as a feature proposal): > * zoom dialog > * Brightness and contrast functionality > * Focus caret/tracking > * Braille translator > * Work still required to be core, so not valid as a feature proposal but > the moment, just asking them to be include on GNOME apps modulesets: > * eViacam > * Dasher > > Although in the case of eViacam it is still required to debate if it is > valid also to be included on GNOME moduleset. > > BR > > -- > Alejandro Piñeiro Iglesias > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On 10/24/2011 09:16 AM, Vincent Untz wrote: >> There are other apps included on GNOME moduleset but not at GNOME git >> (ie: inkscape is also hosted at sourceforge). > That's the difference between core and non-core. For proper integration > with GNOME (which includes integration in gnome-shell, g-c-c, etc.), > this feature would need to be in core, which has additional > requirements. I was aware of those difference. But it is true that I missed to do a analysis in this aspect in relation of both eViacam and Dasher (in a different thread) (so thanks for the reminder) > > Inkscape, on the other hand is not part of GNOME core -- it's a great > application, but it doesn't need any deep integration with the core of > the desktop. In this aspect, and taking into account the know problems with the integration of eViacam and Dasher, it is clear that we can't ask them to be accepted as GNOME core, at least for the moment. But both are really great applications and cover functionality that we feel are we lack right now. And we feel that it would be easier to improve their integration with the core if we include them on GNOME ecosystem. Or explaining this from other POV. If someone ask for that feature and ask on #a11y channel for an app solving this, we will recommend those. And in this aspect, and in relation with what I said about a missing analysis, after thinking a little on all the accessibility features proposed, it is clean (IMHO) that there are two different groups: * Valid as core, so valid as a feature proposal): * zoom dialog * Brightness and contrast functionality * Focus caret/tracking * Braille translator * Work still required to be core, so not valid as a feature proposal but the moment, just asking them to be include on GNOME apps modulesets: * eViacam * Dasher Although in the case of eViacam it is still required to debate if it is valid also to be included on GNOME moduleset. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Hi! > The application provides that UI (here [1][2] for some screenshots) in > order to: > * Configure the application (on the screenshot the Configuration dialog) I am not a designer but I would somehow wonder if they would consider this a good user-interface design. > * A main window showing the input of the webcam, in order to get some > feedback (ie: if the head region was properly set) Does this use gstreamer? In general, is the application using gstreamer as de-facto standard for webcams in Linux/GNOME? > * 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) Those should be displayed in the shell directly I guess (and in fallback mode somehow). In general, shouldn't we consider to split the application into front-end-configuration and a backend process so that the UI doesn't have to be cross-platform (which is always a compromise) and we can still benefit from all the details done in the backend. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
- Mensaje original - > De: Michael Biebl > Para: Richard Hughes > CC: Cesar Mauri ; desktop-devel-list@gnome.org > Enviado: lunes 24 de octubre de 2011 0:31 > Asunto: Re: Feature proposal: Alternative input system based on low-cost > webcam > > 2011/10/22 Richard Hughes : >> On 21 October 2011 17:28, Piñeiro wrote: >>> * Look and feel: some people could not agree with current interface >>> [2]. This shouldn't be a blocker thought. >>> This feature proposal would include the proposal of wxWidgets >>> as a external dependency. >> >> wxWidgets applications differ lots from "native" applications. I >> really don't think depending on wxWidgets is a good idea. > > Although I'm not an active user of wxWidgets I do know that the > maintenance of wxWidgets in Debian has always been a major hassle. > E.g. there still isn't a stable upstream release of wxWidgets that > supports GTK 3. There is supposed to be one beginning next year, but > apparently that has been said since almost three years. > And the current stable branch, 2.8, still uses obsolete libraries like > libgnomeprint and apparently wxWidgets upstream likes to introduce > disruptive changes within a stable branch. > GTK+3 support is in the roadmap for the next stable wxWidgets 3.0. And there is development branch with workable code in [1]. I think that the printing support comment is not applicable here, because the use of wxWidgets is pretty limited to the GUI. Anyway, the use of libgnomeprint was optional and beginning with version wxWidgets 2.9, you can use the GTK+ printing support [2]. Cheers, -- Juanjo Marin [1] http://svn.wxwidgets.org/svn/wx/wxWidgets/branches/SOC2011_GTK3/ [2] http://docs.wxwidgets.org/2.9.2/overview_unixprinting.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
Le lundi 24 octobre 2011, à 01:11 +0200, Piñeiro a écrit : > On 10/23/2011 02:11 AM, Matthias Clasen wrote: > > On Fri, Oct 21, 2011 at 12:28 PM, Piñeiro 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). That's the difference between core and non-core. For proper integration with GNOME (which includes integration in gnome-shell, g-c-c, etc.), this feature would need to be in core, which has additional requirements. Inkscape, on the other hand is not part of GNOME core -- it's a great application, but it doesn't need any deep integration with the core of the desktop. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 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. BR [1] http://sourceforge.net/dbimage.php?id=241616 [2] http://sourceforge.net/dbimage.php?id=241612 -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On 10/23/2011 04:46 PM, Stefan Sauer wrote: > > > Note > === > > In addition to wxwidgets, eViacam has also dependencies with opencv and > libv4l1, that should be included as external dependencies. > > > [1] http://eviacam.sourceforge.net/eviacam.php > Do people using it have two webcams - one for the screennavigation and > one for videocalls? Just wonder if someone has thought about the > resource clash here. Does seems like a feature for a specific use case. Although it seems interesting, it seems somewhat offtopic for that discussion, and, IMHO, not a disqualifying issue. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
2011/10/22 Richard Hughes : > On 21 October 2011 17:28, Piñeiro wrote: >> * Look and feel: some people could not agree with current interface >> [2]. This shouldn't be a blocker thought. >> This feature proposal would include the proposal of wxWidgets >> as a external dependency. > > wxWidgets applications differ lots from "native" applications. I > really don't think depending on wxWidgets is a good idea. Although I'm not an active user of wxWidgets I do know that the maintenance of wxWidgets in Debian has always been a major hassle. E.g. there still isn't a stable upstream release of wxWidgets that supports GTK 3. There is supposed to be one beginning next year, but apparently that has been said since almost three years. And the current stable branch, 2.8, still uses obsolete libraries like libgnomeprint and apparently wxWidgets upstream likes to introduce disruptive changes within a stable branch. So I hope, that we won't depend on wxWidgets as toolkit. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On 10/21/2011 06:28 PM, Piñeiro wrote: > Description > === > > Some physically impaired users are not able to use the mouse, so an > alternative input system is required. web-cams are a really common and > cheap device these days (most of modern laptops include it), so one > option is use a webcam to track the motion of any object visible by the > camera and moves the mouse cursor according to the path of the tracked > object (a user's head, for example). > > > Module proposed > === > > In order to fulfill this feature, we propose eViacam (Enable Viacam) [1]. > > eViacam is a mouse replacement software that moves the pointer as you > move your head. It works on standard PCs equipped with a web camera. No > additional hardware is required. Based on the award winning Facial Mouse > software. > > eViacam is a mature tool, with several years of development, with a user > base, and active help forums. It was also reported that it works fine > with other GNOME related modules like Dasher. > > > Owner > > > César Mauri > > > Involved parties > == > > Accessibility team > > > Current Status > = > > As I said on the module proposal this is an already mature tool, so > towards 3.4 the basic issues is about the integration with GNOME. > * Repositories: right now it is on sourceforge. This shouldn't be a > blocker thought. > * Bugzilla: pending (but probably we should wait until this feature is > approved) > * Look and feel: some people could not agree with current interface > [2]. This shouldn't be a blocker thought. > > 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. > > > Note > === > > In addition to wxwidgets, eViacam has also dependencies with opencv and > libv4l1, that should be included as external dependencies. > > > [1] http://eviacam.sourceforge.net/eviacam.php Do people using it have two webcams - one for the screennavigation and one for videocalls? Just wonder if someone has thought about the resource clash here. Stefan > [2] http://sourceforge.net/projects/eviacam/#screenshots > [3] http://en.wikipedia.org/wiki/Wxwidgets > [4] http://wxwidgets.org/ > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On Fri, Oct 21, 2011 at 12:28 PM, Piñeiro 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. 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 ? 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... Just adding some standalone application using a foreign toolkit doesn't make this an integrated feature. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
- Mensaje original - > De: Richard Hughes > Para: Piñeiro > CC: Cesar Mauri ; desktop-devel-list@gnome.org > Enviado: sábado 22 de octubre de 2011 11:47 > Asunto: Re: Feature proposal: Alternative input system based on low-cost > webcam > > On 21 October 2011 17:28, Piñeiro wrote: >> * Repositories: right now it is on sourceforge. This shouldn't be a >> blocker thought. > > I'm pretty sure it needs to be on git.gnome.org > >> * Look and feel: some people could not agree with current interface >> [2]. This shouldn't be a blocker thought. >> This feature proposal would include the proposal of wxWidgets >> as a external dependency. > > wxWidgets applications differ lots from "native" applications. I > really don't think depending on wxWidgets is a good idea. Well, I think a wxWidgets application can look like a native GNOME application if you want to, and it's not difficult for an average GUI. You're using native GTK widgets after all. >> In addition to wxwidgets, eViacam has also dependencies with opencv and >> libv4l1, that should be included as external dependencies. > > Shouldn't eViacam should be ported to libv4l2? I checked the lastest version of eviacam and it uses the v4l2 API. I think that it just that the configure file uses linux/videodev.h and libv4l1-videodev.h for detecting the presence of v4l, that consist of 3 different libraries: libv4lconvert, libv4l1 and libv4l2. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: Alternative input system based on low-cost webcam
On 21 October 2011 17:28, Piñeiro wrote: > * Repositories: right now it is on sourceforge. This shouldn't be a > blocker thought. I'm pretty sure it needs to be on git.gnome.org > * Look and feel: some people could not agree with current interface > [2]. This shouldn't be a blocker thought. > This feature proposal would include the proposal of wxWidgets > as a external dependency. wxWidgets applications differ lots from "native" applications. I really don't think depending on wxWidgets is a good idea. > In addition to wxwidgets, eViacam has also dependencies with opencv and > libv4l1, that should be included as external dependencies. Shouldn't eViacam should be ported to libv4l2? Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature proposal: Alternative input system based on low-cost webcam
Description === Some physically impaired users are not able to use the mouse, so an alternative input system is required. web-cams are a really common and cheap device these days (most of modern laptops include it), so one option is use a webcam to track the motion of any object visible by the camera and moves the mouse cursor according to the path of the tracked object (a user's head, for example). Module proposed === In order to fulfill this feature, we propose eViacam (Enable Viacam) [1]. eViacam is a mouse replacement software that moves the pointer as you move your head. It works on standard PCs equipped with a web camera. No additional hardware is required. Based on the award winning Facial Mouse software. eViacam is a mature tool, with several years of development, with a user base, and active help forums. It was also reported that it works fine with other GNOME related modules like Dasher. Owner César Mauri Involved parties == Accessibility team Current Status = As I said on the module proposal this is an already mature tool, so towards 3.4 the basic issues is about the integration with GNOME. * Repositories: right now it is on sourceforge. This shouldn't be a blocker thought. * Bugzilla: pending (but probably we should wait until this feature is approved) * Look and feel: some people could not agree with current interface [2]. This shouldn't be a blocker thought. 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. Note === In addition to wxwidgets, eViacam has also dependencies with opencv and libv4l1, that should be included as external dependencies. [1] http://eviacam.sourceforge.net/eviacam.php [2] http://sourceforge.net/projects/eviacam/#screenshots [3] http://en.wikipedia.org/wiki/Wxwidgets [4] http://wxwidgets.org/ -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
