dremin
Fix the theming system!
The theming system is sort of an uphill battle.
- Undocumented
- Normal theme xamls are huge and hard to understand ( See
Windows XP BlueorWindows Vista Aero) - Retrobar just seems to expect certain keys/ids to do things (Again, completely undocumented)
- Themes can pull resources from the language file, which would not be a problem if not for how confusing it is.
- As far as I know, there's no way to ignore properties of another theme you merged with
Ex: In Modern XP Black, which uses
Windows XP Blueas a base, there was no way to explicitly ignore the tooltip's existence. I just had to remove the content to make it as small as possible. - Theme merging considers top-level objects as "whole" objects I'll explain more below
- Defining some property wrong in an object breaks the whole taskbar
I know there are more, but I haven't run into them yet. This is just from my few-hour adventure which probably should have been a few minutes.
- Theme merging considers top-level objects as "whole" objects File 1:
<Style TargetType="ToggleButton" x:Key="StartButton">
<Setter Property="Property1" Value="A" />
<Setter Property="Property2" Value="B" />
</Style>
File 2:
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="File 1.xaml" />
</ResourceDictionary.MergedDictionaries>
...
<Style TargetType="ToggleButton" x:Key="StartButton"> (This is a "top-level object")
<Setter Property="Property2" Value="C" />
</Style>
Property A will not be set in this case, even if it was defined in File 1, because it got "replaced" in file 2, instead of merged. Merging should be an option.
Yes, it is.
- Undocumented
I don't think the "theming system" needs "documentation" because there is no system, maybe the basic things like how to design buttons or change the taskbar background, after all the ability to work with XAML is what most designers turn off to start designing because it is not that practical or comfortable to work with, that's why some designers have to set this as a challenge for themselves (a really wild one if you ask me), but that's what we have for now, and has a good point, nice vector graphics, plus we didn't actually make or develop this markup language, it was Microsoft. If you need documentation, you can check the System.xaml theme file to see what the default behaviors are, and go to the Microsoft site to read what XAML is and how it works.
Here: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/xaml/?view=netdesktop-6.0
- Normal theme xamls are huge and hard to understand... See Windows XP Blue...
This is quite a challenge, but we had no complaints (at least not publicly, except from me) when we were working on the variants, and not only dremin and I were the only ones working on the themes, people from all over the world contributed as well! But here's the place to listen to your suggestions, good ideas are welcome, but code to fix the problems is definitely better!
- Retrobar just seems to expect certain keys/ids to do things (Again, completely undocumented)
As before, you can check the first lines of a modern theme, like Windows XP Blue, and notice that there are backgrounds, the keys, the buttons are there, you can take what you need and also take them as an example.
Themes can pull resources from the language file, which would not be a problem if not for how confusing it is.
Keys marked as String in the XAML language file can be used and referenced as StaticResource/DynamicResource in the themes that use them, perhaps you need to clarify what you mean by confusing.
- there was no way to explicitly ignore the tooltip's existence. I just had to remove the content to make it as small as possible.
Yes, I've seen that, all you have to do is set the Visibility property to "Collapsed", if there's something that can annoy you, just collapse it, like this!
<ToolTip x:Key="StartButtonTip" Visibility="Collapsed" />
Theme merging considers top-level objects as "whole" objects Property A will not be set in this case, even if it was defined in File 1, because it got "replaced" in file 2, instead of merged. Merging should be an option.
Well, that's not how XAML 2006 works, but indeed I would like to be able to inherit properties like that too, what you can do is rewrite them for the theme that needs them, this is the workaround we have until we can switch to a better theming engine.
If there are pieces in the parent theme that are StaticResource/DynamicResource, you can glue them together and reuse them in your theme that inherits them.
- Defining some property wrong in an object breaks the whole taskbar
Yes, XAML is not fault-tolerant, and we probably can't change that.
- Undocumented
- Retrobar just seems to expect certain keys/ids to do things (Again, completely undocumented)
I admit these are practically the same, the complaint I'm making is asking for the Keys and default behavior of retrobar to be documented, mostly because a 1,500 line file is not something I rlly should be reading in order to make a theme. Also, I have tried and failed to sift through the vista theme, but gave up and used XP blue instead.
Themes can pull resources from the language file, which would not be a problem if not for how confusing it is.
Well, I mean, neither StaticResource nor DynamicResource exactly convey the thing I'm looking for is in a completely different file...
As for the rest of these, then just why XAML? A small XML parser could be much, much easier to work with (& smaller in theme filesize as well), if the structure is actually made properly. That sort of thing could fix just about every issue I have with it, +QoL specific to retrobar.
I feel compelled to chime in here, and I apologize if I'm being out of line at all. As one who uses and loves RetroBar and who finds that it actually increases my productivity and reduces my frustration when using my computer for productive things, I just want to express my appreciation to the volunteer developers that have contributed to making it as useful as it is.
I am disappointed to see one submit an issue in the form of a complaint the criticizes those volunteers, and seems to demand that they change their ways. This sounds like the kind of thing that would be submitted by a paying customer to a team of developers who are payed. And on top of that it seems to be expecting/demanding that those developers spend a considerable amount of time "fixing" a problem that doesn't even address the usability of the system, but would allow for a more convenient user experience to adjust the aesthetics. Perhaps some see RetroBar as a purely aesthetic thing, but to me it is a productivity enhancer, and like I said a frustration reducer.
I would strongly encourage the person who submitted this issue (along with anyone else) to be a little less expectant that volunteer developers allocate their "free" time in accordance to what that person deems of highest importance. Yes, this is the place to submit requests and suggestions, I'm just frustrated to find one made with a tone of entitlement like this. Not to be too blunt, but if somebody feels the need to be so critical, then "fix it yourself" seems like an appropriate response from my perspective.
As complicated as this program is, and as many things can go wrong trying to make it work across multiple versions of Windows to attempt to provide a seamless experience for all of the users for free, I would hope that the volunteer contributors aren't ever put into a position where they feel the need to shift their priorities just to appease the demands of some who find the need to express criticism.
If I have misread the tone here, I apologize, and it's not my intent to fan any flames at all. I just want the volunteer contributors to know that their efforts are greatly appreciated, no matter how impossible it may be to make everyone happy performing a largely thankless job.
I commend the contributor that took the time to even respond to this (and so thoroughly too). My hope is that it doesn't seem to them as though the only voices speaking are critical ones.
- Make theme
- Hm, that sort of sucked. That could be better
- Make github issue, list of things I had issues with
- Exactly how I would like to receive an issue, simple & straight to the point
- Contributor largely agrees but says it's mostly due to the system they're using
- Not really a good way to ask why they're using the system without sounding expectant, but just do my best anyways since it's late
- Receive essay-form morality lecture
I didn't just "fix it myself" because I wouldn't even know where to start. I don't know C# or how this program works in the slightest, so there are zero starting points. I did just enough research that I knew it was possible to do what I was asking, and I did consider "doing it myself", but I ended up sort of staring at the retrobar source somewhat blankly. Not even sure what loads this or where, so I just went to bed.
Thank you for the feedback! I agree that the documentation can and should be substantially better. I just haven't focused on that yet, unfortunately.
As far as the system itself is concerned, it worked well for the built-in themes, but I agree it is not great nor a stable interface for custom themes. I don't really see that changing in the near future (at least by myself--contributions are always welcome). Once RetroBar is more feature-complete (i.e. custom toolbars, XP-style task grouping) it will be a lot more feasible to implement a stable custom theming interface.
