MyStyle database.
Sasha_Vasko@osca.state.mo.us
Fri, 5 Feb 1999 10:41:16 -0600
Hi all
As I can see from previous postings on this list, we all are deeply
touched by impeachment discussions in US Senate , and just generally
bored to death by any other way. So here is something for all of us to
chew on :
Here is my proposition :
We all like MyStyle type definitions of the various looks. Latest work by
Ethan
introduced that type of definition outside of the afterstep and into the
Wharf,
and it also moved that functionality into asimagelib.
That makes perfect sense now to convert all the various visual definitions
( like PagerImage, PagerDesktopImage, etc.. ) for different modules,
in to this new format.
Modules affected as I can see are :
Pager:
*PagerDesktopImage -> *PagerDesktopStyle
*PagerImage -> *PagerStyle
Balloons
BalloonFore
BalloonBack
BalloonFont -> PagerBalloonStyle
*PagerBack
*PagerFore
*PagerFont
*PagerSmallFont
*PagerHilight -> *PagerLabelStyle
-> *PagerFocusedStyle
-> *PagerUnFocusedStyle
-> *PagerStickyStyle
WinList :
*WinListBack
*WinListFore
*WinListFont
*WinListGradFrom
*WinListGradTo
*WinListGradType
*WinListPixmap
*WinListTextType -> *WinListStyle
*WinListBalloonBorderWidth
*WinListBalloonFore
*WinListBalloonBack
*WinListBalloonBorderColor
*WinListBalloonFont ->*WinListBalloonStyle
Wharf:
*WharfBalloonFore
*WharfBalloonBack
*WharfBalloonFont ->*WharfBalloonStyle
asetroot:
*asetrootStyle
*asetrootImage ->asetrootStyle
Zharf:
*ZharfFore
*ZharfBack
*ZharfFont ->ZharfStyle
*ZharfBalloonFore
*ZharfBalloonBack
*ZharfBalloonFont ->ZharfBalloonStyle
Scroll:
*ScrollBack
*ScrollFore ->*ScrollStyle
Ident:
*IdentBack
*IdentFore
*IdentFont ->*IdentStyle
Form :
*FormFont
*FormFore
*FormBack ->*FormStyle
*FormButtonFont
*FormItemFore
*FormItemBack ->*FormItemStyle
I believe that this common way of defining visual parameters will be
very easy to understand, adopt and use.
I personally volunteer to convert Pager in to this.
Another implication of such approach is that it makes possible to create
single file - the database of Styles. All the common styles will be defined
there.
This file then needs to be passed as command line argument to the module
when it is started. Module will then read this file first, and then read
it's own
configuration file, where module specific style definitions can be found.
As a result user needs to modify only one - main database of Styles - file
to do
changes to all components.
At the same time we'll not loose in flexibility - because user can define
module specific styles in module configuration file (I'm not sure if it is
a
good thing to do, see below),
to override anything in main database file - if he wants to.
This main Style database file - will be the LOOK file as we know it now.
To keep different look for different desks functionality in place
( which is dubious thing to do )
I propose to let user define his own look.Desk# sub-look files
As a result we'll get the following structure in the /non-configurable :
look - main look file
0_look - smaller sublook file for desk 0
1_look - smaller sublook file for desk 1
2_look - smaller sublook file for desk 2
3_look - smaller sublook file for desk 3
We'll have to add one more menu/Desktop item : Desk Specific looks
to enable user to select those sublooks on per desk basis
There are several major advantages of this approach -
1. Dynamic configuration of the whole system - When user selects a new LOOK
-
all modules gets to update it's visual information accordingly.
2. Better themification of AfterStep - main LOOK file with all the pixmaps
will
in fact be a theme. To make it even easier - we can disable MyStyle
definitions in
module specific config files.
3. Visual configuration sharing between components - same Style can be used
as
Unfocused window style in afterstep, Pager and as a button style in
WinList,
or user need to create single definition of Balloon Style and use it
everywhere.
The disadvantage of course is that we'll need to break compatibility with
old
configuration files.
Sasha.