Re: Themes policy
Doug Alcorn (doug@lathi.net)
17 Aug 1999 23:16:42 -0400
Sasha_Vasko@osca.state.mo.us writes:
> I've been giving some thoughts to the matter of making theme support in
> AS as easy as possible and here is what I've come to:
I'm glad to see some direction from the core developer community.
I've been thinking about what to do for a long while, but wasn't sure
what direction to go in.
>
> 1. Overview.
>
[snipped overview text for brevity]
All this sounds very good.
>
> 2. Preparations. ( Changes to AfterStep )
>
> 2.1. Make Pager use "*PagerDesk#" MyStyle definitions by default. If user
> wishes to override it - he could still use *PagerDeskStyle in pager file.
> That allows us to completely exclude pager from theme making/using.
> 2.2. It is proposed to add non-configurable/theme subdir. When theme is
> installed it is atarred in to this dir. It will then hold all
> MyStyle pixmaps.
let's call these the "auxilary" files, not just pixmaps. See below.
> AfterStep will check this dir for pixmaps and icons , prior to
> searching PixmapPath and IconPath. look and background images can
> be copied from there into non-configurable by > theme > handler and
> asetroot copied into ~/G/L/A.
This is a good move. It is cumbersome for the theme installer to go
around modifying the PixmapPath in the base.Xbpp file. That was just
plain cludgy.
> 2.3. When new theme is being unpacked - n-c/theme dir must be cleaned off
> anything it had before.
good.
> 2.4. ~/G/L/A/themes subdir needs to be added, so user can place
> his/her theme tarballs in there,
good.
> Start menu code needs to be changed to be able to pick up files in
> that dir and add them as items in Startmenu. When user selects
> appropriet item - AS should launch theme handler with this theme
> filename as parameter.
Alternatively, the theme builder could create a normal StartMenu file
that executes the theme installer. This could be in the tarball for
the theme. Then the installation process would put this menu file in
the Desktop->Themes subdirectory. I don't think we need to actually
modify StartMenu code. It seems like there should be some solution
within the existing framework for make theme changing off the
startmenu.
> 2.5 Menu item needs to be added to run theme handler to create new
> theme. It is proposed that new theme be created with generic name of
> [theme] and placed in /tmp dir, so user can rename it and move it to
> anywhere he wishes to.
I don't understand this. Themes have appropriate names from their
creator. Unless you are talking about making a generic theme dir in
/tmp at theme building time.
>
> 3. Theme handler algorithm.
>
> 3.1. Creating the theme.
> 3.1.1. Theme handler starts with no parameters.
> 3.1.2. Theme handler creates /tmp/newtheme.afterstep dir ,
> or cleans it up if it's already there.
> 3.1.3. Theme handler reads look file, in memory trims path off all the
> filenames and saves data in /tmp/newtheme.afterstep/look file
> 3.1.4. Theme handler reads asetroot file, removes all the background records
> that are not currently loaded, trimms path off the filenames and saves
> it all in /tmp/newtheme.afterstep/asetroot file.
good so far.
> 3.1.5. Theme handler copies all the image files
> found in step 3 and 4 into /tmp/newtheme.afterstep dir.
This is why I think we should refer to them as auxilary files. The
theme should also include fonts and possibly sounds. These fonts and
sounds should also go in the ~/g/l/a/n-c/theme dir. This would just
be part of the path. I think autoexec or maybe asetroot could add
this to the user's font path with 'xset fp'. I am not advocating
installing theme fonts in the system font dir. They should be in the
user's space (Ideally dynamically read from the configured ~/g/l/a
place).
Fonts was one of the top three complaints about my theme.handler. The
other two were no startmenu support and poor mapping of multiple theme
source Wharf tiles to the installed theme's Wharf tiles.
> 3.1.6. Theme handler copies README and SCREENSHOT.jpg files from ~/G/L/A
> to /tmp/newtheme.afterstep (if any found).
> 3.1.7. Theme handler tars/zips it all up into /tmp/theme file.
> /tmp/newtheme.afterstep/ gets removed afterwards.
> If user wants to do some custom steps - he can always untarr the tarball.
>
yea.
> 3.2. Installing the theme
> 3.2.1. Theme handler starts with single parameter - theme file name.
> 3.2.2. Theme handler rm everything from non-configurable/theme or
> creates that dir.
> 3.2.3. Theme handler untars theme file in /non-configurable/theme.
> 3.2.4. Theme handler copies:
> look file in n-c/look.#bpp,
> asetroot file in ~/G/L/A/asetroot
> every N_background file into non-configurable.
> 3.2.5. Theme handler restarts asetroot module if it's residently loaded,
> 3.2.6. Theme handler sneds message to update look and background to
> Afterstep.
I guess Wharf and WinList will get the message to update when the look
has been changed? One of the big parts of a theme is the tile for
Wharf (and for many, the background for WinList).
My big concern is supporting all the ways Wharf can be configured
(i.e. the old *WharfPixmap, MyStyles in the ~/g/l/a/wharf file, and
MyStyles in the looks file). I admittedly don't know much about your
'C' parser, but you have to be pretty intelligent to handle all three
cases.
Also, don't forget about multiple instances of *Wharf within the
~/g/l/a/Wharf file. What will the procedure be for changing the tile?
That was a big gripe with the current theme.handler; was that I only
updated on instance of Wharf.
>
> 4. PS
> 4.1. It's proposed to write theme handler in C as AS module and use config
> parser to read
> look and asetroot files and to write them back (on theme creation
> step).
Again, I don't know enough about your parser. I do know that string
manipulation in 'C' is a bear. For looking through the config files
and stripping directories, reading filenames, finding files on the
filesystem; all these things are easier done in some scripting
laguage.
> 4.2. It's possible to integrate support for current theme format if
> that will be desired by users, without drastic changes to proposed
> algorithm. ( Instead of copying look and asetroot files
> theme file will be parsed, and wrote into valid look and asetroot files).
>
I rather propose a theme converter. The old format was a trial for
the first run; just to see what kindof headaches we would run into
with themes. I never claimed it would be the be-all end-all in theme
handling capability. Let's drop the old format once we convert all
the old themes to the new format.
Like I said, once we figure out exactly how the new theme tarballs
will look, I will write something that will convert the themes. Then
with my massive cable modem I will download all the themes, convert
them, then upload them again. Once the converter is written, the
batching of converting the themes would be an unattended nights work.
--
(__) Doug Alcorn
oo / doug@lathi.net
|_/
------- End of forwarded message -------