[GTK Themes] Further GTK+ theme integration
Elliot Glaysher (Chromium)
Chrome GTK+ integration started making progressively poorer decisions
on the frame color due to many of the inputs to our heuristics are
gone. Instead of adding more breakable heuristics, I'm proposing that
we just require theme authors to specify the frame color like they
used to with either the MetaFrames class (general case) or a new
ChromeGtkFrame class (specific to chrome case).
http://code.google.com/p/chromium/wiki/LinuxGtkThemeIntegration
Is there anything I haven't thought of? Any concerns or comments?
-- Elliot
Evan Stade
-- Evan Stade
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Elliot Glaysher (Chromium)
> do we need colors for background tab + hovered background tab?
Maybe? I don't think so because the background tab color is computed
as a function of the foreground tab color (gtk default) and the
background color (this new color).
-- Elliot
Evan Martin
I wonder if we would be better off not making this as Chrome-specific.
Like, suppose another program cares about matching the window frame color.
In that case, we could call it GtkWindowFrame or something. Not sure
if it's rude to pollute their namespace though.
Evan Stade
Evan Martin
<e...@chromium.org> wrote:
> Is there anything I haven't thought of? Any concerns or comments?
Ooh ooh another one -- might as well tackle scrollbar color while we're at it?
Elliot Glaysher (Chromium)
themes in the last year(s) don't change their window color when
inactive and just change the text color. I'm not sure what to do about
that. In my current hacked up version of Ambiance, I just lighten 0.7,
though I'm not sure if that's the best
On Wed, Nov 10, 2010 at 12:20 PM, Evan Martin <ev...@chromium.org> wrote:
> Ooh ooh another one -- might as well tackle scrollbar color while we're at it?
This might be doable. Is there a reason we don't currently just read
whatever the colors were set on GtkScrollbar and do our complicated
workaround instead?
-- Elliot
Evan Martin
<e...@chromium.org> wrote:
> As I've been working on this feature, I've noticed that many (most?)
> themes in the last year(s) don't change their window color when
> inactive and just change the text color. I'm not sure what to do about
> that. In my current hacked up version of Ambiance, I just lighten 0.7,
> though I'm not sure if that's the best
I guess you should bring up a bunch of windows, play around with them
a bit, and then use your judgement as to what looks best. I don't
think it's too harmful if we don't change color when we lose focus --
there are other indicators for focus, like the ring we draw.
> On Wed, Nov 10, 2010 at 12:20 PM, Evan Martin <ev...@chromium.org> wrote:
>> Ooh ooh another one -- might as well tackle scrollbar color while we're at it?
>
> This might be doable. Is there a reason we don't currently just read
> whatever the colors were set on GtkScrollbar and do our complicated
> workaround instead?
I believe it's because the colors that were set are not actually used
by the theme, but I'm not sure.
Elliot Glaysher (Chromium)
>> This might be doable. Is there a reason we don't currently just read
>> whatever the colors were set on GtkScrollbar and do our complicated
>> workaround instead?
>
> I believe it's because the colors that were set are not actually used
> by the theme, but I'm not sure.
OK. I've update the documentation based on what I committed Saturday.
http://code.google.com/p/chromium/wiki/LinuxGtkThemeIntegration has
been updated and now has a bunch of tables of what the various style
properties can do. I'll send this out tomorrow if no one has any
problems with it.
(P.S.: Adding images for close/min/max buttons looks like it's really
friggin hard! The couple of simple ways don't work!)
-- Elliot