> 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. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
