Bug 687752 - work with theme authors

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

Continuing the discussion on the mailing list as requested from:
https://bugzilla.gnome.org/show_bug.cgi?id=687752

To those just joining this discussion, the general issue that I'd like to
see addressed is the lack of communication between GTK developers and theme
developers coupled with the continual theming changes that are occuring in GTK.
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.

A copy of my last comment on that bug follows and was in response to a comment
from Benjamin Otte.

> This is indeed a serious problem. I've never felt the need to spend a lot of
> time on it as I could easily communicate with all the theme authors I know. And
> whenever I (or others) suggested features in GTK that would have improved
> theming, there was not a lot of interest. So I didn't pursue those topics
> further. I guess the biggest problem is that the GTK theming and GTK
> development communities don't talk to each other. So we don't know what you
> guys want or need and can't help you make your themes better and you guys don't
> know what we want and can't help us make GTK better.

I appreciate that you recognize this as something important to deal with, but
the issue is more than not having our people talk to your people because I
wouldn't call GTK theming a community. I spend time looking through the monthly
desktop screenshot thread on UbuntuForums, but that really seems to be the
closest thing to community that theme creators have. It isn't a bunch of people
working together, but rather a bunch of individuals who might use each others
tricks and each others work as a basis for their own. Otherwise, there would be
a lot more people taking what should be a prime opportunity to do more than
just vent their frustrations, but to lessen them by communicating here. A very
important thing to take note of is that individuals more than ever have to base
their work on others because the theme classes are something that need to be
worried about and not just widgets as complete entities like they were in GTK2
when they were interacting with a theme engine more than directly with GTK. The
big difference in this process is that there isn't the autonomy that there used
to be because if you make a theme, you don't just fix it up as the next GTK
version rolls around, you have to rebase your theme on work, and what you'd
rebase it on (if you didn't start with Adwaita) can easily not exist. That
makes it hard for GTK3 theme development to be the kind of self-documenting
process that GTK2 theme development is. First and foremost, I am a developer,
and attempting to call myself any sort of artist is secondary. While I look
through git commits of gtk+ and gnome-themes-standard, (and actually run them
as my everyday versions) I can't expect that others have the capability to do
so, and now you at least need to grab the source code for Adwaita to start
developing a theme because it is no longer on the system in a form you can read
it. Especially with the theming classes so in flux, Adwaita is the premier
documentation and to stay relevant, it is a dependency that theme developers
can't shake at this point.

> I don't know either, but the answer to that is "when it's done". The goals that
> I'm trying to follow are these:

Thanks for sharing those plans, it seems like GTK3 will look like the modern
toolkit it has become under the hood.

> We've thought about a bunch of them but didn't do anything about it for 2
> reasons:
> - Our themes are developed in lock-step with GTK so it wasn't really necessary.
> - We didn't find a good way to handle it, in particular for forwards
> compatibility. What do you do if you figure out your theme is too old?
> I'm open for suggestions here, but I suppose that should go in a different bug.

I would think to version the themes and thus the set of theming classes
separately from GTK itself. Things will break every release right now, but
there will be a point where they stop doing that, where things can be augmented
and changing existing theming won't have to be done for GTK theming mechanisms
to be better. To install a theme now requires the user to know what version of
GTK3 they are running and see that specifically mentioned when they are
downloading a theme. It must be hard to be popular with the bar for users set
so high if you aren't already the default somewhere. This in particular is
important to me because IgnorantGuru and I have seen issues in SpaceFM that
arise due to users using themes that aren't entirely compatible with the
version of GTK that they're using. We can't point the finger at ourselves
because it isn't a bug in our code or something we can work around, we can't
point the finger at theme developers because their theme worked properly when
it was made, we can't point the finger at the user because we don't want to
limit them or ourselves when making a subjective decision like a theme, and we
can't point the finger at GTK because we don't want to stop improvements from
occuring. The best scenario for everyone is for such incomptibilities to be
detected early rather than when they start making things difficult for everyone
who is a part of that process who is doing their best in their sphere.

> This is a question that is very out of scope for this bug.

It is, but I'd talk more about GTK as a platform than GNOME here because I see
a lot of caution to port to this mythical GTK3 beast. XFCE and LXDE seem to
position themselves as wanting GTK3, but hesitant to grab it. SpaceFM only
recently got GTK3 compatibility because I decided that was what I wanted and
contributed it, managing compatibility back to GTK 2.18 in the process. I don't
like the thought that the hesitance is justified beyond not finding the porting
process interesting.

> Ideally, you'd want to get involved and participate in GTK development. You'd
> probably spend a lot more time arguing with people than writing themes. But on
> the plus side, you'd know what's happening early and you could influence the
> direction development takes.

I'd like to do that not to only feel a part of the process, but to try to
expedite a lot of these changes and better guide those who are outside of the
process. Theming is one area, but I'd really want to find a niche and help push
GTK development forward. I build and run GTK from git anyway, this is just
doing more than watching from the sidelines.