On Tue, 27 Mar 2007 14:39:12 +0200 "Jorge Luis Zapata Muga" <[EMAIL PROTECTED]> babbled:
> Hi all, i have coded several things to ecore_fb, but before doing a > commit i prefer your opinion or whishlist =) > > 1. Modules for input devices. Instead of having the input devices > exclusive (linux_input or ps2/keyboard/tslib combo), ive made an > abstraction to support input "modules" (for now they are just > statically linked - its a similar approach to what evas had on the > beginning with engines). For now we don't need real modules because > the input modules is the only module type we have. this sounds all good in principle :) > 2. More Input Devices: A while ago i coded the linux_input (event > devices) support and replace the input devices that were on ecore_fb > (tslib, keyboard, ps2) to support multiple devices (i.e two mice, > three keyboards, whatever). I've re-enabled the replaced ones, > following the module approach. sounds good again. > 3. Support for keyboard layouts, in ecore_fb the keyboard layout was > hard coded to english layout (ascii values only), with this code we > can use different layouts (spanish, french, or your own), it was coded > following the keymaps(5) idea. Ive also made a parser for keymaps (the > files you have under /usr/share/keymaps/) which will export a c source > file for now, i want to also export an eet file, but it wont be done > until my eet patch gets in. btw, where's a good place to put this > application? under /src/bin of ecore? on tests dir in cvs? well you can do an eet file - but you could just keep the keymaps parser and put it into ecore... as you already have the code :) > 4. Support for not allocating a virtual terminal (in case there's no > console attached to the fb) and code to specify which fb device to > use. that makes sense. > I still have one doubt with all of this, ecore_fb will have a lot of > flexibility (input devices, fb to use, vt to allocate, etc) so it will > fit very well for embedded/specific platforms. But we need a way to > set up the configuration for libs/apps working with ecore_fb like > ecore_evas or etk, does it makes sense to also create some kind of > configuration file with a fallback in case none exists? if so, eet, > plain text? i agree with others - some simple plain text files might be best here as it will be limited, small and used very rarely during the running of a process (i.e startup). > turran. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
