deprecation does not imply removal: the API is guaranteed to exist until we break for GTK+ 4.0, and even in that case GTK+ 3.x will still exist with that API.

But doesn't the following mean that it's useless in newer GTK versions:

GtkThemingEngine has been deprecated in GTK+ 3.14 and will be ignored for rendering.

It seems "will be ignored" means the theme engine won't work. Is it wrong?

Hi Emmanuele,
Thanks that is reassuring.
To be honest I was a bit scared by the comment at 
https://developer.gnome.org/gtk3/unstable/GtkThemingEngine.html

"GtkThemingEngine has been deprecated in GTK+ 3.14 and will be ignored for rendering"

(the part: "will be ignored for rendering")

Can you confirm that this will not be the case ? 
If yes you can safely close the report.

oops, double posting. Sorry.

theming engines will be used until GTK+ 4

Reopening, following 
http://blogs.gnome.org/mclasen/2014/10/23/an-early-view-of-gtk-3-16/

The statement about CSS theming clearly, explicitly, contradict comment #5
Any comment about this ? 

Thanks in advance,

Hugo

I guess it's because Matthias was no very involved in the theming stuff we did. We originally thought we would need theming engines for a longer time to implement the features themes wanted. But it turned out that wasn't necessary. And as this public interface deep down in the drawing layer has been holding us back for a while, we're pretty happy it's gone now.

As for oxygen-gtk in particular, I'm actually happy that it's stopped working because its codebase has been explicitly violating the contract for theming engines since its inception.
The first thing its code always does is poke into the widget tree and pull the widget out. And that's what GtkThemingEngine was explicitly designed to not do.

Dear Matthias,
Thanks for the honest answer.
On the part "I'm actually happy that it's stopped working" I will not comment in order to avoid both harsh and sad words. I hope you do not mind if this gets quoted elsewhere. 

for the record: oxygen-gtk uses only available public api, well -public so far-, and if indeed it does poke in the widget tree it was, at that time, at least, to implement features that were not available otherwise, and to share as much code as possible with the gtk2 version, again for manpower reasons. 

... I guess I will open a new bug report asking for help to port the (considerable amount of) work invested on oxygen-gtk to css (something which I cannot -because I do not know how- do. 

Finally, and in case it is not obvious, oxygen-gtk was never written to annoy gtk devs (to the point that they are "especially happy" to get rid of it), but to fill a missing hole that I considered important in the open source world about consistency between applications. With this in mind, I just used (respectfully) all the available tools I could lay my hands on. 

Regards, 

Hugo

Side note:
doesn't the change about themingengine *removal* (as opposed to deprecation) "explicitly violate" some sort of contract between gtk and devs about API stability ? or is there no such contract in gtk ?

> Finally, and in case it is not obvious, oxygen-gtk was never written to annoy
> gtk devs 

It doesn't - please take Benjamins attempt at humor the wrong way. We are very happy to have good (theming) integration of GTK+ apps in KDE, and your work is a big part of that!

It is still very early in the development cycle, lets see if we can work something out - I may have some resources available to help reducing oxygen-gtk's dependency on a theming engine. If we can't get the major themes (Ubuntu, Elementary and Xfce come to mind here) working without theme engine by the time the 3.15 cycle comes to an end, we'll look at granting theme engines another cycle of porting time.

I'm sorry if this is inconvenient for you, or causes extra work.

(In reply to comment #9)
> Side note:
> doesn't the change about themingengine *removal* (as opposed to deprecation)
> "explicitly violate" some sort of contract between gtk and devs about API
> stability ? or is there no such contract in gtk ?

It doesn't break any application apis, which are the ones we care most about when it comes to keeping stability. Themes are a bit more of a fuzzy area for compatibility. We try to keep things working here as well, but theming has been under very heavy development throughout the 3.x era. Thankfully, with CSS now being good enough for 'pure css' themes, we're nearing the end of that phase...

I find the current state of affairs appalling and disturbing.

This was a working feature in Gtk, which had a very legitimate use case that can *NOT* be replicated in pure CSS alone.

The oxygen-gtk engine is used by an extremely large number of users in a wide variety of settings. Removing real support for theming engines essentially makes gtk3 apps a non-possibility on quite a few distributions that previously relied on the seamless integration.

I implore you to undepreciate this part of Gtk 3. If you would like to remove support for it, this is clearly something to do for Gtk 4. You *have* broken compatibility and the promise between minor versions. Even though the API still compiles, it essentially does nothing now. Hence, this is a Gtk 3 *regression*.

Please fix this bug immediately. Your inconsiderate practices are affecting a wide variety of users on multiple platforms and distributions. You are harming the experience of great numbers of non-GNOME users. The community is largely outraged at your decision here.

Fix this regression at once.

I would like to point out that removing theming engines has been an ongoing project and GTK 3.16 has done lots of refactoring and feature additions in this internal code that were possible now that they are gone.

At this point bringing them back would be a lot harder than "fix this bug immediately".

But I'd rather do many more refactorings and feature additions that would be pretty much impossible with theming engines.

And in the process, you leave behind an extremely useful and essential feature that enormous quantities of users are relying on.

I'm all for progress. But you can't throw your users under a bus during minor releases. That's against all good practices everywhere.

If you do in fact intend to completely axe this feature, I'd appreciate it if you would take over maintenance of the "oxygen-gtk" package from Hugo Pereira Da Costa and "port" it to whatever new Frankenstein interfaces you're developing. Perhaps in the process you will relearn the necessity of the features you have removed and broken. Or, more positively, perhaps you will succeed in such a porting effort, in which case, all parties involved will be satisfied.

Please do the responsible thing, and either support your users, or revert your changes so that your users may continue to support themselves. Anything to the contrary is sheer recklessness. It's my understanding that the Gnome project as a whole very much wants to shed that reputation. As a representative of your community, you'd best not reinforce an already tarnished image.

General request: When it comes to tone and personal criticism, please do respect https://wiki.gnome.org/Foundation/CodeOfConduct . Thanks everybody.

To keep this discussion constructive, it would be helpful if the Oxygen-GTK theme maintainer(s) and/or developer(s) filed separate issues for things that "had a very legitimate use case that can *NOT* be replicated in pure CSS alone" so that the CSS machinery *can* be made (if it hasn't already) to support them.

(In reply to Emmanuele Bassi (:ebassi) from comment #16)
> To keep this discussion constructive, it would be helpful if the Oxygen-GTK
> theme maintainer(s) and/or developer(s) filed separate issues for things
> that "had a very legitimate use case that can *NOT* be replicated in pure
> CSS alone" so that the CSS machinery *can* be made (if it hasn't already) to
> support them.

Will not happen, sorry. As described here: 
https://bugs.kde.org/show_bug.cgi?id=340288
oxygen-gtk3 will not be ported ( = not by me), to css. So that I will not, either, explore the many possibilities for CSS theming to look for the ones that I cannot implement. sorry. 

And I don't think this is how it is supposed to work anyway: deprecate ( = here: erase) an API for another one, between two minor releases, and let third party devs figure out what is missing in the new one.

To repeat what I said earlier, no application apis were removed or broken. And not to flog a dead horse, but this refusal at least puts the earlier statements about 'throwing users under the bus' into the proper context...

(In reply to Hugo Pereira Da Costa from comment #17)
> (In reply to Emmanuele Bassi (:ebassi) from comment #16)
> > To keep this discussion constructive, it would be helpful if the Oxygen-GTK
> > theme maintainer(s) and/or developer(s) filed separate issues for things
> > that "had a very legitimate use case that can *NOT* be replicated in pure
> > CSS alone" so that the CSS machinery *can* be made (if it hasn't already) to
> > support them.
> 
> Will not happen, sorry. As described here: 
> https://bugs.kde.org/show_bug.cgi?id=340288
> oxygen-gtk3 will not be ported ( = not by me), to css. So that I will not,
> either, explore the many possibilities for CSS theming to look for the ones
> that I cannot implement. sorry. 
> 

I guess I have not been very clear as to why I will not port oxygen-gtk to css:

I have some reasonable skills in c and c++. I have none in CSS (vanilla css, or the gtk version of it). In the past gtk had the proper api so that I could use the skills I have to implement a widget theme. It does not anymore and I do not have the skills to use the api it now offers. So I cannot perform what is required and one would have either to re-introduce the api for which I have skills, or find someone who as the proper skills to deal with the new one. As simple as that. No flame war intened, nor insult, towards anyone, be them gtk devs or users. Sorry. Just admitting my incompetence on the matter.

and Matthias: playing with words will lead you nowhere, sorry.

> "To repeat what I said earlier, no application apis were removed or broken. "

This is a joke. Yes, applications still compile. Maybe ABI has even been preserved! Great. But the functions that were called are now essentially no-ops. So... indeed, the API has been broken, since the behavior has changed significantly (namely, from "doing something" to "doing nothing").

(In reply to Jason A. Donenfeld from comment #21)
> > "To repeat what I said earlier, no application apis were removed or broken. "
> 
> This is a joke. Yes, applications still compile. Maybe ABI has even been
> preserved! Great. But the functions that were called are now essentially
> no-ops. So... indeed, the API has been broken, since the behavior has
> changed significantly (namely, from "doing something" to "doing nothing").

I think Matthias point is that "applications" (as in "evolution", or "nautilus") API has not been broken. (at least not with the theming engine removal). But theming (as in "oxygen-gtk3") definitly has. 

Strictly speaking this statement is correct, although irrelevant for the bug report at hand.

Of course an API contract is broken if you change it do nothing.

That’s called a regression bug. “API no longer works as advertised”

I’ve been following this report for a while. I had the low expectations that the things said here, e.g. comment #5:

> theming engines will be used until GTK+ 4

would be truthful, and the faint hope things would improve, but never once considered they’d get worse and you’d simply throw the hard work of Hugo under the bus.

This, and comments like “I'm actually happy that it's stopped working” are nothing short of bullying, which violates the Gnome CoC.

I'm an Ubuntu user who develops embedded applications. This weekend I installed Ubuntu 16.04 (with GTK+3.18) and Eclipse Mars. On 14.04 Eclipse Mars worked just fine. On 16.04 Eclipse was broken to the point of being unusable. GUI features often did nothing, such as selecting items from the menus (context menus still functioned). The IDE would hang when trying to open or import a project.

After hours of searching I found this

http://askubuntu.com/questions/776717/eclipse-using-high-cpu-after-upgrade-to-ubuntu-16-04

which indicated that a "fix" may be to force Eclipse to use GTK+2 instead of GTK+3. I followed it and Eclipse works again. It took me so long to find the above answer because there's a lot of forum chatter about Eclipse not working on Ubuntu 16.04, but most of it had no answers/solutions.

Eclipse is an application with a widespread user base that uses themes--it is not a theme--and for me and many other folks who posted in various forums it is totally unusable with GTK+3.18. If this bug report is why Eclipse is broken (all I know for sure is that GTK+2 works, GTK+3.10 works, GT+3.18 doesn't) then you are, indeed breaking applications.

I'm not posting to get help. I'm posting because of the attitude I see on this thread that concerns me. It tarnishes not only GTK+'s reputation, but the reputation of GNU/Linux and open source in general. You're perpetuating the "you can get it to work if you're willing to spend hours weeding through forum posts and enduring newbie insults" reputation of GNU/Linux.

Keep in mind your users are also folks like me who need your software, and the software that uses your software, to work so that they can do their work.

(In reply to Mark Perry from comment #24)
> I'm an Ubuntu user who develops embedded applications. This weekend I
> installed Ubuntu 16.04 (with GTK+3.18) and Eclipse Mars. On 14.04 Eclipse
> Mars worked just fine. On 16.04 Eclipse was broken to the point of being
> unusable. GUI features often did nothing, such as selecting items from the
> menus (context menus still functioned). The IDE would hang when trying to
> open or import a project.
> 
> After hours of searching I found this
> 
> http://askubuntu.com/questions/776717/eclipse-using-high-cpu-after-upgrade-
> to-ubuntu-16-04
> 
> which indicated that a "fix" may be to force Eclipse to use GTK+2 instead of
> GTK+3. I followed it and Eclipse works again. It took me so long to find the
> above answer because there's a lot of forum chatter about Eclipse not
> working on Ubuntu 16.04, but most of it had no answers/solutions.
> 
> Eclipse is an application with a widespread user base that uses themes--it
> is not a theme--and for me and many other folks who posted in various forums
> it is totally unusable with GTK+3.18. If this bug report is why Eclipse is
> broken (all I know for sure is that GTK+2 works, GTK+3.10 works, GT+3.18
> doesn't) then you are, indeed breaking applications.

Hello, Eclipse developer here: I work on SWT, upon which the Eclipse UI sits.

I would strongly recommend you use Eclipse Neon -- either a latest milestone build or a recent integration build. There have been significant changes since Mars especially on the GTK side of things. I would say the difference is nearly night and day in this respect. The particular bug with high CPU usage was fixed ~3 months ago IIRC. That being said if the issue still persists on a recent Neon build, please file a bug and add this bug as a dependency: https://bugs.eclipse.org/bugs/show_bug.cgi?id=492371

As for gtkthemeengine, I'm happy it's been deprecated. The CSS machinery in GTK is a lot easier to use, more consistent (especially now with GTK3.20), and more reliable. We also had constant issues with Oxygen-GTK causing Eclipse to crash.

(In reply to Eric Williams from comment #25)
> (In reply to Mark Perry from comment #24)
> > I'm an Ubuntu user who develops embedded applications. This weekend I
> > installed Ubuntu 16.04 (with GTK+3.18) and Eclipse Mars. On 14.04 Eclipse
> > Mars worked just fine. On 16.04 Eclipse was broken to the point of being
> > unusable. GUI features often did nothing, such as selecting items from the
> > menus (context menus still functioned). The IDE would hang when trying to
> > open or import a project.
> > 
> > After hours of searching I found this
> > 
> > http://askubuntu.com/questions/776717/eclipse-using-high-cpu-after-upgrade-
> > to-ubuntu-16-04
> > 
> > which indicated that a "fix" may be to force Eclipse to use GTK+2 instead of
> > GTK+3. I followed it and Eclipse works again. It took me so long to find the
> > above answer because there's a lot of forum chatter about Eclipse not
> > working on Ubuntu 16.04, but most of it had no answers/solutions.
> > 
> > Eclipse is an application with a widespread user base that uses themes--it
> > is not a theme--and for me and many other folks who posted in various forums
> > it is totally unusable with GTK+3.18. If this bug report is why Eclipse is
> > broken (all I know for sure is that GTK+2 works, GTK+3.10 works, GT+3.18
> > doesn't) then you are, indeed breaking applications.
> 
> Hello, Eclipse developer here: I work on SWT, upon which the Eclipse UI sits.
> 
> I would strongly recommend you use Eclipse Neon -- either a latest milestone
> build or a recent integration build. There have been significant changes
> since Mars especially on the GTK side of things. I would say the difference
> is nearly night and day in this respect. The particular bug with high CPU
> usage was fixed ~3 months ago IIRC. That being said if the issue still
> persists on a recent Neon build, please file a bug and add this bug as a
> dependency: https://bugs.eclipse.org/bugs/show_bug.cgi?id=492371
> 
> As for gtkthemeengine, I'm happy it's been deprecated. The CSS machinery in
> GTK is a lot easier to use, more consistent (especially now with GTK3.20),
> and more reliable. We also had constant issues with Oxygen-GTK causing
> Eclipse to crash.

Thanks for the clarification and info! I didn't expect a reply.

My issue was total malfunction, not high CPU usage, but the fix for the latter made it work.

I don't know enough to have an opinion on the "deprecated" status, since I don't develop themes. Progress is good, certainly, and I posted because of how it looked like this was handled. If I'm wrong, I apologize and will shut up.

To me "deprecated" means "we'll leave it alone in this release and remove it in some future release," whereas it looks from this thread like what happened was "we'll strip out all the meaningful functionality in this release and the API later on."

My point is simply that handling progress this way is almost never without unintended consequences, and that those consequences are part of what can turn users and prospective users off to your software or platform.

The problem is threefold:

1. As you said: this isn’t deprecation, this is feature removal while stubbing out the APIs
2. The CSS approach isn’t as powerful as the theme engine (e.g. we can’t read the color values from the plasma theme), therefore it isn’t progress. Or, to phrase it better, it’s not a straight upgrade
3. The attitude of GNOME developers towards other people’s expectations and work

People got frustrated because there was no warning that their hard work would be invalidated because the deprecation policy they relied on was a lie. And because e.g. in comment #7, an adult literally told people he’s glad that their work was for naught.