search

dremin / RetroBar

Classic Windows 95, 98, Me, 2000, XP, Vista taskbar for modern versions of Windows
Apache License 2.0
2.78k stars 262 forks source link

Some thoughts regarding skinning #29

Open Splitwirez opened 3 years ago

Splitwirez commented 3 years ago

So I've been thinking about skinning in RetroBar lately, and had a few thoughts on how it could be improved...

  1. Having the start button's icon be an Image baked into TaskbarWindow itself is awkward for any skins that don't strictly follow the "icon with text to the right" thing 9x - XP did. This is an issue for a potential Vista skin, as well as for some potential Longhorn skins, which have the icon but no text. I'd argue that either the icon should be part of the skins' templates for the start button, or both the icon and text should be part of the start button's template (perhaps with the actual "start" string being stored in the DataContext or something, for sake of keeping the door open to localization?)
  2. Having all the skins be single XAML files in the same folder makes it very easy for two skins to include conflicting assets. This could be resolved by giving each skin its own folder.
  3. Metadata for skins. Making the change proposed in 2 would allow for this to be done via, say, an additional XML document or INI file or something like that, which could live in the skin's folder alongside the XAML. This would allow skins to version themselves, credit their authors, etc., and could also be useful for localization...again.
  4. The file introduced in 3 could also be used to offer customization options for a skin, perhaps by loading additional XAML files depending on...things in the XML document or what-have-you, which would be represented in Retrobar's GUI.
  5. The process of installing skins could be streamlined to be done through Retrobar's own GUI, rather than through diving headfirst into its install directory.
  6. https://github.com/dremin/RetroBar/issues/9

Changes 1, 2, and 6 are all things I'd be happy to help implement, I just wanted to find out what you thought before actually taking a crack at it.

As for 3, 4, and 5, well...I've been developing a somewhat comparable system for...mods for a certain game, surprising as it may sound. As such, I'm definitely not able to take those on right now. We'll see what the future may hold on that front...no promises.

dremin commented 3 years ago
  1. I'm not sure I follow why this change would be an improvement. Setting the visibility of StartLabel to collapsed in the theme removes it completely, and the icon is defined by the theme already. If a theme desires to override the layout in a way that the built-in start template doesn't allow for, the theme can override the template. By moving the content into the theme by default, every theme that wishes to override the button template would need to also define the content, which would be largely redundant.
  2. Having a folder per theme is a good idea, as it does not require trusting the theme author to 'do the right thing.' It would also open the door to number 3.
  3. Metadata is definitely needed. Another option could be string resources defined within the XAML file.

Regarding number 5, I should probably work on a real installer for RetroBar to simplify the initial installation as well. For theme installation, distributing themes as a ZIP and extracting them in the %localappdata%\RetroBar\Themes directory is the direction I may pursue (whatever is implemented will likely also be shared with Cairo.)

Splitwirez commented 3 years ago

1: Okay yeah maybe that doesn't make so much sense after all. Woops.

3: Are you sure you want to parse the entire XAML document (and implicitly assume it to be valid)...just to get the metadata? Not to mention, how would you allow for, say, localized display names in...XAML resources? And do you really want to effectively require the addition of another XAML namespace just for that?

Another thing I forgot to mention about 3. in my initial post: some kind of unique identifiers for skins. This would allow the automated skin installation to, for example, seamlessly "upgrade" an older version of a skin to a newer version, rather than resulting in pointless duplication and clutter.

Also the skin options thing. Futureproofing.

5: I couldn't agree more about having a proper installer, especially if that could take care of ensuring that the proper .NET Core runtime gets installed...and on that note, automatic update delivery would be nice as well (but let them opt-out and stay behind if they so desire).

That said...I'm not so sure ZIP is the way to go for skins - if my experience with that game modding thing is any indication, you may end up with people extracting the ZIP files and wondering what they're supposed to do with the stuff inside. I wish I knew of an archive format I could recommend...one which can be extracted by those looking to see what's inside...but not by standard Windows features or software as widespread and prone to misinterpretation as 7-zip, so as to avoid them being mistakenly extracted by those just looking to install them.

If you do go with ZIP (or anything else which supports a hierarchy, for that matter), well...watch out for this:

There were quite a few mistakes we (mostly I, regrettably) made with our "Mod Identity" system for this game, of which this is one. I don't want those mistakes to be repeated here. I'll try to elaborate further once my head is less clouded-over from vaccination side effects.

yoshiask commented 3 years ago

As far as ZIP goes, you could always use ZIP but distribute them with a different file extension. That way, the program can still use the archive but users are less likely to attempt to extract it.