After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733298 - Useless runtime warnings about deprecated object properties
Useless runtime warnings about deprecated object properties
Status: RESOLVED DUPLICATE of bug 732184
Product: glib
Classification: Platform
Component: general
2.41.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 749195 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-07-17 08:30 UTC by Milan Crha
Modified: 2017-11-17 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2014-07-17 08:30:59 UTC
I just downloaded latest gtk3 with glib (glib-2.41.2 and gtk+-3.13.4) and I noticed immediately that the console is full of useless runtime warnings similar to the one below, when I run an application X.

> GLib-GObject-WARNING **: The property GtkImage:stock is deprecated and
> shouldn't be used anymore. It will be removed in a future version.

This is completely useless for various reasons:
- how am I, as a *regular user* of application X, supposed react to these
  warnings? I cannot do anything about it, as a *regular user*;
- what if the application X supports also older gtk/glib/... where these
  deprecated properties are still used and valid?
- what if it comes from an .ui file definition? (it makes the .ui files
  useless too, in some extent);
- my system logs are full of these useless warnings, which doesn't eat only
  my SSD disk space, but also wastes space in bug reports from tools which
  can upload these system logs as well;
- what is wrong with compiler warnings? That's the way how *a developer* of
  the application X is supposed to be notified about upcoming changes; the
  runtime is not meant for this at all;
- these useless warnings make the application X unusable with fatal-warnings,
  while it can still be completely free of any issue otherwise (note of
  the second ball, it can be valid to use the "old" properties)

I am aware of G_ENABLE_DIAGNOSTIC=0, but are you going to set this environment variable in each single destination where the new library can be deployed? Definitely not.

I suggest to change defaults, if you do not want to get rid of it completely. The default should be "off" state and *developers* can turn it on on demand, when *they want* to actually diagnose the code. Having this on by default brings just a bad experience to *users*.
Comment 1 Matthias Clasen 2014-07-18 20:00:30 UTC
I sympathize, but you are choosing to run development versions of glib and gtk+. We've found that deprecating properties is does not have the desired effect (of applications stopping to use them) unless we generate some noise about it.
Comment 2 Milan Crha 2014-07-21 11:47:35 UTC
(In reply to comment #1)
> I sympathize, but you are choosing to run development versions of glib and
> gtk+.

True, but the code read didn't suggest that the default will be different with a stable version. If the default is different there, then I'm fine. And it's basically what I suggest too.

> We've found that deprecating properties is does not have the desired
> effect (of applications stopping to use them)

Oh yeah, I can imagine. :)

> unless we generate some noise about it.

Still this is the worse option. Trust me, even WebKitGTK did try that, and it was not nice of them at all.

You should also provide tools to be able to check which deprecated symbols are used in the code base. Everyone can grep the source code, but not everyone can properly check .ui files. And updating .ui files is a nightmare.
Comment 3 Philip Withnall 2017-11-17 12:35:55 UTC
Let’s keep all the discussion about deprecation warnings in one place: bug #732184.

(Also, they were turned off by default for properties in commit 3bd1618ea955f950f87bc4e452029c5f0cea35aa, and have remained that way since.)

*** This bug has been marked as a duplicate of bug 732184 ***
Comment 4 Philip Withnall 2017-11-17 12:36:14 UTC
*** Bug 749195 has been marked as a duplicate of this bug. ***