Re: Themes policy
Sasha_Vasko@osca.state.mo.us
Wed, 18 Aug 1999 09:35:11 -0500
Lathi wrote:
>Sasha_Vasko@osca.state.mo.us writes:
>> 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.
Unfortunately there are no currently a mechanism. This thing will have to be
coded in, and I think I know who 'll do that - our friend Ethan :)
>> 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.
When you create the theme tarball, you have to put it somewhere.
I don't really want to ask user to provide me with filename and path,
so I need to use some generic filename and path.
I see two alternatives for path :
$HOME and /tmp
The home dir does not look like a good place to use, as we can inadvertentlty
overwrite some user file that is called "theme", at the same time /tmp looks
like a good place to use.
I 'm not a big specialist in Unix security and infrastructure of large multiuser
systems,
so maybe somebody else will be able to comment on that, and may be
propose better place.
>> 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).
Yeah, I havenot thought of that. Fonts sure are important. I guess we can have
non-configurable/theme/fonts dir, and AfterStep itself would have to do 'xset
fp'.
>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.2. Installing the theme
>> 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.
MyStyles definitions withing the wharf, winlist, etc files will be lost.
That is also a good thing, as it provides user with the way to override
some particular aspect of the theme. Like for instance - I want the theme,
but I don't want my Wharf tile changed.
WharfPixmap will not be supported
>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.
As all the tiles for them will be defined in look - they'll get included in the
Theme automagically. Problem is that user may want to use some wierd
names for it's other wharfs - in that case we are in trouble. Theme handler
will not only need to copy look file, but also filter out and change Wharf
styles names, and I don't see a safe way to do it without user intervention.
As you don't know which styles is used where.
Well, actually I do see a way. On the Theme making part , theme handler
will have to change all "*Wharf" style names into something like "*Wharf_N"
and then when installing theme we will have to change it back. Of course we'll
need to query what Wharfs are running, while creating the theme, which makes
it next to impossible to implement it in scripting language, and will probably
need
to add one more command to afterstep.
>>
>> 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.
It will be very easy task if we'll go with parser, as there already be a code
for
reading/writing config files and all we have to do is go through array of
simple
structures and trim everything before last '/'. And in the same time it provides
several advantages, like it makes theme handler independent of config
file format, and it allow us to process same actual meaningfull data that
afterstep is using, and not some faceless regular expressions.
>> 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.
sounds good to me, as most complicated parts of new theme format will
be missing in old themes - fonts and multiple wharf/WinList/Pager tiles.
> (__) Doug Alcorn
Sasha