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
