is there an actual bug, in that wall of text, or are you just venting for theme changes?

The issue being reported here is the pattern of theme breakage in almost every minor release, and the request being made is that your dev team examine and discuss the problems it's having in maintaining a stable theming api across versions.  This is a major obstacle to gtk3 adoption and use.  Identifying the problem in your development process is necessary to address it.  Have you identified what is causing this serious and repeated breakage?

As I stated, reporting and addressing (or ignoring) the bugs in isolation doesn't address the pattern of repeated breakage.  IOW even if you keep fixing reported bugs in one version, if you simply add more with every release, apps using gtk3 are in a constant state of 'broken'.  This deserves some attention from your lead developers in this area to put an effective solution into place.  This issue is currently the most significant one I've seen using gtk3, making it almost unusable in practical terms.

bugzilla is not a place for introspection. you are also operating under the impression that there are "lead developers".

if you have *specific* bugs and regressions, you're *strongly* encouraged to file them - along with test cases, if possible, so that they can be caught by the test suite.

if you're just venting because the themeing classes, which are not currently under any stability promise, change while we fix bugs then the gtk-devel-list mailing list is a better option for you to be heard by anyone beyond your echo chamber.

> the themeing classes, which are not currently under any stability promise, change while we fix bugs

I see.  When does gtk3 leave alpha testing?  Is there any road map to a stable theming api such that theme developers have some incentive to invest their time, and app & distro developers know when to expect gtk3 to be usable in production?

Also, where in your documentation is this covered - that gtk3 is unstable by intent at this stage?  Are theme developers warned not to bother wasting hours developing themes for it because they simply won't work with every update, or is this undocumented?  Perhaps that's one of the problems with this issue.

This is a very specific bug, it's just broad.  You don't seem to be addressing it at all.

Also, from your analysis of the instability in your themeing classes, does this problem continuously break gnome as well, or does gnome magically escape this somehow?  If so, why are only non-gnome gtk3 themes and apps being affected by this problem?

Do you in fact support theming in gtk3 at all, or do you consider this merely third-party hacking?  Thanks.

I still think an effort to analyze this severe problem is in order, not just wasting time in a long discussion and denials of the problem on the mailing list - I don't have time to correct your development problems, sorry.  I'm just reporting the issue to you in the hopes that you would want to address it.

(In reply to comment #4)
> > the themeing classes, which are not currently under any stability promise, change while we fix bugs
> 
> I see.  When does gtk3 leave alpha testing?

it's debatable as it ever did.

>  Is there any road map to a stable
> theming api such that theme developers have some incentive to invest their
> time, and app & distro developers know when to expect gtk3 to be usable in
> production?

the themeing API is already stable (though it's subject to expansion and deprecation, like other API). if you're referring to how widgets are themed, that has never been placed under any stability promise in GTK+ 2.x either: bugs have been fixed, themes needed to be updated.

> This is a very specific bug, it's just broad.  You don't seem to be addressing
> it at all.

we have two wildly differing definitions of "specific", I am afraid. again: if you have specific instances of things that broke between 3.4 and 3.6 (old stable and current stable) we'd like to get bugs detailing them.

(In reply to comment #5)
> Also, from your analysis of the instability in your themeing classes, does this
> problem continuously break gnome as well, or does gnome magically escape this
> somehow?  If so, why are only non-gnome gtk3 themes and apps being affected by
> this problem?

the GNOME standard theme (Adwaita) is updated each time something changes - and GTK+ is updated each time a new requirement is put forward by the theme authors for GNOME and Windows (and MacOS).

> I still think an effort to analyze this severe problem is in order, not just
> wasting time in a long discussion and denials of the problem on the mailing
> list - I don't have time to correct your development problems, sorry.  I'm just
> reporting the issue to you in the hopes that you would want to address it.

if you don't have time to deal with bug reports then I don't feel very much compelled to answer broad questions that are more suited to the development mailing list than to bugzilla.

> we'd like to get bugs detailing them

Very well, I have changed this to UN-RESOLVED so you can get some further info from theme developers.  I asked some theme developers I know to add some details, but they said they have wasted too much time trying to get you to fix anything, and simply refuse to be "fooled into participating" anymore.  That's quite a relationship you have with gtk3 theme devs, many of which I know to be very conscientious and helpful contributors.  You must have done some number on them to alienate them all the way you have - nice support work.  I guess the fact that people are saying that gtk3 "upstream is impossible to work with" means nothing to you, and doesn't indicate any problems in your dev team.

If you're interested in doing anything more than marking everything RESOLVED while doing nothing to address it, you might also review the (many!) theme bugs already submitted and examine what might be causing you to break themes in such a careless, widespread, and regular manner.  I have already seen this cause memory leaks, app dysfunction, and other serious problems in otherwise well maintained themes and apps.

By only fixing bugs for the prior versions, but creating new breakage with every release, you're merely wasting everyone's time - perhaps your intention.  Why fix the bugs at all?  The continuous breakage with the next release renders any fix useless.  Hence this bug report of a problem which is broader in scope (a situation you don't seem to know how to handle at all, which is why I suggested your dev team should discuss this repeating failure.)

Based on your response thus far, I can only conclude that gtk3 is unsupported.  It's so inflexible that the only theme which can be used effectively is Adwaita, as this is the only one you apparently give any mind to not severely breaking with every release of gtk3.  Thus use of themes in gtk3 is simply unsupported, which explains why many theme developers are abandoning it as unsupported.  Perhaps you should document the fact that you don't support any non-default theming in gtk3, and that all themes must be recreated for every release.  That is the current situation so best it's to make people aware of it.  So please forward this bug to your documentation experts.

Thanks for addressing this problem.

ebassi: you should know better than to feed the trolls ;)

Hi, I'm the guy that has spent the last two years breaking themes with every release. This is 100% deliberate and I intend to continue this process for the forseeable future. I've been very open about this and told this to all the people that have asked me about it (read: not you) and done so repeatedly. So it's not a new thing.

But because you asked, again, here are the reasons for why this choice was made:

(1) Moving the theming code from its antiquated underpowered gtkrc format to a web-inspired CSS format respecting the CSS box model that can be animated is not a simple task that can be done quickly. And if done slowly, it likely can't be done without breakage.

(2) GTK doesn't swim in extra developers that are happy to spend their time ensuring compatibility with rarely used themes. I decided the time was better spent implementing new features than caring about other themes.

(3) All the theme authors participating in GTK development (read: not you) agreed that it's better to keep their themes up to date if in exchange they get new features than keeping with the status quo.

(4) After those decisions were made, no time was spent on even thinking about compatibility, because there were no people even bringing up the topic, let alone willing to work on it.


And this is why lonely blog posters on blogspot or the mint dev blog (read: you) get all sad and ranty when they don't participate upstream and then decide to only use GTK2 apps.

@Benjamin Otte

Thank you for your condescending, semi-serious reply - about the best I can expect in the way of gtk support these days, so I'll take it.

> (3) All the theme authors participating in GTK development (read: not
> you) agreed that it's better to keep their themes up to date if in
> exchange they get new features than keeping with the status quo.

Really?  All of them?  I'm sure the ones I've spoken to will be very surprised to read that.  What you're really saying is all your large corporate customers with teams of devs made that agreement, that you would break everyone else's themes regularly, and only give a damn about the official Windows, Gnome, and Mac themes, letting them dictate what is done in gtk in general, to hell with everyone else.  "We had a meeting!  It's official!'  Gnome is obviously now riddled with those kinds of priorities, and treats its API users like hostile competitors that it needs to disrupt and destroy.  Nice dev environment - you're really giving back to the community til it hurts (everyone else).

What you may not realize is that many users actually use those 'rare' (aka non-corporate, community-developed themes downloaded by the tens of thousands), because they like themes that have some aesthetic quality to them, they're disabled or impaired and have special visual requirements, etc.  With the fantastic approach you've taken, I now have regular reports of mysterious memory leaks, broken displays, broken menus, ridiculously looking widgets, etc, which all eventually track back to serious gtk theme malfunction.  And it's not due to people unwilling to maintain their themes or users unwilling to update them in a reasonable timeframe.  It's due to a completely ridiculous development approach to gtk's theme API (the very one you describe) that is breaking themes with every release.

Your BS argument that there's simply no way to make significant changes without breaking everyone's work every other day is just that - BS.  You simply give no thought to community-developed projects, as you yourself just admitted.  You simply don't want to be bothered with doing it correctly, carefully and with consideration for others' work.  And your corporate customers are more than happy to see their themes are the only ones that work at all, and that everyone else's work is regularly broken.

So now that your work is actually being USED, not just talked about in your corporate little cliques, it's seriously failing.  And you're alienating every independent gtk theme developer, who all say you haven't listened to shit they've said, that developing a usable theme for gtk3 is impossible, and that upstream is the same.

In case you didn't know, developing themes is a lot of tedious and hard work, and you seem to have no respect whatsoever for other people's time, like most devs I've encountered at gnome.  'Break everything that is non-gnome' seems to be your philosophy - eliminate the enemy!  (Which unfortunately includes all users of your API - they're just trying to steal your work, after all).

So let me put it this way - whatever development approach you took to expanding gtk's theming abilities, it sucks.  You screwed up royally, and now you get to figure out how to fix it, such that gtk is actually a usable library by someone except Adwaita users.

I'm sure that will be real high on your list of priorities since gnome devs are so known and respected for maintaining all these little pet broken projects they start.  Tell me, where did you come to gnome from?  Microsoft?  Apple?  Or do you just rent yourself out to whatever open-source community-developed project is listed for destruction?

> (4) After those decisions were made, no time was spent on even
> thinking about compatibility

Quite an approach for API development - 'no thought whatsoever to compatibility'.  Well done!  Sounds really usable.  Where _do_ you find the time?

Actually, I've heard from many people bringing up this topic.  Obviously you're completely removed from how your library is actually performing.  This too I've encountered from gnome devs before - they feel everything is going swimmingly while people are screaming for some kind of decent support.  Those are some good earplugs you have - try taking them out and you might hear something besides you complimenting yourself on what great work you're doing.

Unless it's your goal to completely destroy gtk3's reputation, and turn it into one big unusable bug, a possibility I haven't eliminated, get your act together and start putting some quality into your work, AND respecting others' work.  We all love playing around and being creative, don't we?  But if you develop an API and are as completely uninterested in 'compatibility'  as you say, how do expect that API to be even remotely usable?  In case you didn't realize, people attempt to build useful things with an API, not just useless crap that fails.  Take some responsibility for your work, or don't do it.

Congratulations on destroying another community-developed project.  Well done.  Took years to build - it's always much easier to destroy things quickly with carelessness and laziness than it is to develop something of quality that lasts.

And where is all of this documented, that gtk themes are to be completely rewritten for every trivial gtk release, and that API compatibility (even from 3.6.0 to 3.6.1) is non-existent now?  I'd be most interested to read these docs, and share them with my readers.  And what is your roadmap to a stable, usable API, or am I being old-fashioned?

Finally, what is your solution to this widespread breakage causing apps to malfunction due to your incompetence?  Namely, this bug report (once again marked 'RESOLVED' in panic that thought might actually be required to correct it.)  Not your problem either, even though you just admitted that you created the problem deliberately?

The issue I have here is not that it changes, but the magnitude with which things change. Theming is straightforward and better than ever, but is the best place to look for the changes I need to implement in a theme a choice between the gtk+ git repository or the gnome-themes-standard repository? Is there anywhere else where I would be able to see what changes I would need to make to remain compatible? When, if ever, will we be able to start expecting that a theme will have relevance for longer than it takes to release a new version of gtk?

Building on this notion, is there a possibility of versioning the changes to the theming classes so that themes can be made for a specific version and have their compatibility checked before they are used and make a mess of things?

What should be done about projects that aren't Gnome projects and aren't developed in lock-step with Gnome? I can see vast changes in the construction of interfaces meant for Gnome3, and the continue now. Where are we in terms of deciding what an application should look like and how it should behave? The desired api's are in flux, including notifications, as I see from the gtk-devel mailing list. Is the migration to gtk3 too early for most applications that are neither associated with Gnome nor a specific version of a particular distribution?

More than anything, I just want to understand the situation and how I should proceed as a theme developer, an application developer, and a power user whether it is changes I can make to my own development processes or contributions I can make here to make my own and hopefully your lives easier as well.

(In reply to comment #9)
> (2) GTK doesn't swim in extra developers that are happy to spend their time
> ensuring compatibility with rarely used themes.

Hi,

I'm a GTK3 theme developer, and I would like to comment this sentence. This is not really friendly for theme developers spending their time ensuring compatibility with new GTK3 versions.

Do you imply that themes (other than Adwaita, I suppose) are rarely used? Even if it was true, not bothering about themes compatibility is not really nice for developers relying on GTK. Anyway, it's not true. Here are some examples from most downloaded themes:

- Zukitwo, downloaded 169,607 times on gnome-looks.org (g-l). Theme broken. GTK 3.4 only.

- Faience, downloaded 95,782 times on deviantart.com (dA). Old downloads for GTK 3.2, updated for GTK 3.6, but nothing for GTK 3.4.

- Adwaita Cupertino, downloaded 75,146 times on g-l. Theme broken. GTK 3.4 only:

user:
> will the next version be compatible with gtk 3.5.x? [...]

dev:
> I do not know, I think it depends on how the changes affect the
> theme, 2 months ago that I have gnome 3.4, now is a bit early to
> think about gnome 3.5.
> 
> After my bad experience with v3.2 to v3.4 update I decided not to
> work more with beta versions, sorry I have not enough time

dev:
> Moreover, the constant changes with Gnome updates do not help much

- Hope, downloaded 68,576 times on dA. Theme broken according to comments. Example:

> I know that it must be frustrating as a theme developer to have the
> Gnome/GTK+ devs basically ignore you in terms of backwards
> compatibility, but, seriously, can we please please please have a
> fixed and updated version of the best GTK3 theme for Gnome 3.6?
> 
> Pleasepleasepleaseplease?

- Atolm, downloaded 43,663 times on dA. GTK 3.2 only. Theme broken and will remain broken:

> The theme is not up to date with the current version of gtk and
> gnome, and I won't update it.

- ANewStart, downloaded 42,564 times on dA. Theme broken. GTK 3.2 only. From the dev:

> Porting of ANewStart suite to GNOME 3.4 › As you may know (if you
> don't, you should!), new GNOME 3.4 version has dramatically changed
> the way in which 3.2 themes behave. Being this a very disruptive
> process, updating GNOME 3.2 themes to the latest 3.4 version is far
> from being easy, since I have to basically rewrite the themes from
> scratch. And this takes a long time.

dev:
> As you said, in my opinion GNOME is no longer listening to the
> community, and this is not only a big flaw, but also a hazardous
> double-edged sword. I tenderly remember the early days (we're talking
> about 6 years ago) in which I approached to linux in general and
> ubuntu in particular. There was this big great friend called GNOME2
> in which magic appears and with which you can change your desktop's
> look and feel with simple and easy steps. And I tenderly remember
> when I started to customize by myself and to create my own themes: it
> was fun, and easy, and exciting to some extent.
> Now creating themes is becoming a full-time job: you have to deal
> with a lot of problems, to stay always up-to-date with the latest
> versions, to work more on fixes rather than on ideas. And this is
> hurting both to the community and to GNOME itself, since they're
> trying to brand their software, to have a well-defined personality
> and to be instantly recognized by everyone (the same way ubuntu is
> doing). And this is cool, but as long as you keep the process of
> changing thing easy and affordable. Otherwise, people will simply
> move away. We're not that stupid.

- Elegant Brit, downloaded 31,163 times on dA. Theme broken. GTK 3.2 only.

- Boomerang, downloaded 26,304 times on dA. Theme broken. GTK 3.4 only.

- Orion, downloaded 26,058 times on dA. Theme broken. GTK 3.4 only.

- SLAVE, downloaded 11,006 times on dA. Broken and will remain broken. The author, half-left, developed a lot of themes. His GTK3 themes were downloaded 30,399 times and his Gnome Shell themes were downloaded 299,358 times on dA. He just abandoned Gnome:

half-left:
> I'm sorry to say this but I am abandoning any GTK3 theme making from
> now on. Upstream is impossible to work with and GNOME 3 has become a
> complete mess in regard to third party theme making. As if GNOME
> Shell isn't bad enough sometimes with every version being broken,
> GTK3 is even worse. For those of you who wish to make GTK3 in the
> future, good luck, you'll need it.
> 
> Honestly, Windows and OS X actually look more attractive to me right
> now.

half-left:
> Sorry, I've given up on GTK3 and GNOME, I use KDE4 now.

half-left:
> Blame GNOME, they changed the GTK syntax too much and made it even
> more complicated. It's like maintaining alpha software.

And from my experience, I have versions of my theme for GTK 3.2, 3.4 and 3.6. Theming is all but pleasant. With GTK 3.4, I tried to update my theme but it was so buggy that I can't even say exactly what were the problems. I wasted days to code my theme again from scratch.

If I were to start over, I'm not sure I would like to code a GTK3 theme, but now I have thousands of users, so I feel I have some responsibility to update my theme, but without any pleasure.

(In reply to comment #11)
> The issue I have here is not that it changes, but the magnitude with which
> things change. Theming is straightforward and better than ever, but is the best
> place to look for the changes I need to implement in a theme a choice between
> the gtk+ git repository or the gnome-themes-standard repository? Is there
> anywhere else where I would be able to see what changes I would need to make to
> remain compatible? 
>
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.

> When, if ever, will we be able to start expecting that a
> theme will have relevance for longer than it takes to release a new version of
> gtk?
> 
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:
(1) Make GTK CSS be compatible (syntax and semantics) to Web CSS. So a theme written for GTK should also apply to a Website. In fact, I write most of my tests on http://www.jsfiddle.net and run them in Firefox and WebKit to know how to implement things. I consider this pretty much done since 3.4.
(2) Make GTK have the CSS3 styling (read: color, images, sizes - but not layout properties like display: none or position:fixed) properties that the web supports, too. And support them in the same way (animatable etc). This is pretty much done with 3.6.
(3) Make GTK widgets conform to the CSS box model - http://www.w3.org/TR/CSS2/box.html - for everything we draw. So make sure every widget respects margins, padding, borders and draws a background. This is my primary focus for now. Expect lots of widgets to suddenly have borders, backgrounds, padding that previously ignored them.
(4) Implement sizing properties like min/max-width/height and make the boxes respect them as best as they can. Also get rid of all the old "style properties" (like "-GtkWidget-link-color" or "-GtkScrolledWindow-scrollbar-spacing") for real CSS properties. This should be part of the box model stuff in (3).
(5) Name the boxes we create properly to make theme creation easier. This means figuring out how many boxes we create for each widget and what classes we do and don't attach to them. This is work that I had wished people spend more time on as the current style classes situation is pretty dire. But so far nobody has spent time on it.

There's also a bunch of other things that I want to move to the CSS machinery that I don't expect to cause breakage, as they just depend on new properties and don't alter behavior by default:
(6) Add support for border-collapse of some sort.
(7) Add support for layout and animating layout of certain widgets to the CSS machinery and use it where widgets allow it.
(8) Make CSS support everything we use icon themes for today.

So all in all I'd expect things to slow down more and more with every release, in particular after the box model things are through. And I expect those to happen for 3.8 or 3.10 for GTK's own widgets and maybe a bit later for most of the core applications.

> Building on this notion, is there a possibility of versioning the changes to
> the theming classes so that themes can be made for a specific version and have
> their compatibility checked before they are used and make a mess of things?
> 
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.

> What should be done about projects that aren't Gnome projects and aren't
> developed in lock-step with Gnome? I can see vast changes in the construction
> of interfaces meant for Gnome3, and the continue now. Where are we in terms of
> deciding what an application should look like and how it should behave? The
> desired api's are in flux, including notifications, as I see from the gtk-devel
> mailing list. Is the migration to gtk3 too early for most applications that are
> neither associated with Gnome nor a specific version of a particular
> distribution?
> 
This is a question that is very out of scope for this bug. And it's a question that is even out of scope for GTK but a question that is best asked to all of GNOME. All I know is that I have asked a lot of people about this and everybody has different opinions. So no consensus about how stable/experimental we are exists. The only thing everyone agrees on is that GNOME 3 is not as stable as GNOME 2.

> More than anything, I just want to understand the situation and how I should
> proceed as a theme developer, an application developer, and a power user
> whether it is changes I can make to my own development processes or
> contributions I can make here to make my own and hopefully your lives easier as
> well.
>
Again, this is mostly out of scope for me and this bug report. But as a theme developer with the unstable theming APIs, I think the minimum you'd need to do is go in lock-step with GTK (or even GNOME). And depending on how up-to-date you want to be, you want to develop your theme against the unstable vesions of GTK in preparation for the next release.

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.
Because so far, the people that get involved in development of GTK are more of the opinion that "Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design." (That's a quote copied from the blog post in comment 1.)

> 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.

useful discussion, but not an actionable bug. lets take this to the mailing list or irc.