On Thu, 2010-03-25 at 01:57 +, Chris Vine wrote:
In cases where GTK+ does not in fact
intend ownership to be passed, gtkmm gets round this by incrementing
the reference count in the getter function, thus neutering the RefPtr,
but also leaving open the possibility of a reference being owned
On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming murr...@murrayc.com wrote:
On Thu, 2010-03-25 at 01:57 +, Chris Vine wrote:
In cases where GTK+ does not in fact
intend ownership to be passed, gtkmm gets round this by incrementing
the reference count in the getter function, thus
On Thu, 2010-03-25 at 10:52 +, Chris Vine wrote:
On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming murr...@murrayc.com wrote:
On Thu, 2010-03-25 at 01:57 +, Chris Vine wrote:
In cases where GTK+ does not in fact
intend ownership to be passed, gtkmm gets round this by incrementing
On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming murr...@murrayc.com wrote:
I'm sorry for not taking the time to consider this discussion fully
right now, but I do want to revisit it properly for gtkmm 3. I hope to
have time later. Right now, I'm not putting much thought into gtkmm 3
because
On Thu, 25 Mar 2010 12:17:01 +0100
Murray Cumming murr...@murrayc.com wrote:
What would some application code look like if you fixed this in the
gtkmm API?
A minimal interface would be something like:
Gtk::WeakPtrGtk::TreeSelection s = tree_view.get_selection();
...
[some code blocks
On Thu, 25 Mar 2010 13:13:32 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
But WeakPtr could be made thread safe in the way I have mentioned,
because from from glib-2.8 the GObject reference count is thread safe:
but I doubt it is worth it (and doing so would make the interface more
On Thu, Mar 25, 2010 at 10:08 AM, Chris Vine
ch...@cvine.freeserve.co.uk wrote:
On Thu, 25 Mar 2010 13:13:32 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
But WeakPtr could be made thread safe in the way I have mentioned,
because from from glib-2.8 the GObject reference count is thread
2010/3/25 Chris Vine ch...@cvine.freeserve.co.uk:
On Thu, 25 Mar 2010 09:46:08 +0100
Murray Cumming murr...@murrayc.com wrote:
I'm sorry for not taking the time to consider this discussion fully
right now, but I do want to revisit it properly for gtkmm 3. I hope to
have time later. Right now,
On Thu, 2010-03-25 at 14:08 +, Chris Vine wrote:
Glib::WeakPtrGtk::TreeSelection s = tree_view.get_selection();
...
[some code blocks later]
{ // scope block for Lock
Glib::WeakPtrGtk::TreeSelection::Lock(s); // take a strong
reference
if (s)
On Thu, 2010-03-25 at 12:35 -0400, Paul Davis wrote:
as i've mentioned to daniel on IRC, it would make our life in ardour
MUCH easier if all gtkmm objects were reference counted with both weak
and strong references available. we have a very nasty and hard to deal
with situation right now where
On Thu, 2010-03-25 at 18:31 +0100, Murray Cumming wrote:
On Thu, 2010-03-25 at 14:08 +, Chris Vine wrote:
Glib::WeakPtrGtk::TreeSelection s = tree_view.get_selection();
...
[some code blocks later]
{ // scope block for Lock
Glib::WeakPtrGtk::TreeSelection::Lock(s); //
On Thu, 25 Mar 2010 12:35:40 -0400
Paul Davis p...@linuxaudiosystems.com wrote:
i prefer the boost syntax for this:
boost::weak_ptrFoo weak_foo = ;
...
[ // scope begins for use of referenced object ...
boost::shared_ptrFoo shared_foo = weak_foo.lock ();
On Thu, 2010-03-25 at 14:58 -0500, Jonathon Jongsma wrote:
For example, the following commonly-used one-liner:
tree_view.get_selection()-set_mode(...);
would become (without validity-checking):
tree_view.get_selection().lock()-set_mode(...);
Sorry, what does that lock() do in this case?
I
On Thu, 25 Mar 2010 23:45:24 +0100
Murray Cumming murr...@murrayc.com wrote:
On Thu, 2010-03-25 at 14:58 -0500, Jonathon Jongsma wrote:
For example, the following commonly-used one-liner:
tree_view.get_selection()-set_mode(...);
would become (without validity-checking):
14 matches
Mail list logo
