From: <ra...@ra...> - 2001-02-15 20:55:04
|
On 15 Feb, Lyle Kempler scribbled: -> * ra...@ra... (ra...@ra...) wrote: -> > actually they arent. on first runt eh system defaults are copied to the -> > users dir - hence forth its the users copy thats read and edited. i did -> > this for simplicity. i just decided that hunting through layers for -> > config settings was going a bit far (i also wanted the ability where -> > regardless of the system settings the users settings were the same on -> > every mahcine they used as logn as they used the same settings- -> > differences in system setup wouldnt make a difference) - i knwo thsi -> > isnt what it normally is - but its not far off how e16, 15 etc. worked. -> -> Well, that makes sense, though it makes it impossible to have a -> system-enforced environment. We might need to spend more time working on that is absolutely true. i rememebr wrestling with this for a while "but what if the admin wants to enforce stuff" "how to reconcile the user wanting to do stuff and the admin wanting to" - well at the end of the day i decided the user wins. sorry admins. its really a dscision based on keeiping things simple (only one place to look fro your config) and policy - ie the user wins, not the admin - he can set defaults and thus suggestions, but not go around chaning peoples setups behind them if per chance the user hasnt changed them but has gotten comfortable with the current setup. -> this.. what I wanted was a way to have each login instance have the -> ability to have differences from a shared base config.. e.g. changing -> the background but keeping the same font style, font, borders, whatever. yeah - i thought about this.. but in the end i just came to the concept "its too complex - waay too complex - lets keep it simple" - i just didnt want to tackle this. my favorite exmaple was lets say the confg for a menu - it has entires - what if the system admin re-ordeers menus while the user is logged out- but the user has aloready re-ordered menus himselff, deleted a few, added some and renamed some - the admin renamed a few entries too - how the hell am i going to reconciple this? its sounding as complex as a set of diff's now that we use with code.. and we all knwo how if things change too much patches fail to apply... i basically decided that the scenario of handling themerging of multiple configs in layers ends up a mess and i was going tokeep it simple. unless osmeone can come up with a foolproof way of making this work without it being so hellishly complex that its bound to have nasty bugs. -> term -> -> _______________________________________________ -> Enlightenment-devel mailing list -> Enl...@li... -> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@va... ra...@en... ra...@li... ra...@zi... |