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 able to be changed without a restart. we might even remove the restart menu item or move it down deep into a far flung submenu to shorten the main one - as u then dont need it as often. > > - 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! well module .eap's are now (finally) in - and the .eap is simply in the src like .png files etc. modify them as needed using enlightenment_eap and create using edje_cc. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
