GtkDialog is deprecated, but all subclasses are not

[kjellahl (Kjell Ahlstedt)]

The GtkDialog class has been deprecated, but its subclasses GtkPageSetupUnuxDialog
and GtkPrintUnixDialog are not deprecated. How is that supposed to work, if you
want to avoid using deprecated API? I suppose you can use GtkPageSetupUnuxDialog
or GtkPrintUnixDialog, and avoid GtkDialog API as much as possible.
But it’s hard to avoid connecting to the deprecated GtkDialog::response signal.

I know that deprecation does not imply removal in gtk4, only removal in a future gtk5.
In gtkmm, that’s not unconditionally true. It’s possible (but seldom done) to build
gtkmm without deprecated API. It makes me wonder if it’s wise to deprecate all of
Gtk::Dialog in gtkmm.

[ebassi (Emmanuele Bassi)]

@kjellahl

The GtkDialog class has been deprecated, but its subclasses GtkPageSetupUnuxDialog
and GtkPrintUnixDialog are not deprecated.

Strictly speaking, you don’t really need to use those dialogs at all: printing is done via the GtkPrintOperation API. Those dialogs exist only to let you control the print set up with custom widgets, but that does not really work when sandboxing an application, so they are not recommended for newly written code.

The plan is to drop the GtkUnixPrint dialogs soon, and replace them with an object-based async API: wip: print dialog api (!5484) · Merge requests · GNOME / gtk · GitLab

It’ll likely be ready for GTK 4.12, at which point we’ll deprecate that API.

@kjellahl

How is that supposed to work, if you
want to avoid using deprecated API? I suppose you can use GtkPageSetupUnuxDialog
or GtkPrintUnixDialog, and avoid GtkDialog API as much as possible.
But it’s hard to avoid connecting to the deprecated GtkDialog::response signal.

Connecting to signals isn’t really affected by deprecation warnings, unless you run with G_ENABLE_DIAGNOSTIC=1 in your environment.

@kjellahl

It makes me wonder if it’s wise to deprecate all of
Gtk::Dialog in gtkmm.

Since it’s harder to deal with this with bindings that do code generation, then it’s entirely up to you to decide whether you want to deprecate Gtk::Dialog in gtkmm.

From a C perspective, using GDK_DISABLE_DEPRECATION_WARNINGS or G_GNUC_BEGIN_DISABLE_DEPRECATION/G_GNUC_END_DISABLE_DEPRECATION already avoids dealing with compiler warnings; I wonder if gtkmm should have something similar to let you deprecate API while still allowing your users to get by with no deprecation warnings.

[kjellahl (Kjell Ahlstedt)]

As the plan is to deprecate the GtkUnixPrint dialogs soon, I’ll probably wait
until that happens and then deprecate both Gtk::Dialog, Gtk::PageSetupUnixDialog
and Gtk::PrintUnixDialog. The Gtk::Dialog documentation already says it’s deprecated,
although that’s not properly marked in the code.

I wonder if gtkmm should have something similar to let you deprecate API while still allowing your users to get by with no deprecation warnings.

Users of gtkmm can choose to

• define the preprocessor constants GDKMM_DISABLE_DEPRECATED and GTKMM_DISABLE_DEPRECATED,
  and get compilation errors if they try to use deprecated API, or
• not define them, and get neither compilation warnings nor errors.

Unfortunately, there’s no way to get only warnings.