[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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