gtk1 themes for repository

Forum: Themes
Topic: gtk1 themes for repository
started by: mikshaw

Posted by mikshaw on Oct. 14 2006,14:08
I recently downloaded a small pile of non-pixmap gtk1 themes that work in DSL, and I'm looking for some feedback on what the most useful method of packaging would be.  They will be packaged as gtk1-themename.tar.gz and install into /home/dsl/.themes so they can be automatically found by switch.dsl and be edited by the user.

The fact that they'll install into ramdisk (and the fact that I tend to want no more files than necessary installed at any given time) makes me want to package them individually.

The thing I haven't decided on yet is how to handle the engines.  Some themes require particular theme engines.  Having the engine included with every theme that requires it is wasteful, so there are a few options on my mind:

Option 1: Include the engine with the theme that was originally released with the engine.  This will require each additional theme that needs an engine to have its module_path point to the original theme's directory.  This is the method I'm currently using on my system. It's quite portable, and is pretty close to the way the original theme packages are set up.  The module_path for each engine-dependent theme also includes /usr/lib/gtk/themes/engines so the theme can be used if you already have switch.dsl installed (and if the required engine is actually included in switch.dsl).

Option 2: Release the engines as a separate package or packages, installed into /home/dsl/.themes or as a uci.  Each engine-dependent theme will have the same module_path regardless of what engine it uses.  If the engines are released as a uci, it will need to remain mounted for as long as gtk apps are being used.  This method was the first thing I tried, but personally I think it's a little messy.

Option 3: Release theme packs, with each pack including all themes that require a particular engine. This method is my least favorite, although I know many people like packs.

Option 4: Release everything as one package.  This would be convenient as a uci, but as I said before it would need to remain mounted permanently and I tend to prefer not installing things I have no plan to use. This also means the themes are read-only.

Option 5: Release both a theme pack and individual themes. This would be a combo of two of the above options.

Any feedback on the pros/cons of these options, additional options, or any other ideas are welcome.

Thanks for reading.

Posted by nickelplated on Oct. 14 2006,16:33
How many different engines are there?
Posted by mikshaw on Oct. 14 2006,20:02
I have 13, but I'm sure I don't have all of them.  So far I've tested 30 themes that work in DSL, only a few of them do not rely on an engine.
There are still a handful of themes I haven't tested yet, and probably more I will want to download.

The .themes directory including the engines is currently 279k compressed as a single tar.gz file.  That's not bad at all, but I still am leaning toward a separate package for each theme.

The way I have it set up for now would state in the info file whether the desired theme requires that another theme is needed, pretty much the same way it's done at freshmeat.
For example, if you want to use XenoThin (774 bytes compressed) the way it was intended to look, you would also need Xenophilia (45k).
Keep in mind that most of these engines are also available in switch.dsl, so if you already have that you will not need to download Xenophilia separately.  I just don't like switch very much, so all of the themes supplied with that package will also be available as individual packages.

Posted by nickelplated on Oct. 15 2006,02:28
Man, that's a lotta engines.

Personally I think that keeping everything separate is a good thing as far as keeping things damn small. Especially when there's that many things you may not want. Though I've never much cared for extensions that have other extensions as dependencies, as I've had problems with that before, just not noticing there was a dependency.

Would it be possible to include an if statement in a wrapper script to test for the presence of the engine before attempting to load the theme? So that if it's not present it could wget it or at least let you know that it's needed?

Posted by mikshaw on Oct. 15 2006,03:56
gtk themes are handled entirely by gtk...nothing more i can do beyond including an appropriate module_path in each theme file.  If you're talking about a check during the download or installation process, that is also not a possibility. The MyDSL system is very downloads and installs the desired package, and that's it.
As far as gtk goes in dealing with missing theme engines, it sticks with the default gtk widgets but still uses the theme's colors and fonts.  A missing engine doesn't mean the theme will not just won't look entirely as intended.

In any case, the info file will clearly state which engine is needed, if any, and I will be sure to submit only themes using engines that are already available through myDSL.
I'm also hoping to find more themes that use only the default gtk widgets.

Posted by nickelplated on Oct. 15 2006,08:19
I meant a check at the time you click the menuitem to implement the new theme, after installation is complete. But I guess it wouldn't really matter much either way if the worst case scenario of a person forgetting the engine would just be using some default widgets.

Though something occurred to me..if a person's just casually going to be looking for some new eye candy, are they really going to be motivated to individually install all 30 themes just to find one they want? Perhaps a good way to do it would be to have a big uber-package of all of them for your casual eye candy hunter AND individual extensions for each one, so when a person finds the theme they want they can go back to mydsl and get just that one and discard the uberpackage, thus keeping their system a nice small size.

Posted by mikshaw on Oct. 15 2006,13:47
I meant a check at the time you click the menuitem to implement the new theme
well, that COULD be done if I was using the menu/icon to apply a theme, but I'm not.  That would require writing a tool that is already available as switch.dsl (which also previews the theme and applies the changes to currently opened applications).  If you do not want to use switch, applying the theme is a simple matter of either including the theme from within ~/.gtkrc or replacing ~/.gtkrc with a link to the theme.  Some things are just too simple to spend extra time and effort making them more click-friendly =o) (and filling up the menu/desktop with multiple objects).
Gtk2 themes would be a different story, but so far I dislike the process too much to even bother with gtk2 themes. They dropped the module_path specification for some reason, so engines must be installed to a particular directory...kinda dumb if you ask me, moving backward in flexibility while increasing the system demands. And Gtk2 isn't even an improvement visually as far as I'm concerned...but that's a rant for a different thread...

Your suggestion of the uber-package is one I'd considered, though I hadn't thought about the users' motivations beyond mere convenience.  Maybe it would want a small screenshot included for each theme, or one shot containing all themes, to ease the decision making process.

I'm still hoping to find out what the issue is with Gtk's pixmap engine in DSL, considering most available themes use it.

Posted by mikshaw on Oct. 16 2006,04:11
Have now found 48 decent themes that work in DSL, not including the handful that are so similar to the default that they aren't worth packaging, and several that just didn't appeal to me. Still have had no luck getting the pixmap engine working, and haven't found any useful info online.  Themes that set pixmaps directly seem to have no trouble, so there must be an issue with DSL's Gtk....maybe one or more libs was compiled without pixmap support?
In any case, most Gtk themes available online use the pixmap engine, which makes finding good themes for DSL a bit of an annoyance.

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.