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

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



On Fri, 10 Mar 2006 00:09:24 +0900 "David Stevenson" <david.35472@gmail.com>
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)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)