Re: [E-devel] .eap files for modules

[David Stevenson]

On 3/6/06, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:

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.

In it goes then :)
Stafford can tidy up the changes I made to e_intl if he likes - I just wanted to expose his nice function with minimum fuss there.

> 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.

OK (^_^)

> 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.

True. It would keep the code cleaner for sure. 

> * 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) :)

Ah, yes... A lack of thought there on my part.

> 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 :)

I'd be all for that.

> - 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 :)

I hope other readers haven't missed this, buried deep into my tedious email - others will surely have thoughts on this.
As a user I personally only use enlightenment_remote for re-setting my config after it gets wiped out (this is quite nice really, during development). Otherwise, hmmm. 

> - 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 :(

Restarting on the one time you change your language is not too bad I guess...

> - 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.

Fair enough!

> 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 :)

Yeah, I'll have to take a look at what I was doing there again...

Thanks!
David