[gtkmm-documentation/wip/dboles/make_managed-etc-4: 1/2] Document the new make_managed() & prefer to use it
- From: Daniel Boles <dboles src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gtkmm-documentation/wip/dboles/make_managed-etc-4: 1/2] Document the new make_managed() & prefer to use it
- Date: Sat, 13 Oct 2018 15:22:41 +0000 (UTC)
commit ef84bbdcde3b36d1529f59a113ae0d20207dda2b
Author: Daniel Boles <dboles src gmail com>
Date: Sat Oct 13 15:54:03 2018 +0100
Document the new make_managed() & prefer to use it
This performs creation and manage()ment in a single step and therefore
avoids the user having to write the discouraged new operator, looks more
like Standard C++ things like make_shared(), etc. So, move our examples
to it, and elaborate on why it is preferable to manage() or new/delete.
https://gitlab.gnome.org/GNOME/gtkmm/issues/33
docs/tutorial/C/index-in.docbook | 76 +++++++++++++++++++++++++++-------------
1 file changed, 52 insertions(+), 24 deletions(-)
---
diff --git a/docs/tutorial/C/index-in.docbook b/docs/tutorial/C/index-in.docbook
index 3d04fb6..7cc9341 100644
--- a/docs/tutorial/C/index-in.docbook
+++ b/docs/tutorial/C/index-in.docbook
@@ -423,7 +423,15 @@ Most of the chapters in this book deal with specific widgets. See the <link link
<para>Although you can specify the layout and appearance of windows and widgets with C++ code, you will
probably find it more convenient to design your user interfaces with <literal>Glade</literal> and load them
at runtime with <literal>Gtk::Builder</literal>. See the <link linkend="chapter-builder">Glade and
Gtk::Builder</link> chapter.
</para>
-<para>Although >kmm; widget instances have lifetimes and scopes just like those of other C++ classes,
>kmm; has an optional time-saving feature that you will see in some of the examples.
<function>Gtk::manage()</function> allows you to say that a child widget is owned by the container into which
you place it. This allows you to <function>new</function> the widget, add it to the container and forget
about deleting it. You can learn more about >kmm; memory management techniques in the <link
linkend="chapter-memory">Memory Management chapter</link>.
+<para>Although >kmm; widget instances have lifetimes and scopes just like
+those of other C++ classes, >kmm; has an optional time-saving feature that you
+will see in some of the examples. The <function>Gtk::make_managed()</function>
+allows you to create a new widget and state that it will become owned by the
+container into which you place it. This allows you to create the widget, add it
+to the container and not be concerned about deleting it, since that will occur
+when the parent container (which may itself be managed) is deleted. You can
+learn more about >kmm; memory management techniques in the
+<link linkend="chapter-memory">Memory Management chapter</link>.
</para>
</sect1>
@@ -503,7 +511,8 @@ The C++ wrapper shall be explicitly deleted if
<itemizedlist>
<listitem><para>it's a widget or other class that inherits from <classname>Gtk::Object</classname>,
and</para></listitem>
<listitem><para>the C instance has a floating reference when the wrapper is created, and</para></listitem>
-<listitem><para><function>Gtk::manage()</function> is not called.</para></listitem>
+<listitem><para>it was not created using <function>Gtk::make_managed()</function>, and</para></listitem>
+<listitem><para><function>Gtk::manage()</function> has not been called on it.</para></listitem>
</itemizedlist>
<function>Glib::wrap()</function> binds the C and C++ instances to each other.
Don't delete the C++ instance before you want the C instance to die.
@@ -979,9 +988,9 @@ public:
RadioButtons::RadioButtons()
{
Gtk::RadioButton::Group group;
- Gtk::RadioButton* m_rb1 = Gtk::manage(new Gtk::RadioButton(group, "button1"));
- Gtk::RadioButton* m_rb2 = Gtk::manage(new Gtk::RadioButton(group, "button2"));
- Gtk::RadioButton* m_rb3 = Gtk::manage(new Gtk::RadioButton(group, "button3"));
+ Gtk::RadioButton* m_rb1 = Gtk::make_managed<Gtk::RadioButton>(group, "button1");
+ Gtk::RadioButton* m_rb2 = Gtk::make_managed<Gtk::RadioButton>(group, "button2");
+ Gtk::RadioButton* m_rb3 = Gtk::make_managed<Gtk::RadioButton>(group, "button3");
}</programlisting>
<para>
@@ -2515,7 +2524,7 @@ appropriate <classname>Gtk::TreeView::Column</classname> widget.
Here is some example code, which has a pixbuf icon and a text name in the same column:
</para>
<programlisting>Gtk::TreeView::Column* pColumn =
- Gtk::manage(new Gtk::TreeView::Column("Icon Name"));
+ Gtk::make_managed<Gtk::TreeView::Column>("Icon Name");
// m_columns.icon and m_columns.iconname are columns in the model.
// pColumn is the column in the TreeView:
@@ -2549,7 +2558,7 @@ if(pColumn)
actions. For instance:
</para>
<programlisting>Gtk::CellRendererToggle* pRenderer =
- Gtk::manage( new Gtk::CellRendererToggle() );
+ Gtk::make_managed<Gtk::CellRendererToggle>();
pRenderer->signal_toggled().connect(
sigc::bind( sigc::mem_fun(*this,
&Example_TreeView_TreeStore::on_cell_toggled), m_columns.dave)
@@ -3527,7 +3536,7 @@ to a container. For instance:
<programlisting>
<![CDATA[Glib::RefPtr<Glib::Object> object = m_refBuilder->get_object("menubar");
Glib::RefPtr<Gio::Menu> gmenu = Glib::RefPtr<Gio::Menu>::cast_dynamic(object);
-Gtk::MenuBar* pMenuBar = Gtk::manage(new Gtk::MenuBar(gmenu));
+Gtk::MenuBar* pMenuBar = Gtk::make_managed<Gtk::MenuBar>(gmenu);
m_Box.pack_start(*pMenuBar, Gtk::PACK_SHRINK);
Gtk::Toolbar* toolbar = nullptr;
@@ -5261,7 +5270,7 @@ Gtk::Widget* CustomPrintOperation::on_create_custom_widget()
Gtk::Box* hbox = new Gtk::Box(Gtk::ORIENTATION_HORIZONTAL, 8);
hbox->set_margin(6);
- Gtk::Label* label = Gtk::manage(new Gtk::Label("Enter some text: "));
+ Gtk::Label* label = Gtk::make_managed<Gtk::Label>("Enter some text: ");
hbox->pack_start(*label, false, false);
hbox->pack_start(m_Entry, false, false);
@@ -5992,11 +6001,13 @@ increased data hiding and reduced dependencies.
<title>Dynamic allocation with new and delete</title>
<para>
-Although, in most cases, the programmer will prefer to allow containers to
-automatically destroy their children using <function>Gtk::manage()</function> (see
-below), the programmer is not required to use <function>Gtk::manage()</function>.
-The traditional <literal>new</literal> and <literal>delete</literal> operators
-may also be used.
+Usually, the programmer will prefer to allow containers to automatically destroy
+their children by creating them using <function>Gtk::make_managed()</function>
+(see below). This is not strictly required, as the <literal>new</literal> and
+<literal>delete</literal> operators may also be used, but modern C++ style
+discourages those in favour of safer models of memory management, so it is
+better to create widgets using <function>Gtk::make_managed()</function> and
+let their parent destroy them, than to manually perform dynamic allocation.
<programlisting>
Gtk::Button* pButton = new Gtk::Button("Test");
@@ -6017,29 +6028,46 @@ Here, the programmer deletes <varname>pButton</varname> to prevent a memory leak
Alternatively, you can let a widget's container control when the widget is
destroyed. In most cases, you want a widget to last only as long as the
container it is in. To delegate the management of a widget's lifetime to its
-container, first create it with <function>Gtk::manage()</function> and
+container, create it with <function>Gtk::make_managed()</function> and then
pack it into its container with <methodname>Gtk::Container::add()</methodname>,
<methodname>Gtk::Box::pack_start()</methodname>, or a similar method. Now the
widget will be destroyed whenever its container is destroyed.
</para>
<sect3 id="memory-managed-dynamic">
-<title>Dynamic allocation with manage() and add()</title>
+<title>Dynamic allocation with make_managed() and add()</title>
<para>
->kmm; provides the <function>manage()</function> function and
-<methodname>add()</methodname> methods to create and destroy widgets. Every widget
-except a top-level window must be added or packed into a container in order to
-be displayed. The <function>manage()</function> function marks a widget
-so that when the widget is added to a container, the container becomes
-responsible for deleting the widget.
+>kmm; provides the <function>make_managed()</function> function and
+<methodname>add()</methodname> methods to create and destroy widgets.
+</para>
+
+<para>
+Every widget except a top-level window must be added or packed into a container
+in order to be displayed. The <function>manage()</function> function marks an
+existing widget so that when the widget is added to a container, the container
+becomes responsible for deleting the widget, so the user need not do that
+themselves. The old way of creating widgets whose lifetime is managed by their
+parent in this way was to call <function>manage()</function>, passing in a
+<literal>new</literal> expression that created a dynamically allocated widget.
+</para>
+
+<para>
+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 <literal>new</literal> operator, which was
+required when passing a newly created widget to <function>manage()</function>.
+Therefore, >kmm; has added <function>make_managed()</function>, which combines
+creation and marking with <function>manage()</function> into a single step. This
+avoids you having to write <literal>new</literal>, which is discouraged in
+modern C++ style, and more clearly expresses intent to create a managed widget.
</para>
<para>
<programlisting>
MyContainer::MyContainer()
{
- Gtk::Button* pButton = Gtk::manage(new Gtk::Button("Test"));
+ Gtk::Button* pButton = Gtk::make_managed<Gtk::Button>("Test");
add(*pButton); //add *pButton to MyContainer
}
</programlisting>
@@ -9445,7 +9473,7 @@ _CLASS_GTKOBJECT(Button, GtkButton, GTK_BUTTON, Gtk::Bin, GtkBin)
<classname>Gtk::Object</classname>.</para>
<para>You might also derive non-widget classes from <classname>Gtk::Object</classname>
so they can be used without <classname>Glib::RefPtr</classname>. For instance,
- they could then be instantiated with <function>Gtk::manage()</function> or on the stack
+ they could then be instantiated with <function>Gtk::make_managed()</function> or on the stack
as a member variable. This is convenient, but you should use this only when you are sure
that true reference-counting is not needed. We consider it useful for widgets.</para>
</sect3>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]