Consider making Fluent and Default theme a separate NuGet package

[Takoooooo]

Is your feature request related to a problem? Please describe.
At the moment if you will create an application on Avalonia and build it you will have Avalonia.Themes.Fluent.dll(~5.5mb size) in build output even when you don't use it.
Also, I think would be nice to ship the Default theme also as a separate NuGet package because in the case when you use e.g only Fluent theme you will also get the Default theme(~0.4mb) in build output.

Describe the solution you'd like
I think it would be ok just to get it as NuGet package

[kekekeks]

Also, most of that 5.5 mb dll is fonts

[rstm-sf]

I also don't understand why I need a default theme in the output

[Splitwirez]

Would I be pushing it to suggest doing this to both themes?

[Takoooooo]

Would I be pushing it to suggest doing this to both themes?

Yes, you`re right. For those people who use only e.g Fluent theme having a Default theme in the build output would also be overhead

[MarchingCube]

It would also help for people that don't use either theme :)

[maxkatz6]

It would be good to have themes as separated package included in the default templates. With some build-in templates required to show anything (like Window/UserControl templates).
But it will be big breaking change, that will affect every current user unfortunately.

[maxkatz6]

Also DevTools needs to be updated to work with any theme available.

[BreyerW]

You cant use trimming feature since it requires too new runtime right?

[MikeCodesDotNET]

I agree with the idea as I've often thought it'd be good to provide a few more theme options (perhaps through promoting community themes). In an ideal world, having a theme for each of the supported operating systems.

Android could us the Material theme.

I'm working on a Big Sur theme which would cover macOS.

Linux is obviously a little more difficult due to the variety but a generic GTK/KDE theme could still be useful.

Obviously these themes shouldn't be included in the core library, which then brings into question the decision to have the fluent theme built in.

With that said, we need to keep a good first run experience and so I support the idea of removal but with the intention of adding the a fluent theme package to the default templates. People playing with Avalonia won't notice any difference but this change enables devs to completely forgo Fluent if it's not needed.

[Splitwirez]

I agree with the idea as I've often thought it'd be good to provide a few more theme options (perhaps through promoting community themes).

I wholeheartedly agree with this.

In fact, making it easier for developers to let users choose (or better still, create) app themes (not just colour schemes, actual themes) would be awesome, but I'm pretty sure that's beyond the scope of the GUI Framework itself...lol

In an ideal world, having a theme for each of the supported operating systems.

Android could us the Material theme.

[...]

Linux is obviously a little more difficult due to the variety but a generic GTK/KDE theme could still be useful.

@MikeCodesDotNET bold of you to assume Linux is the only platform where the look and feel is user-customizable - if nothing else, that unofficially also applies to Windows. Wouldn't surprise me if it's also true at least to some extent for the other platforms Avalonia can/will target.

That said...I once went down the route of merely mimicking each platform's default, much like what you're suggesting. I firmly believe we may be able to do better...much better.

I've been experimenting with the possibility of using platform-specific control rendering within Avalonia's existing, unmodified styling system. Here's a look at some initial results:

All of this was done with standard, unmodified Avalonia. It didn't require any changes to the styling system or any other part of Avalonia itself, and was implemented as a custom control and a handful of new control templates. Admittedly, the code I wrote was dependent on winforms, but this is NOT necessary - the winforms functionality I used merely wraps regular unmanaged Windows APIs, which could be used instead, to avoid depending on winforms. The only reason I used winforms at all was because my understanding of the Windows APIs in question is...insufficient. EDIT: Just got it working without the winforms dependency. Weird timing, lol

I've yet to look at actually implementing this for Linux or macOS, but there's strong evidence that it could be done there as well, as evidenced by the existence of the -moz-appearance CSS property in Firefox-based browsers.

Not only that, but for Linux, there's even a Qt theme that renders the system GTK theme in Qt apps. Who's to say an Avalonia theme couldn't similarly call into GTK?

EDIT: Ok yeah, GTK is most likely within the realm of possibility...super buggy progress image:

[MikeCodesDotNET]

@Splitwirez, please accept my apologies for the delay in responding to your comment. There was a lot to unpack! I try my best to give my opinion on the points you've raised. To clarify one thing before I start, when I speak of development work, I'm generally talking about the community producing these things and not the core Avalonia team.

In fact, making it easier for developers to let users choose (or better still, create) app themes (not just colour schemes, actual themes)

Perhaps I do not understand correctly, but it's my view that developers already can do far more than tweak colours. Because Avalonia controls are lookless, which mean we can make them look however we want. This is how we've got a beautiful Fluent theme that is very different from the old default. It's also how I can produce a 'theme' that mimics macOS without modifying Avalonia.

bold of you to assume Linux is the only platform where the look and feel is user-customisable - if nothing else, that unofficially also applies to Window

Supporting the weird world of Windows theming would (in my view) be a massive waste of time. I recognise the argument for an aero theme and perhaps even Windows Classic, given that both are supported on Windows 7, which still accounts for ~16% of Windows installations. The Windows 7 install base has shrunk 8% in the last 12 months, suggesting that this work shouldn't be a priority as the market share continues to shrink.

That said...I once went down the route of merely mimicking each platform's default, much like what you're suggesting. I firmly believe we may be able to do better...much better.

My thinking has continually been, "what low-hanging fruit exists that can help support and grow the community?" and 'mimicking' a platform offers is a low-hanging fruit that several immediate advantages. The most significant benefit is this work can be achieved with Avalonia as it is today. I imagine your thoughts on doing "much better" would require reworking parts of the Avalonia, which would require numerous discussions and agreement before work could begin. By creating themes that mimic the platforms, we can ship themes today, and the conversations can start in parallel.

A secondary benefit of mimicking is that the community already has the necessary skills to be involved in this process. It also uses their existing experience of working with the default and fluent themes.

So while I'm not against throwing my opinion into the ring regarding a potential theming API, I believe my time is better spent right now working with the existing styling mechanisms.

I've been experimenting with the possibility of using platform-specific control rendering within Avalonia's existing, unmodified styling system. Here's a look at some initial results:

I'm REALLY not understanding what's happening here and would love to learn more. What exactly are you doing, and do you have some code you could share?

[Splitwirez]

@Splitwirez, please accept my apologies for the delay in responding to your comment. There was a lot to unpack! I try my best to give my opinion on the points you've raised. To clarify one thing before I start, when I speak of development work, I'm generally talking about the community producing these things and not the core Avalonia team.

@MikeCodesDotNET No need to apologize, lol

Perhaps I do not understand correctly, but it's my view that developers already can do far more than tweak colours. Because Avalonia controls are lookless, which mean we can make them look however we want. This is how we've got a beautiful Fluent theme that is very different from the old default. It's also how I can produce a 'theme' that mimics macOS without modifying Avalonia.

You're technically 100% correct...but that's completely irrelevant - I was talking about the end users of the programs those Avalonia app developers create, not just the Avalonia app developers themselves.

Supporting the weird world of Windows theming would (in my view) be a massive waste of time. I recognise the argument for an aero theme and perhaps even Windows Classic, given that both are supported on Windows 7, which still accounts for ~16% of Windows installations. The Windows 7 install base has shrunk 8% in the last 12 months, suggesting that this work shouldn't be a priority as the market share continues to shrink.

As someone who uses and has created unofficial third-party Windows visual styles, I strongly disagree. Also, the Classic Theme has a few users on Windows 8 and 10, in spite of the Classic Theme's supposed removal - it's not gone at all, there's just no longer a built-in way to activate it system-wide.

You can never stop 100% of people from tinkering with software as they see fit. The most dedicated among them won't back down, except maybe if thrown in jail for it (and as far as I'm concerned, you're a monster if you'd actually throw someone in jail for re-skinning a program to make it look better in their personal opinion). I don't blame them one bit, either - I view it as their moral right to be able to do so. I'm not saying we're obligated to facilitate their tinkering, just that we're obligated to not strive to stop them. That said, I absolutely would argue it'd be a nice thing to do to facilitate such "skinning" efforts, but I've now realized that that's well beyond the scope of this issue post, so...shelving that topic for now.

My thinking has continually been, "what low-hanging fruit exists that can help support and grow the community?" and mimicking' a platform offers is a low-hanging fruit that several immediate advantages.

Makes two of us. Most of my PRs to Avalonia itself are applicable to such "low-hanging fruit"...albeit less about growing the community and more about tasks trivial enough that I can actually take them on without breaking literally everything, lol

The most significant benefit is this work can be achieved with Avalonia as it is today. I imagine your thoughts on doing "much better" would require reworking parts of the Avalonia, which would require numerous discussions and agreement before work could begin.

And that's where you're completely and utterly wrong. More on that below.

By creating themes that mimic the platforms, we can ship themes today, and the conversations can start in parallel.

This statement is technically true, but I don't see why it wouldn't also apply to a system-drawn theme such as the one I've been working on (again, more on that below)

A secondary benefit of mimicking is that the community already has the necessary skills to be involved in this process. It also uses their existing experience of working with the default and fluent themes.

So while I'm not against throwing my opinion into the ring regarding a potential theming API, I believe my time is better spent right now working with the existing styling mechanisms.

Given my approach, this "theming API" would fit straight into Avalonia's existing styling system, no changes needed. (and by "would", I mean "is already starting to"). More on that juuust below here.

I'm REALLY not understanding what's happening here and would love to learn more. What exactly are you doing, and do you have some code you could share?

Yes, here's the experiment's repo: https://github.com/Splitwirez/avalonia-system-theme