| Chapter 30. Recommended Techniques | ||
|---|---|---|
 |
|
|
| Chapter 30. Recommended Techniques | ||
|---|---|---|
|
|
|
|
Table of Contents
This section is simply a gathering of wisdom, general style guidelines and hints for creating gtkmm applications.
Use Meson! It is your friend :)
It examines C and C++ files, determines how they depend on each other,
and generates build.ninja or an equivalent file so the
files can be compiled in the correct order. Meson
permits automatic configuration of software installation, handling a large
number of system quirks to increase portability.
Subclass Widgets to better organize your code. You should probably
subclass your main Window at least. Then you can
make your child Widgets and signal handlers members of that class.
Create your own signals instead of passing pointers around. Objects can
communicate with each other via signals and signal handlers. This is much
simpler than objects holding pointers to each other and calling each
other's methods. gtkmm's classes use special versions of
sigc::signal, but you should use normal
sigc::signals, as described in the
libsigc++ documentation.
Most applications will have only one Window, or
only one main window. These applications can use
Gtk::Application::make_window_and_run(int argc, char** argv, T_Args&&... args).
It creates and shows a window. When the window is hidden, make_window_and_run()
deletes the window and returns to the caller.
This might happen when the user closes the window, or when your code decides to
hide the window with set_visible(false). You can prevent the user from
closing the window (for instance, if there are unsaved changes) by
overriding Gtk::Window::on_close_request().
Most of our examples use this technique.
|
|
|
|
| Example |  |
Using a gtkmm widget |