Extending material.Palette

Message ID
DKIM signature
Download raw message

I'm currently building a chat app using gio and was thinking about
introducing support for a dark theme. Now I obviously have to use more
colors than I can store in material.Palette which makes this harder than
just changing the material.Theme and rerendering everyting.

I could introduce my own, extended Palette type and pass it around.
However I think allowing material.Palette to hold more colors is a much
better course of action (since I am already passing around

However, I am not sure how to do it best. The material design
specification explicitly talks about primary and secondary colors, so
adding SecondaryBg and SecondaryFg to Palette would be one way to do it.
But two colors in the Palette are probably not enough for a lot of
applications either. This could be fixed by adding something like a
map[string]color.NRGBA to palette, thus allowing the developer to add as
much colors to the palette as needed.

I think adding additional colors to material.Palette will make
developing applications using Gio much easier. If this is something that
would get merged, and if we can find a good approach to do it, I would
be happy to implement the changes.

Message ID
<C83M952HQ5V9.2OBJ4AGUWFO9F@FABIANS-Workstation> (view parent)
DKIM signature
Download raw message
Hi Fabian,

The story around color management within Gio is still unfolding. We
agree that the current palette, by itself, is insufficient for complex
applications. See the commentary on the patchsets that introduced the
palette type for some of the rationale behind the current approach:

- v1 https://lists.sr.ht/~eliasnaur/gio-patches/patches/14880
- v2 https://lists.sr.ht/~eliasnaur/gio-patches/patches/15473
- v3 https://lists.sr.ht/~eliasnaur/gio-patches/patches/15510
- v4 https://lists.sr.ht/~eliasnaur/gio-patches/patches/15546

In essence, I originally proposed something similar to your idea, but
we decided to explore a different direction. The goal now is that we
have many `material.Palette`s defined per application, and that you
swap the one in use at any given time to match what you are currently
laying out. For instance:

var primary = material.Palette{Fg: black, Bg: white, ContrastBg:
lightblue, ContrastFg: white}
var secondary = material.Palette{Fg: black, Bg:white, ContrastBg:
lightgreen, ContrastFg: white}

When you want to lay out a widget in the secondary colors, you switch
the theme's current palette:

th := th.WithPalette(secondary) // make a local copy of the theme so
that you're not making a global change
material.Button(&th, &btn, "example).Layout(gtx)

We could certainly use some kind of meta-palette type like this:

type MetaPalette struct { // needs better name
    // fields for each material palette type
    Primary, Secondary, Surface, Error material.Palette

Alternatively, we could define a type that you express just the
material colors and then can invoke methods to generate the palette
that you need.

I am currently looking into whether we can start using non-pointer
themes, which will make it much easier to make function-local theme
modifications. Just gotta make sure that the overhead of copying the
theme isn't very extreme.

In any event, our color management is absolutely not complete, and we
welcome your thoughts on the matter!

What do you think?

Reply to thread Export thread (mbox)