[gtkmm] Gtkmm-forge digest, Vol 1 #773 - 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 154068]  - Access to human readable string from Gtk::AccelKey would be nice (bugzilla-daemon bugzilla gnome org)
   2. [Bug 154018]  - A Glib::RefPtr bound to a slot stays around forever (bugzilla-daemon bugzilla gnome org)
   3. [Bug 154498] New:  - Unnecessary warning on console: signalproxy_connectionnode.cc (bugzilla-daemon bugzilla gnome org)

--__--__--

Message: 1
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon,  4 Oct 2004 01:52:51 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 154068]  - Access to human readable string from Gtk::AccelKey would be nice

http://bugzilla.gnome.org/show_bug.cgi?id=154068
gtk+ | general | Ver: unspecified





------- Additional Comments From mclasen redhat com  2004-10-04 01:52 -------
Created an attachment (id=32194)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=32194&action=view)
a quick patch

Here is a patch which factors the requested functionality out from
gtkaccellabel and adds gtk_accelerator_display_name().

------- You are receiving this mail because: -------
You are the assignee for the bug.


--__--__--

Message: 2
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon,  4 Oct 2004 16:48:21 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 154018]  - A Glib::RefPtr bound to a slot stays around forever

http://bugzilla.gnome.org/show_bug.cgi?id=154018
libsigc++ | general | Ver: 2.0

plangdale vmware com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin-ml hippogriff de
             Status|UNCONFIRMED                 |RESOLVED
          Component|object                      |general
            Product|glibmm                      |libsigc++
         Resolution|                            |FIXED
            Version|2.4.x                       |2.0



------- Additional Comments From plangdale vmware com  2004-10-04 16:48 -------
The fix for bug 152323 seems to have fixed this. We don't see this as a leak
because the ref holder is the object that's leaked.

------- You are receiving this mail because: -------
You are the assignee for the bug.


--__--__--

Message: 3
From: bugzilla-daemon bugzilla gnome org
To: gtkmm-forge lists sourceforge net
Cc: 
Date: Mon,  4 Oct 2004 17:26:30 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 154498] New:  - Unnecessary warning on console: signalproxy_connectionnode.cc

http://bugzilla.gnome.org/show_bug.cgi?id=154498
glibmm | general | Ver: 2.4.x

           Summary: Unnecessary warning on console:
                    signalproxy_connectionnode.cc
           Product: glibmm
           Version: 2.4.x
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: minor
          Priority: Normal
         Component: general
        AssignedTo: gtkmm-forge lists sourceforge net
        ReportedBy: plangdale vmware com


Martin's fix for a memory leak in libsigc++ means that a lot more objects are
actually getting deleted which is good, but it's revealed that glibmm seems to
be producing an unnecessary g_warning when the object a signalproxy is watching
is destroyed.

In SignalProxyConnectionNode::notify the comment says:

// If there is no object, this call was triggered from destroy_notify_handler()
// because we set conn->object to 0 there:

which sounds reasonable enough, but the code then goes on to emit a g_warning
when it detects this case, which looks ugly and unprofessional.

My particular case is one where both gtk and gtkmm destroy a single object on
the same event. The last ref to a widget goes away causing gtk to destroy it,
which leads in turn to destroying a GtkAction. destroy_notify_handler is called
on the signalproxy for that action, but after this happens, gtkmm is notified
that the widget went away causing the gtkmm wrapper to be deleted which in turn
notifies the GtkAction's wrapper through sigc::trackable. Thus we hit this
particular case.

There doesn't seem to be anything wrong with this course of events so the
warning is inappropriate.

It's a trivial change which I can make myself if this is the correct thing to do.

------- You are receiving this mail because: -------
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