[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] .eap files for modules
On Thu, 09 Mar 2006 10:27:00 -0500 dan sinclair <firstname.lastname@example.org> 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.
> 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!
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)