How to not use templates or inheritance in gtkmm4 HelloWorld example?

[Hamza_Algohary]

In gtk3 I could just instantiate a window, and Gtk::Application and call application->run.

While in Gtk4 I’m required to inherit from window and pass the new class as a template argument to the run function as in the tutorial there Hello World in gtkmm

But it doesn’t make any sense for me to do it this way, plus that the examples I see in other languages don’t require this, so why does the c++ binding require this way. In other words, how can I do it the old way.

Another question: I’ve read on reddit that that gtkmm is going to be abandoned soon, is that true? I’ve seen gnome-terminal being replaced by console and the gnome-terminal is written in c++, so I’ve started getting worried.

Thanks in advance.

[ebassi (Emmanuele Bassi)]

@Hamza_Algohary

In gtk3 I could just instantiate a window, and Gtk::Application and call application->run.

This was a gtkmm only API, which incidentally conflicted with the underlying GtkApplication API.

@Hamza_Algohary

But it doesn’t make any sense for me to do it this way, plus that the examples I see in other languages don’t require this, so why does the c++ binding require this way. In other words, how can I do it the old way.

Every language has to do this, since GtkApplication is the main entry point for all GTK applications.

You can use gtk_init() and then spin the default GMainContext yourself, but it’s pointless to do so.

@Hamza_Algohary

Another question: I’ve read on reddit that that gtkmm is going to be abandoned soon, is that true?

The current maintainer of the gtkmm bindings has said that he does not have enough time to devote to the project, yes.

@Hamza_Algohary

I’ve seen gnome-terminal being replaced by console and the gnome-terminal is written in c++,

The language used by libvte and gnome-terminal, and the replacement in the core GNOME apps, has nothing to do with the maintenance situation of gtkmm. Console still uses libvte internally, which is implemented using C++ even if it exposes a C API.

[Hamza_Algohary]

@ebassi

Every language has to do this, since GtkApplication is the main entry point for all GTK applications.

I’m not saying that I don’t want to use Gtk::Application, I just want to instaintiate the widgets in the main functions, isn’t that possible.

@ebassi

You can use gtk_init() and then spin the default GMainContext yourself, but it’s pointless to do so.

Can you refer me to an example on how to do that because I am anyway trying to do that for another purpose.

Can You also lead me to how might I help to maintain the binding if it’s not a hard task, I mean a tutorial for GObject introspection I think?

[ebassi (Emmanuele Bassi)]

@Hamza_Algohary

I’m not saying that I don’t want to use Gtk::Application, I just want to instaintiate the widgets in the main functions, isn’t that possible.

Correct, that’s not how applications work.

GtkApplication will notify you of when the application should present its window, because it supports single instantiation across multiple launches, and remote activation via IPC.

Building your UI inside main is not really how things work any more.

@Hamza_Algohary

Can you refer me to an example on how to do that because I am anyway trying to do that for another purpose.

The only purpose for this is to write small test cases; anything more complicated than that is out of scope, and you are strongly encouraged to use GtkApplication. You don’t even need to subclass it: you can instantiate it and connect to the activate signal.

@Hamza_Algohary

Can You also lead me to how might I help to maintain the binding if it’s not a hard task, I mean a tutorial for GObject introspection I think?

The C++ bindings do not use gobject-introspection: they have their own mechanism to describe the C API and generate code. You’ll need to look at the gtkmm repository and ask on the gtkmm mailing list.

[Hamza_Algohary]

Okay, Thank you for replying to alot of my questions today .

[kjellahl (Kjell Ahlstedt)]

I’ve read on reddit that gtkmm is going to be abandoned soon, is that true?

I announced more than a year ago that I will spend less time with gtkmm in the future.
See https://mail.gnome.org/archives/gtkmm-list/2021-February/msg00003.html.
It’s not so much because of lack of time. But I never had the intention to become
the main maintainer of gtkmm and a bunch of other C++ modules.

The developers of Inkscape have expressed their concern. No one has offered to replace me.

you can instantiate it (Gtk::Application) and connect to the activate signal.

That’s what application->make_window_and_run() does. It creates a window in a
signal_activate() handler.

Most example programs also in gtkmm3 subclass Gtk::Window or Gtk::ApplicationWindow
and create the other widgets in its constructor. See e.g. the Hello World program at
Hello World in gtkmm.
The difference between gtkmm3 and gtkmm4 is that the HelloWorld window is created in
the main() function in gtkmm3.

The Building Applications chapter in the gtkmm tutorial shows how a window is created
in Gtk::Application::on_activate() also in gtkmm3.
https://developer-old.gnome.org/gtkmm-tutorial/3.24/chapter-building-applications.html.en

Can You also lead me to how might I help to maintain the binding

You can look at Wrapping C Libraries with gmmproc.
It does not tell you everything you need in order to maintain gtkmm, but it’s a
fairly good start.

Gtkmm depends on other C++ modules that need some maintenance: mm-common,
libsigc++, cairomm, glibmm, pangomm. Gtkmm3 also depends on atkmm.

[zbrown (Zander Brown)]

@Hamza_Algohary

Another question: I’ve read on reddit that that gtkmm is going to be abandoned soon, is that true? I’ve seen gnome-terminal being replaced by console and the gnome-terminal is written in c++, so I’ve started getting worried.

Just for clarity here: g-t/vte roll their own in-tree “bindings” - effectively just using the C API directly - and don’t use gtkmm et al