Re: Bug 687752 - work with theme authors

["Mike C." <compmastermike yahoo com>]

> Now what does that mean for you or me working with GNOME 3 (or GTK 3)? It means
> they can't rely on things staying the same or having a stable base to build on.
> Things keep changing. You can't just write something for 3.0 (be it an
> application, a shell plugin or a GTK theme) and expect it stay working that way
> forever. Instead you need to constantly improve on your work.
> There's one important thing to note about this however. If you participate in
> this process - like a bunch of applications do - you get two things:
> (1) You get the help of the GNOME developers. People are generally interested in
> your use cases and want to make your life easier and better.
> (2) You get to influence the direction of development. You can request features
> that you are missing and can expect help to get them implemented.
> However, you also lose your independence to do whatever you want and you get to
> compromise on your vision. Which is why at this point in time I'd advocate
> against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3. They value their
> independence from GNOME too much.

I agree that GTK is and was always essentially just the GNOME toolkit. This
discussion is less about applications and more about themes. The reason for
that is that themes are something that we know won't work in the next release
to the point where rewrites are in order. Applications are not. On the
application side with SpaceFM, we haven't even had much issue with differences
in the operation of GTK2 and GTK3, let alone just different versions of GTK3.

You stress that I'm advocating for backwards compatibility, when my greatest
point towards that was the expectation that the theme api eventually won't be
in flux as much as it is now, and perhaps a theme would work between GTK3
version because the changes would be more of additions than anything else.
Personally, I am _NOT_ advocating for backwards compatibility at all. That
isn't my goal. I start with "The goal here is not to try to stop progress with
regards to GTK theming, but rather to help foster an environment where current
and aspiring GTK theme designers can thrive despite the changes that are
occurring." What I'm looking for here is communication of changes in some form,
documentation of what the theming classes are, at least on the api pages. The
only two ways of making a theme right now are to start from Adwaita or the
daunting task of looking through the gtk source code for every place where
theming classes exist. The bar for entry is just "too damn high" (my apologies,
Jimmy McMillan). Those who entered this arena aren't even staying, even
considering that they aren't the ones "just about changing 5 colors and 3
settings in a gtkrc file" but ones making fresh, attractive, consistent themes
that one cannot mistake as a recoloring of Adwaita. It's those individuals, not
the one who came up with the magical idea that Clearlooks could be red instead
of blue that the community is up in arms about and aren't just passing off as
"these individuals are too lazy".

One of the only places I easily find where I can see the theme classes is here:
http://gnomejournal.org/article/107/styling-gtk-with-css and that's from 3.0,
not inclusive of any changes since then. This lack among other things I'm sure
you've heard and keep hearing, is why others are making the claim GNOME is
trying to stifle 3rd party theme creation. Options were a theme engine thing in
GTK2 when they weren't things documented on the individual GTK widget pages.
The default themes that came with those theme engines showed off the options
within the comments. We've moved into CSS and away from the focus on theming
engines, but there hasn't been a migration of the knowlege that they exposed.
Where do I find the .view, .cell, .button, etc? Where do I see the :backdrop,
:focused, :selected and their combinations? I can at least say that the
":backdrop" state is not a general CSS thing.