SEUL: Re: Config file idea

[Erik Walthinsen <omega@aracnet.com>]

> but this is where win95 and E meet.. E is WAY more configruable.. but
> as a result.. there is NO STANDARD!.. menus arent linear lists.. any
> theme can place menu items where it likes.. so to hav a foolproof way
> fo "adding" menutimes is basicaly impossible wihtotu adding abstract
> menu classes ontop of the current capabilites (eg vertical linear,
> horizontal linear, array linear etc.).. but this could eaily conflict
> with thatvere has been setup already in a theme.. its a give and take..
> ig ive people a lot morew power over their interface.. but in return i
> demand a little more knodwledge and effeort on their part for setups...
> thats is the big problem. its not a matter of how the config filesa are
> read.. but what they describe...
Point taken.  But if the capability were there, wouldn't it be possible to 
create a class of themes that specifically supports this?  In the case of 
SEUL, we would be distributing E along with a couple dozen themes.  In an 
ideal world the user would be able to switch themes in E almost as easily as 
in Winblows95, if you ignore the fact that E is many times better and more 
configurable...  As long as they are "quick" enough to deal with the complete 
paradigm shift between a complete Afterstep theme and an AmiWM theme, they're 
safe.  Some kind of ability to keep parts of the config the same and others 
provided by the them itself would be quite useful (and I saw a few other posts 
on the subject in the list from others thinking it would be a useful feature).

> install/de-istall progs could easily be ritten to add and remove menu items
> form menus.. but not in a foolproof manner.. 
There's the problem.  It's not standard or foolproof.  Each theme has a 
different structure (given), thus you'd have to be able to extract all the 
user-config data from one theme, save to an intermediate format, load the new 
theme, and re-integrate.  That could get ugly, depending on the kind of 
changes we allow the user to make.  Then again if could be an ideal solution 
if we only allow them to change the list/hierarchy of programs they want.

> 
> >> one problesm.. E is setup to doa lot of shiton startup.. emus are
> >> created and rendered (jst not mapped) on startup.. as is a lot fo
> >> shit.. so in effect.. this is waht gives E a LOT of speed..
> >> "pre-calculation" if you want to call it that.. :) i knwo what u mean..
> >> tis going to be a bitch to do.. I'll be lookig into that a while form
> >> now.. after a lot of other stuff is done first.. :)
> > 
> > That's what I thought.  I agree, there are a lot of things (like virtual 
> > screens) that fall way above this in priority.  At least you're planning on 
> > looking into it... ;-)

        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/


----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------