@neauoire nice, i was going to suggest the f_*/b_* labels on the table, makes it even more useful as a tool for implementing the theme ecosystem somewhere I would say.

Maybe you want to hard-code the table cell width? right now it seems to be shifting slighlty based on the numbers and symbols in each column

@neauoire Nice! You might also want to add colour-blindness filters :)

@neauoire many of the themes in the folder get poor grades :D Is there a description of the metric somewhere? i.e how it measures good bad. if someone had a bad theme, how would they improve it

@_discovery the theme displays little warnings for low contrast, the trick is just to get rid of the little warnings. That's what I'll do these next couple of days for the themes in the repo.

@neauoire @_discovery I think that one of the difficult things about themes is how they are used in different contexts. For example, when I ported the Night Owl theme there were things that looked good in Paradise but resulted in poor contrast with text in Orca.

@maxdeviant @neauoire yea it comes down to what something means. Is a button drawn with b_low or ? That will influence legibility across themes

@maxdeviant @neauoire at least the intent of the app author is held if the theme is consistent since I can define things in terms of value contrast

@_discovery @maxdeviant b_low would be for the background of a greyed out button, and f_low would be for the text.

@_discovery @maxdeviant but yeah, it's designed to be readable no matter how the app creator uses the different variables.

It's only recent that I've started to go over the apps and make them comply to these rules.

I did dotgrid today.

@neauoire @maxdeviant yea I think it’s likely if you use it as value only your contrast should work regardless of theme. but whether it looks good or makes sense for any theme will come down to consistent use as well, like med being normal, high being hover and inv being pressed, low as disabled. That would be my assumption but I got this wrong before, is that what you expect from those?

@_discovery @maxdeviant yeah pretty much, but I'm not sure how to document this properly yet, I'm still finding new UXs that I've never seen before and change my mind on what element should be painted with what color.

For hover states I usually use the inv states. For example, if you press `G` on dotgrid, it'll use the inv states to colorize the hidden input field.

hundredrabbits.github.io/Dotgr

@neauoire @maxdeviant I think what’s also a factor is how much you draw. For instance in my ui I want buttons to have a subtle border. if b_med is the normal, I can’t assume b_low is brighter/darker value, or f low/med are.

Many themes use vivid color in f med, so if I try pick it ends up being based on what I see in themes and not in value. like “slightly darker than the base color” can then only come from actually modifying the input. Make hsv from b_med, use a smaller value for the lowlight

@neauoire @maxdeviant This was my thinking when playing with it, since contrast relative to global background is not relative between f and b necessarily.

Or in less words, you end up with bright green rectangles everywhere instead of a subtle lowlight :D

Sign in to participate in the conversation
Merveilles

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them. Check out our Patreon to see our donations.