Komponenter

If a programmer does not need dynamic memory allocation, automatic widgets in class scope may be used. One advantage of automatic widgets in class scope is that memory management is grouped in one place. The programmer does not risk memory leaks from failing to delete a widget.

The primary disadvantage of using class scope widgets is revealing the class implementation rather than the class interface in the class header.

#include <gtkmm/button.h>
#include <gtkmm/window.h>
class Foo : public Gtk::Window
{
private:
  Gtk::Button theButton;
  // will be destroyed when the Foo object is destroyed
};

If a programmer does not need a class scope widget, a function scope widget may also be used. The advantages to function scope over class scope are the increased data hiding and reduced dependencies.

{
  Gtk::Button aButton;
  aButton.set_visible(true);
  ...
  app->run();
}

However, this technique is rarely useful. Most widgets can't safely be created before the application has been registered or activated. They can't safely be deleted after Gtk::Application::run() or Gtk::Application::make_window_and_run() returns.

Vanligen kommer programmeraren föredra att tillåta behållare att automatiskt förstöra sina underordnade genom att skapa dem med Gtk::make_managed() (se nedan). Detta är inte strikt nödvändigt då operatorerna new och delete också kan användas, men modern C++-stil avråder från dessa till förmån för säkrare minneshanteringsmodeller, så det är bättre att skapa komponenter med Gtk::make_managed() och låta deras överordnade förstöra dem än att manuellt utföra dynamisk allokering.

auto pButton = new Gtk::Button("Test");

// gör något användbart med pButton

delete pButton;

gtkmm provides ways including the make_managed() function and Gtk::Box::append() method to simplify creation and destruction of widgets whose lifetime can be managed by a parent.

Every widget except a top-level window must be added to a parent container in order to be displayed. The manage() function marks a widget so that when that widget is added to a parent container, said container becomes responsible for deleting the widget, meaning the user no longer needs to do so. The original way to create widgets whose lifetime is managed by their parent in this way was to call manage(), passing in the result of a new expression that created a dynamically allocated widget.

However, usually, when you create such a widget, you will already know that its parent container should be responsible for destroying it. In addition, modern C++ style discourages use of the new operator, which was required when passing a newly created widget to manage(). Therefore, gtkmm has added make_managed(), which combines creation and marking with manage() into a single step. This avoids you having to write new, which is discouraged in modern C++ style, and more clearly expresses intent to create a managed widget.

MyContainer::MyContainer()
{
  auto pButton = Gtk::make_managed<Gtk::Button>("Test");
  append(*pButton); //lägg till *pButton till MyContainer
}

Now, when objects of type MyContainer are destroyed, the button will also be deleted. It is no longer necessary to delete pButton to free the button's memory; its deletion has been delegated to the MyContainer object.

Om du aldrig la till komponenten till någon överordnad behållare så är det ditt ansvar att ta bort den. Om du lägger till den till en behållarkomponent, och sedan tar bort den (exempelvis med Gtk::Box::remove()), så tas den bort av behållaren.

Of course, a top-level container will not be added to another container. The programmer is responsible for destroying the top-level container using one of the traditional C++ techniques. Or you can let Gtk::Application::make_window_and_run() create a top-level window and delete it when it's hidden.