From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.66.27.67 with SMTP id r3mr6511124pag.27.1378795249269;
        Mon, 09 Sep 2013 23:40:49 -0700 (PDT)
X-Received: by 10.49.129.65 with SMTP id nu1mr451qeb.41.1378795248758; Mon, 09
 Sep 2013 23:40:48 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!b4no8164252pbq.1!news-out.google.com!z6ni37714pbu.0!nntp.google.com!y3no13360154pbx.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 9 Sep 2013 23:40:48 -0700 (PDT)
In-Reply-To: <1rlxflx3vn7d2$.gwfur2yxe3we.dlg@40tude.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=88.181.126.208;
 posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 88.181.126.208
References: 
 <66ce64dd-1428-4db1-8d0e-a4ba68f9f09d@e27g2000vbu.googlegroups.com>
 <t4dxgi068wxi$.asa8tzvc65eq$.dlg@40tude.net> <ji78ll$rj$1@dont-email.me>
 <1dfmw0tj24ol0.pdfi51pextgu$.dlg@40tude.net> <ji95g5$g2n$1@dont-email.me>
 <1rlxflx3vn7d2$.gwfur2yxe3we.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3ae71819-7fa1-4d45-9363-a0b6aa1fde3c@googlegroups.com>
Subject: Re: help building ada with glade
From: briot.emmanuel@gmail.com
Injection-Date: Tue, 10 Sep 2013 06:40:49 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:17149
Date: 2013-09-09T23:40:48-07:00
List-Id: <comp.lang.ada>

> But it is impossible to do due to GTK design [**]. The most typical and
> safe pattern for handling signals is that a composite widget connects to a
> signal of its child and passes itself as a parameter to the signal handler,
> because you need to know it in the handler. For this
> Gtk.Handlers.User_Callback must be instantiated. I have no idea how a code
> generator could deal with this in the round-trip manner.

Just wanted to react on this small technical point: you do not want to use
a User_Callback if you are passing a child of GObject_Record in parameter.
Instead, use Object_Connect, which has the benefits of automatically
disconnecting whenever one of the two widgets (the one for the event, the
one in parameter) is destroyed. 
Plus that limits the number of instances of User_Callback, and thus reduces
the size of the executable.