I like this change, Kim. It solves the vista issues nicely, and will continue to give us an easy way to add themes as versions change without messing up the base install folder which is, as you point out, getting a bit messy.
I also think doing something similar for calendars would be a good thing. Again, they would thus be "per user" and not require admin rights to change. Obviously, we'd have to be reading a localprefs file in the %appdata%\DQSD folder. Charlie. http://msmvps.com/blogs/xperts64 http://mvp.support.microsoft.com/profile/charlie.russel ----- Original Message ----- From: "Kim Gräsman" <[EMAIL PROTECTED]> To: "DQSD development discussions" <[email protected]> Sent: Thursday, August 07, 2008 12:34 PM Subject: [DQSD-Devel] Theme improvements(?) > Hello devs, > > I think the current theming is a little noisy--all the files are just > dumped in the install directory, and it's hard to tell which bitmaps > go with which theme, etc. > > I started a new "convention" with the Vista theme, and added it under > %INSTDIR%\themes\vista -- if every theme is a folder, it can contain > all necessary resources. Does that make sense to you all, or am I > stepping on something? > > Also, I'm considering a new method for theme selection, whereby the > current theme files are always located in the user's appdata folder, > so that a user can switch themes without needing write access to the > install dir. > > I haven't looked into this closely, but I'm thinking something like: > > // file structure > instdir\themes > Blue > // theme css and bitmaps go here... > Classic > Royale > Vista > Vista Widescreen > > // search.htm > <script type='text/jscript'> > document.write("<link rel='stylesheet' type='text/css' href='" + > buildCurrentThemeUrl(); + "'>"); > </script> > > // tools.js or simiilar > function buildCurrentThemeUrl() > { > // maybe some trickery here to detect whether a theme css is in > place, or something... > return Launcher.AppDataDirectory + "\\" + theme.css > } > > I don't know, it's not exactly clear in my head, but this general > structure would give a couple of nice benefits: > > - Themes can be implicitly named by the folder name under /themes/ > - We can enumerate the available themes by listing the folders under > /themes/ > - Themes are per-user at this point, so Admin and Kim can both use > DQSD on the same machine with different themes. > - Non-privileged users can change themes, because we're only > overwriting per-user data > > So... What am I missing? :) > > Thanks, > - Kim > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
