OSD symbols
Rodney Dawes
dobey.pwns at gmail.com
Thu Dec 10 12:46:23 PST 2009
On Thu, 2009-12-10 at 21:07 +0100, Kenneth Wimer wrote:
> On Tuesday 08 December 2009 03:38:15 pm Rodney Dawes wrote:
> > On Sun, 2009-12-06 at 16:43 +0000, Matthew Paul Thomas wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Jakub Steiner wrote on 02/12/09 22:55:
> > > >...
> > > > What the important part here is that the color isn't defined in the
> > > > icon itself, it's up to the widget theme to define in all sorts of
> > > > different contexts like we have it for text. Eg. panel, menu, toolbar,
> > > > when it's hovered over, disabled, that sort of thing.
> > >
> > > Maybe, but then someone would have to maintain a color naming
> > > specification (however simple) alongside the icon naming specification.
> > > I know of only one attempt to do something similar: CSS system colors,
> > > which was a failure. <http://www.w3.org/TR/CSS2/ui.html#system-colors>
> > > We'd need to identify what went wrong there and how not to repeat it.
> >
> > I don't think so. I think this should be handled as part of the symbolic
> > addendum to the theme/naming specs. It should specify how to name, and
> > how to design those icons so that we get the appropriate behavior with
> > being able to alter the colors in the widget themes.
> >
> > This is important, because Qt or other widget sets may want to use the
> > same icons in the same way, and we need to allow for the fact that they
> > may not have the same states or color structure as GTK+. That said, I
> > don't think we need to really care about things like warning and error
> > colors. We just need to define that the paths that need to be drawn with
> > the same colors as text, have the appropriate metadata tagging on them.
>
> I think that being able to add some colour is important. I suggest allowing as
> many colour values as needed and including a fall-back mechanism if any of
> those variables are not defined (to use just one color as suggested).
Write the addendum, and we can discuss it better, since we'll have
something tangible to alter. :)
More information about the xdg
mailing list