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.
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.
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)
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 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.
- 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 restriction, I've stored a partial path in my test module.eap to the module.so file in there, which is somewhat useful elsewhere...
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.
- 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.
- 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.
- 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?
- 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.
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'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
intleapp.patch
Description: Binary data
moduleeap.patch
Description: Binary data
module.eap
Description: Binary data
