[as-devel] Re: Themes policy
Ethan (allanon@crystaltokyo.com)
Wed, 18 Aug 1999 11:49:37 -0700 (PDT)
On Wed, 18 Aug 1999 Sasha_Vasko@osca.state.mo.us wrote:
> 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 :)
Aha, but I sneakily provided for just this eventuality. This can easily
be done by .include files:
include "~/GNUstep/Library/AfterStep/themes" Exec installastheme
> >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.
This one is tricky, yes. Perhaps we should have a module class as well
as the current module name. In general, modules use MyStyle's with names
like "*Module", where Module is the module name reported to AfterStep.
So, figuring out what styles are currently in use is easy. Figuring out
what styles will be in use when the theme is installed is harder, and
that's what a class might be useful for. Class would simply be the
module name (Wharf, Pager, WinList, etc), no matter what the name of the
executable is.
> >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.
And to me. Now, if it were only in XML... ::ducks:: :)
Here's a possibly controversial idea: perhaps we should disable
backwards compatibility code in the devel version, to encourage people
to create new-theme-handler compatible themes? They can then be turned
back on via a compile time flag (which is by default off) if the user
really wants/needs compatibility. If we do this, though, I'd want to
keep the ETA for 1.8 as short as possible.
----
Ethan Fischer
allanon@crystaltokyo.com
http://members.xoom.com/allanon1