Hi,
On 2024-12-30 21:58, Nate Graham wrote:
On 12/30/24 12:31 PM, christ...@cullmann.io wrote:
On 2024-12-30 18:51, Nate Graham wrote:
I see an opportunity to move closer to that here. So my preference
would be to implement the proposal, but also:
- the default window decorations remain in Breeze
- the default colors remain in Breeze, and are removed from
KColorScheme
I think that is no good idea, that makes then Breeze even mandatory if
an application just wants to have dark mode.
Breeze is already increasingly being made mandatory in our apps, right?
Our apps need to have *some* theme available.
At the moment at runtime, icons are a compile dep for icon themes.
- breeze-icons is merged into Breeze
Like above, not sure about that. Even if one can just build and
install parts that seems to me like we will have some 'super
framework'.
I think colors and icons are decoupled enough, users are even allowed
to change them and I fail to see the large issue in having them in
different repos.
It's not a huge deal, but I think it's nice to have a complete theme in
one git repo so it's clear where to make changes and what needs to be
replaced once we change the default theme.
Put another way, if Breeze and Breeze Icons are both frameworks, and
both mandatory, and both full of Breeze assets, I don't see a
compelling reason *not* to merge them.
I am all for having a framework I could depend on and that fixes all my
theming issues, but I am not sure that will work out well.
e.g. the icons are tier 1, I doubt that breeze style will be that.
At the moment to at least work, one can link to the breeze-icons and
kcolorscheme and be happy, if we need to require Breeze that will be a
lot more deps.
But perhaps I am confused with that.
Would kcolorscheme then depend on breeze? Without it, it would be again
back to more or less useless as it ships no proper color scheme nor will
the
dark mode switching work.
Same for kiconthemes, that relies on that to work with just kcolorscheme
& breeze-icons.
Greetings
Christoph
Nate
