This is another take on trying to clean up the deprecation warning situation in Spice-Gtk.
Let me know if it goes in the right direction. With this patchset deprecation warnings are enabled again and there are no remaining warnings, except those in src/controller since they happen in generated code and I don't know how to modify it so it does not use the deprecated GSimpleAsyncResult class (and I don't really want to do the conversion to GTask either). Of course those could also be avoided by keeping the -Wno-deprecated-declarations in src/controller but then nobody will fix that code. Francois Gouget (10): build-sys: Enable deprecation warnings instead of ignoring them entirely First the Spice-Gtk situation is different from the Spice server one. In Spice server the only deprecated APIs we use are Spice's own. So new uses will only result from changes in Spice's code. Thus it's ok to have them produce an error to prevent their use from spreading. In Spice-Gtk the deprecated APIs are almost all GTK APIs. Those can be deprecated at any time independently of Spice-Gtk's code. Thus we don't want deprecation warnings to break the build. But so far they have be completely disabled, thus ensuring no one will ever fix them. So the first patch turns them back to regular warnings with -Wno-error. gtk: Avoid gtk_vbox_new(); it is deprecated gtk: Avoid gtk_hbutton_box_new(); it is deprecated gtk: GtkTable is deprecated so use GtkGrid instead These patches just fix usage of some deprecated APIs. Fixes that would likely have happened not long after GTK+ 2.0 support was dropped if deprecation warnings had not been disabled. Those should clearly be applied even if we don't enable deprecation warnings. gtk: Ignore GLib's too-new warnings where we explicitly check its version GLib also issues warnings for APIs that are more recent than GLIB_VERSION_MIN_REQUIRED. But these happen in suitable #if sections and thus should be ignored. build-sys: Remove SPICE_NO_DEPRECATED build-sys: Use spice-protocol's deprecation macros This one may be somewhat questionable since it spice-protocol's macros don't use GLib's helpers and thus don't support Clang and Visual C++. This means we may locally disable these warnings with G_GNUC_BEGIN_IGNORE_DEPRECATIONS when they would not have in fact been issued at all. * It's not like this issue would cause compilation errors or warnings (the opposite) so maybe it should just be ignored. * Or maybe it means Spice-Gtk should keep using its own deprecation macros, but it would be a bit of a shame that spice-protocol's macros cannot even be reused by all Spice's codebase. * Or maybe spice-protocol should use GLib's macros if available, even if it is a bit distasteful. session: Disable the spice_audio_new() deprecation warning I donsider this to be a "false positive", although maybe the code should be rewritten to avoid it. RFC: gtk: Temporarily ignore the keyboard/mouse grabbing deprecation warnings RFC: spicy: Temporarily ignore deprecation warnings These two really just silence warnings that should be fixed. So if someone fixes these warnings they will not be needed. Otherwise I think it's still better than globally disabling the deprecation warnings because these patches are local and add nice FIXME warnings in the relevant places. m4/spice-compile-warnings.m4 | 2 +- src/Makefile.am | 1 - src/controller/Makefile.am | 1 - src/spice-channel.h | 5 +++-- src/spice-gtk-session.c | 5 +++++ src/spice-session.c | 2 ++ src/spice-util.h | 14 +++----------- src/spice-widget-egl.c | 3 +++ src/spice-widget.c | 30 ++++++++++++++++++++++++++++++ src/spicy-connect.c | 22 +++++++++++----------- src/spicy.c | 3 +++ src/usb-device-manager.h | 2 +- 12 files changed, 62 insertions(+), 28 deletions(-) -- 2.9.3 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
