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

[The Rasterman]

On Fri, 10 Mar 2006 00:09:24 +0900 "David Stevenson" <[EMAIL PROTECTED]>
babbled:

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

actually - the code is not at a stage where it almost never wipes config - just
extends - so e_ipc's usefulness is becoming dubious. for code that makes up 5%
of e17's code in 1 lump - thats a lot of code that has dubious use value when
the same features are available via the gui. the gui should also prevent users
shooting themselves in the foot - ipc doesn't. i woudln't remove it entirely,
but i'd heavily trip it down to maybe issuing restarts, exit, logout etc.
requests - feeding in actions from a script, and maybe later querying for data
that might be useful from management scripts.

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

yeah - we can live with it. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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

[The Rasterman]

On Fri, 10 Mar 2006 00:09:24 +0900 "David Stevenson" <[EMAIL PROTECTED]>
babbled:

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

well ipc is nice. it's great. the problem is - maintainability. we currently
have a lot of evil macros to hide parsing and logic handling and its a massive
lump of code that is built in a complex way to create both the
enlightenment_remote cmd-line side of things and e's side. etc. the ability to
set/get an int, string etc. is easy and can be made very generic - BUT the
problem comes when u have lists of things adding/deleting items, finding an
item by name/.id/etc. and modifying a member, lists of lists etc. the code is
long and unwieldy. we need to consider maintainability, bugs etc. - as you
mentioned - if you use e_remote WHILE a gui dialog is up - crashes are bound to
happen. adding more code to do this safely is yet more work as well as
maintaining/expanding the ipc handling. i do realise some people like it - but
the gui is the ultimate goal for config as it is something everyone can use and
understand and explore right away - once a gui does everything you can do with
e_remote - you have duplicate functionality, with ipc generating most of the
problems and being the "harder to use" and "less user friendly" way. now - what
do we do? how do we try and reduce our workload? right now the best way to do
this i can think of is to just remove the ipc to get rid of such possible
crashes/bugs and simplify our work.

i think that the way to go is to slightly expand the config profile code to
handle config snapshots and backups. most people don't know that e17 supports
profiles - multiple, at any time. you can choose the profile at start time with
a command-line option, it always uses the last used profile unless overridden
on the cmd-line. the default profile is "default". you can create any number of
named profiles and flip between them. i think the solution is to simply have
a way to make backups of "working config" or states and make it easy to roll
back/select one. even have an auto-roll-back if e finds its crashing on
startup. it should snapshot a last known working config - maybe also keep the
last N weeks  or months with timestamped copies etc. this is as simple as
archiving up config dirs and flipping to use one (or nuking a config dir and
copying the backup contents over).

this will mean any bugs/crashes etc. are automatically recoverable without need
to edit a text file or use command-line tools and hack. i personally believe
the system should be robust in and of itself without resorting to these
mechanisms (rm -rf config and restart or edit config text file or use
e_remote). we should work WITHOUT these and have a way to roll back to a known
good config - and have e automatically store known good configs.

e17's config is now able to go up a rev without nuking it - unless major
non-backwards compatible changes are made. this is during development only and
between 0.17.0 and 0.18.0 no user will lose a config as code will auto-upgrade
their config as needed. the odd nuking of config is something cvs users will
have to live with - but now it will be rare

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

though it is nice not to restart - i'd like to see more of e17 work without a
restart - and over time i think this should be a goal to have as much as
possible - if not everything, be

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

[David Stevenson]

On 3/12/06, Stafford Horne <[EMAIL PROTECTED]> wrote:
On Sat, 11 Mar 2006 23:00:05 +0900"David Stevenson" <[EMAIL PROTECTED]> wrote:>>> I'm not that familiar with locale aliasing, but for me (on Debian) it
> doesn't seem to be useful atm. I see the code is looking for> locale.aliasfiles, which I do have, but e doesn't read any of them. So> when I try a> -lang-set "japanese.euc"   I end up in the C locale.
> My locale.alias files are in> /etc/locale.alias> /usr/share/locale/locale.alias> /usr/share/gettext/intl/locale.alias> /usr/X11R6/lib/X11/locale/locale.aliasYou
could get aliases picked up by adding the base directories to your
messages path. Some day it would be nice if enlightenment could detect
these during installation.$ enlightenment_remote -dirs-list-append messages /usr/X11R6/lib/X11/locale$ enlightenment_remote -dirs-list-append messages /usr/share/locale
Nice - that works! Much easier to remember "japanese" than "ja_JP.EUC-JP"
 David

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

[Stafford Horne]

On Sat, 11 Mar 2006 23:00:05 +0900
"David Stevenson" <[EMAIL PROTECTED]> wrote:
> 
> 
> I'm not that familiar with locale aliasing, but for me (on Debian) it
> doesn't seem to be useful atm. I see the code is looking for
> locale.aliasfiles, which I do have, but e doesn't read any of them. So
> when I try a
> -lang-set "japanese.euc"   I end up in the C locale.
> My locale.alias files are in
> /etc/locale.alias
> /usr/share/locale/locale.alias
> /usr/share/gettext/intl/locale.alias
> /usr/X11R6/lib/X11/locale/locale.alias
 
You could get aliases picked up by adding the base directories to your messages 
path. Some day it would be nice if enlightenment could detect these during 
installation.  

$ enlightenment_remote -dirs-list-append messages /usr/X11R6/lib/X11/locale
$ enlightenment_remote -dirs-list-append messages /usr/share/locale

> 
> If I had installed to /usr rather than /usr/local, it would have picked up
> the file in /usr/share/locale/ though it seems.
> 
> So we would end up with:
> > * Get language from e_intl_language_get()
> > * Resolve any language aliases with e_intl_locale_alias_get()
> > * Get only the relevant parts from the locale
> > with  e_intl_locale_canonic_get()
> > * Store localized property
> >
> > What do you think?
> 
> 
> This would be more robust :-)
>
> Maybe I should cache the resolved alias for the current locale in e_intl.
> 
> 
> Indeed, we would be doing this every time we load a new e_app...

I will do that then. The cache will be removed whenever the "messages" path or 
the language is changed.
 
> Regards!
> David
> 


-- 
Stafford M. Horne
Senior Engineer 高级工程师
SurfControl plc 美讯智科技
Peoples Republic of China, Beijing  中国人民共和国， 北京
Mobile: +86 13611014044 手机：＋86 13611014044

(Website) http://shorne.homelinux.com/wordpress (网站)
N�HS^�隊X���'���u��<�ڂ�.���y�"��*m�x%jx.j���^�קvƩ�X�jب�ȧ��m�ݚ�v&��קv�^�+j�Z{az^��h��஋�n���)��{h�����ا�׫�+h�(m�Z��jY�w��ǥrg

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

[David Stevenson]

On 3/10/06, Stafford Horne <[EMAIL PROTECTED]> wrote:
David,I see in your changes that the logic is now as follows in e_apps.c: * Get language from LANG environment variable * Get canonic form for language * Store localized propertyI have a few suggestions:
 1. You could easily get the language from the function e_intl_language_get()
Actually, that code has been there since the initial revision, but
you're right, it makes sense to replace that with a fast
e_intl_language_get call. 

2. The language might a an alias (Example: japanese.euc), It would be
better to use the function e_intl_locale_alias_get() to resolve the
alias for the language(Example: ja_JP.eucJP).
I'm not that familiar with locale aliasing, but for me (on Debian) it
doesn't seem to be useful atm. I see the code is looking for
locale.alias files, which I do have, but e doesn't read any of them. So
when I try a   -lang-set "japanese.euc"   I end up in
the C locale.
My locale.alias files are in 
/etc/locale.alias
/usr/share/locale/locale.alias
/usr/share/gettext/intl/locale.alias
/usr/X11R6/lib/X11/locale/locale.alias

If I had installed to /usr rather than /usr/local, it would have picked up the file in /usr/share/locale/ though it seems.
So we would end up with: * Get language from e_intl_language_get() * Resolve any language aliases with e_intl_locale_alias_get()
 * Get only the relevant parts from the locale with  e_intl_locale_canonic_get() * Store localized propertyWhat do you think?
This would be more robust :-)
 Maybe I should cache the resolved alias for the current locale in e_intl.

Indeed, we would be doing this every time we load a new e_app...

Regards!
David

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

[The Rasterman]

On Thu, 09 Mar 2006 10:27:00 -0500 dan sinclair <[EMAIL PROTECTED]> babbled:

> >> > - 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.
> > 
> 
> Um, if we are going to remove enlightenment_remote then we need to make 
> the config system a lot more robust. It shouldn't destroy my config on 
> update (yes, I know, CVS software, but this will have to be tackled at 
> some point as once e17 is released we'll need to be able to update e 
> without destroying users configs).

the problem is that for every new item u then need an upgrade path. my plan is 
to have one - but ONLY from RELEASES. ie e17->e18, e18->e19. during cvs 
development - it is pointless to add big fat upgrade path's. i guess i should 
try make the code able to inset new config as needed though. it is possible, 
but nothing i have wanted to write a chunk of code for.

> The benefit of e_remote at the moment is that I can write a script that 
> reconfigures e as I want it. I don't care if it destroys my config on 
> reboot as I can run the script. Without that I'd have to go through the 
> tedious process of doing it through the menus.

i know - but then again -other than some over-zealous increasing of the version 
# it only happens every few weeks so i am not sure its something we should 
sacrifice long term code maintainability, efficiency etc. for.

> What does it matter if a new option doesn't have ipc yet? If someone 
> wants it, they'll add it in. They don't all have to be there for the 
> system to function.

it's not 1 thing - its the ongoing maintenance of a huge block of code. the ipc 
code is about 10% of e17's wm proper in terms of lines of code. and that's 10% 
of DENSE code ans macros compress a lot of it. the ongoing need to add 
functions, etc. is something i would be happy to see removed. ongoing 
complexity etc. etc.

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


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

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

[Stafford Horne]

David, 

I see in your changes that the logic is now as follows in e_apps.c:
 * Get language from LANG environment variable
 * Get canonic form for language
 * Store localized property

I have a few suggestions:
 1. You could easily get the language from the function e_intl_language_get()
 2. The language might a an alias (Example: japanese.euc), It would be better 
to use the function e_intl_locale_alias_get() to resolve the alias for the 
language(Example: ja_JP.eucJP).

So we would end up with:
 * Get language from e_intl_language_get()
 * Resolve any language aliases with e_intl_locale_alias_get()
 * Get only the relevant parts from the locale with  e_intl_locale_canonic_get()
 * Store localized property

What do you think?
 Maybe I should cache the resolved alias for the current locale in e_intl.

-- 
Stafford M. Horne
Senior Engineer 高级工程师
SurfControl plc 美讯智科技
Peoples Republic of China, Beijing  中国人民共和国， 北京
Mobile: +86 13611014044 手机：＋86 13611014044
N�HS^�隊X���'���u��<�ڂ�.���y�"��*m�x%jx.j���^�קvƩ�X�jب�ȧ��m�ݚ�v&��קv�^�+j�Z{az^��h��஋�n���)��{h�����ا�׫�+h�(m�Z��jY�w��ǥrg

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

[dan sinclair]

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



Um, if we are going to remove enlightenment_remote then we need to make 
the config system a lot more robust. It shouldn't destroy my config on 
update (yes, I know, CVS software, but this will have to be tackled at 
some point as once e17 is released we'll need to be able to update e 
without destroying users configs).


The benefit of e_remote at the moment is that I can write a script that 
reconfigures e as I want it. I don't care if it destroys my config on 
reboot as I can run the script. Without that I'd have to go through the 
tedious process of doing it through the menus.


What does it matter if a new option doesn't have ipc yet? If someone 
wants it, they'll add it in. They don't all have to be there for the 
system to function.


dan


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

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

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

[The Rasterman]

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 

[E-devel] .eap files for modules

[David Stevenson]

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. 

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 /lib/enlightenment/modules/clock/ ). It
contains the following:



$ enlightenment_eapp -get-name -get-comment -get-exe module.eap 

Clock

Display the time.

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