Gtkmm-forge digest, Vol 1 #1139 - 3 msgs

[gtkmm-forge-request lists sourceforge net]

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  A daily digest is sent to gtkmm-main, to encourage people to help fixing the bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 332446] API additions (gtkmm (bugzilla.gnome.org))
   2. [Bug 332446] API additions (gtkmm (bugzilla.gnome.org))
   3. [Bug 332446] API additions (gtkmm (bugzilla.gnome.org))

--__--__--

Message: 1
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Tue, 30 May 2006 07:16:50 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 332446] API additions

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D332446
 gtkmm | general | Ver: 2.8.x





------- Comment #8 from Maxim Udushlivy  2006-05-30 11:16 UTC -------
>This is neither very meaningful or true. Managed child widgets are simpl=
y
>destroyed when their parent widgets are destroyed. No more, no less. And=
 there
>is no additional "gtk destroyed" concept. When I say destroyed I am talk=
ing
>about normal C++ memory management.

GTK+ widget can be in a "destroyed" state and occupy memory until there a=
re no
references to it. See refcounting.txt in GTK+ source tarball under docs
directory.


>You can put both Glib::RefPtr<SomeGlibObject> and Gtk::SomeWidget in a g=
eneric
>sharedptr<> in C++.

This is not very useful because such sharedptr's will be incompatible: on=
e that
holds Glib::RefPtr<> cannot take Gtk::Widget.


>Reference-counting of widgets will not really work in GTK+
>in C either, because parent widgets don't care - they just destroy child
>widgets regardless.

See refcounting.txt


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 2
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Tue, 30 May 2006 07:28:03 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 332446] API additions

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D332446
 gtkmm | general | Ver: 2.8.x





------- Comment #9 from Murray Cumming  2006-05-30 11:28 UTC -------
> GTK+ widget can be in a "destroyed" state and occupy memory until there=
 are no
> references to it. See refcounting.txt in GTK+ source tarball under docs
> directory.

I believe this is a very short intermediate state. As soon as destruction
happens we forget about widgets and try to never use them again. This sta=
te is
of no use to application programmers.

Likewise, there is no Gtk::Object::destroy() in gtkmm, because C++ has de=
lete.

> >You can put both Glib::RefPtr<SomeGlibObject> and Gtk::SomeWidget in a=
 generic
> >sharedptr<> in C++.
> This is not very useful because such sharedptr's will be incompatible: =
one that
> holds Glib::RefPtr<> cannot take Gtk::Widget.

Obviously not and I don't know why you would want to do that.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


--__--__--

Message: 3
To: gtkmm-forge lists sourceforge net
From: "gtkmm (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>
Date: Tue, 30 May 2006 10:37:19 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 332446] API additions

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D332446
 gtkmm | general | Ver: 2.8.x





------- Comment #10 from Maxim Udushlivy  2006-05-30 14:37 UTC -------
>I believe this is a very short intermediate state. As soon as destructio=
n
>happens we forget about widgets and try to never use them again. This st=
ate is
>of no use to application programmers.

The main conclusion here is that this "corner" state is valid and not a b=
ug.
The state may last arbitrary time unless a widget is referenced by its
container only.


>Obviously not and I don't know why you would want to do that.

As I said earlier, to have Glib::RefPtr<Glib::Object> that can hold any G=
TK+
object including Gtk::Widget. Actually this works perfectly now, the ques=
tion
was whether to add "T * Glib::RefPtr<T>::get()" function. =20

The real-world examples that require such functionality usually are not
ordinary GUI applications. One good example is a GUI serialization. It is
convenient and reasonable for the implementation to use the same code pat=
h for
storing and loading Glib::Object's, Gtk::Object's and Gtk::Window's.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



--__--__--

_______________________________________________
Gtkmm-forge mailing list
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest