On Sun, 19 Feb 2006 16:04:09 +0900 "David Stevenson" <[EMAIL PROTECTED]> babbled:
> Greetings, > > I've been playing with some ideas for how modules might be able to have > their own eaps (there is a TODO item for this + it would also fix some minor > issues with i18n in modules), and am looking for some comments. > > Here are two patches > 1) (intleapp.patch) Minor fixes for localized eapps > > Currently e_apps.c uses LANG to look for localized strings in the eaps, but > LANG may have an encoding value on the end of it (e.g. ja_JP.UTF-8), while > the eap file might contain an a "name[ja]" value, or "name[zh_CN]". This > little patch will improve that situation. most good. yes yes. definitely. > 2) (moduleeap.patch) Proposed changes to support module .eaps > > The e_module_new and e_module_find functions use a "name" arg which > corresponds to the name of the dir the module was installed in. But modules > might like to have their "name" localized, or even simply displayed with a > Capital letter, i.e, instead of "clock", display "Clock" in English or > "tokei" in Japanese. yup. that's why name and "label" should be separated. the module name should stay as is - a canonical name always the same, but the DISPLAY of the "name" (title, label) should be translatable :) > So instead of getting a list of names (for the e_module_* calls), a list of > paths (for the icons), and a list of localized names (for the widget > labels), I've tried to add E_App based API calls to e_module, for use by > e_int_config_modules. > - e_module_available_list (return a list of E_Apps, one for each installed > module - I added a check here to make sure that the module.so actually > exists so that uninstalled modules are discluded) > - e_module_icon_get (return the .eap icon if it's there, otherwise fall back > to the existing module_icon.pngs) let me look at this - but this is defintiely the way to go. > Briefly, these changes support modules with a "module.eap" file in the > module's directory, and those modules that don't have an eap in that > location have a dummy E_App created for them (just in RAM). i'm tempted to say that if the moduel has no .eap - it should be just not listed - enforcing some sort of consistency and "good design" by modules (to provide a proper label, icon, etc. etc.) woudl be good imho. > * I bumped the e_module.h E_MODULE_API_VERSION because I added an E_App to > the E_Module struct. 3rd party modules will be rejected, but just rebuilding > them will be sufficient to get them working again. true. :) > - issue: E_App abuse. some of the stuff I've put in E_App fields is pretty > damn dirty > 1) e_app_new (currently) requires a value to be present in the .eap file exe > field or it'll return NULL instead of a new E_App. Rather than loosen that correct :) > restriction, I've stored a partial path in my test module.eap to the > module.so file in there, which is somewhat useful elsewhere... hmm - not sure that's useful - as the module may contain .so's for multiple architectures (eg amd64 may contain an i386 and a amd64 .so - if you share your homedir on nfs between multiple arch systems u may have a ppc, i386, amd64, sparc, etc. etc. etc. module .so... that was the idea of the subdirs for module.so) :) > 2) the dummy E_Apps for modules without .eap files is one case - maybe not > such a big deal as the idea is to move to eaps or some other data file > anyway. i would personally think just removing this code would be the way to go - ship a module.eap - or don't get loaded :) > - issue: it would be nice if an E_App could be directly associated 1-to-1 > with the corresponding widget, but I've not found a way to do that yet. Thus > currently the new stuff walks lists doing string comparisons on the widget > label and the name in the E_Apps to find the right one. the problem is an eap may have multiple associations. a border, multiple menu items, buttons in ibar etc. etc. the walking isnt too bad right now imho. > - issue: there may be issues if users try to use enlightenment_remote > -module-* while using the config dialog at the same time - this stuff still > needs more testing in that area. yes. a LOT of config has that problem. i am wondering what we should do about it. despite the effort with e_remote - i am beginning to think - to reduce code size and maintenance - of literally removing e remote calls if they are fully implemented in a gui. i know people will cry and moan - but having to implement a gui AND ipc code for all config options is a lot of work. many new options have no ipc as they go direct to a gui. i am thinking that just to save us all work - remove the ipc config stuff. in fact just remove e_remote... yes people will complain - if we didn't have an open development process they wouldn't. people seem to hate change - even if they use cvs and know its subject to change - INCLUDING removal of things. anyway - in removing the ipc, we also remove all the code needing to handle if/when the modules are screwed with from elsewhere etc. making e 1. more maintainable, 2. less liable to have bugs, 3. smaller, 4. faster to develop for. i am ONLY proposing we remove the ipc handlers for stuff that *IS* fully implemented in a gui. then it acts also as a todo list of things we need to still add a gui for :) > - issue: More generally with E_Apps, similar to the problem with module > menus not updating to reflect the user's language (on a change) E_Apps might > need a way to have their strings refreshed? yeah - all objects only get their language evaluated on creation. any changes after creation are not seen :( > - issue: module.eap creation. Not sure about how all the localized values > would get into the module.eaps in the first place. I've not given much > thought to this, but one idea I had would be to build or at least modify the > .eap file at install time, using a little c program which could refer to a > previously installed message catalog, and insert localized strings for any > languages found... somehow I think it'd be nice if the .po files could be > used for this. it should be - but a fair bit of work. for now i'd be happy just with module.eap's created at build time (using enlightenment_eap and edje_cc) and manually editing a template file that is used. > Finally, I'll also attach a clock module .eap which I have been testing with > (put it in <prefix>/lib/enlightenment/modules/clock/ ). It contains the > following: > > $ enlightenment_eapp -get-name -get-comment -get-exe module.eap > Clock > Display the <hilight>time</hilight>. > clock/linux-gnu-i686/module.so i would simply fill the exe with a dummy value - like "clock" myself :) > I'm probably failing to see the forest for the trees at this point, so I'd > love to hear some of the esteemed opinions of the e-devel readership. > > Regards! > David > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
