Bastien Nocera wrote: >> - removing glib dependency (or at least making steps in that direction) > > Is that such a good idea? I'd rather we used it more, especially as we > want developers to be using the fprintd D-Bus service in the future, > which will be using glib in any case. What's the reasoning behind that?
I'm only talking about removing the dep from libfprint, fprintd can still use glib. The reason is that people want to run libfprint on embedded devices where glib is too heavy. I myself have an embedded MIPS device with embedded DigitalPersona fingerprint reader and a whopping 4mb of storage. It runs proprietary DigitalPersona software and is a useful device (see http://www.disbio.com/index.php?/Contenido/Control-de-Presencia.html for a successful commercial application). It would be great to replace the software with libfprint, but there is not enough room for glib. Other people ran into the exact same issues on other setups. Which features of glib are you thinking would be useful here? I initially though glib would be a major boost for development and we'd use it so much it would be difficult to remove. But actually we don't really use much at all. >> - standardising error codes >> - making driver inclusion configurable at configure-time (then >> separating out dependencies by driver e.g. only aes4000 requires >> ImageMagick) > > This should be pretty easy. See Totem's configure.in to select the > plugins: > http://svn.gnome.org/viewvc/totem/trunk/configure.in?view=markup > Look for "Movie player plugins". Agreed :) Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
