Re: Unparenting from GtkWidget "destroy"

Kjell Ahlstedt via gtkmm-list <[email protected]> Sun, 10 Jul 2022 13:06:12 +0200
Newsgroups	gmane.comp.gnome.gtkmm
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============7514210952155278077==
Content-Type: multipart/alternative;
 boundary="------------7fg2iUjQNmLEJSOuZDZ2PCiY"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7fg2iUjQNmLEJSOuZDZ2PCiY
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Den 2022-07-09 kl. 18:50, skrev Andrew Potter via gtkmm-list:
> Beyond exposing the destroy signal, another approach might be adding a 
> virtual dispose method if there is some known problem with sigc++ at 
> this point in the object lifecycle.
Adding a virtual method to an existing class breaks ABI. It won't be done.
>
> Maybe Kjell knows there is a good reason to not expose signal destroy 
> / dispose in gtkmm? If so you'd have to settle for subclassing a 
> container, but otherwise I'd prefer all signals to be available.
>
No, I don't know why the destroy signal is not exposed in gtkmm. 
Probably no one thought it would be useful. Even confusing to most 
users? It's not explicitly ignored, probably because no one has been 
sure it's useless. And now it seems it is useful, even necessary, to 
some users.

I don't mind adding Gtk::Widget::signal_destroy() to gtkmm4. I'd prefer 
a merge request, If you, Baldvin, have write permission to gitlab you 
can even add it yourself. Adding a _WRAP_SIGNAL is trivial, but it needs 
a better description than the one that will be inherited from gtk.

Is this an issue mostly for people who write widgets intended for others 
to use in their applications? I suppose that people writing application 
programs wouldn't mind using boxes, grids and other container widgets.


--------------7fg2iUjQNmLEJSOuZDZ2PCiY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Den 2022-07-09 kl. 18:50, skrev Andrew
      Potter via gtkmm-list:<br>
    </div>
    <blockquote type="cite"
cite="mid:CABgWb1KugS0D_=n8UeFXnfZS68C-7uQwxt0mmgG89BOtd4XBTg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">Beyond exposing the destroy signal,
          another approach might be adding a virtual dispose method if
          there is some known problem with sigc++ at this point in the
          object lifecycle.</div>
      </div>
    </blockquote>
    Adding a virtual method to an existing class breaks ABI. It won't be
    done.<br>
    <blockquote type="cite"
cite="mid:CABgWb1KugS0D_=n8UeFXnfZS68C-7uQwxt0mmgG89BOtd4XBTg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Maybe Kjell knows there is a good reason to not expose
            signal destroy / dispose in gtkmm? If so you'd have to
            settle for subclassing a container, but otherwise I'd prefer
            all signals to be available.<br>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    <p>No, I don't know why the destroy signal is not exposed in gtkmm.
      Probably no one thought it would be useful. Even confusing to most
      users? It's not explicitly ignored, probably because no one has
      been sure it's useless. And now it seems it is useful, even
      necessary, to some users.</p>
    <p>I don't mind adding Gtk::Widget::signal_destroy() to gtkmm4. I'd
      prefer a merge request, If you, Baldvin, have write permission to
      gitlab you can even add it yourself. Adding a _WRAP_SIGNAL is
      trivial, but it needs a better description than the one that will
      be inherited from gtk.</p>
    <p>Is this an issue mostly for people who write widgets intended for
      others to use in their applications? I suppose that people writing
      application programs wouldn't mind using boxes, grids and other
      container widgets.</p>
    <p><br>
    </p>
  </body>
</html>

--------------7fg2iUjQNmLEJSOuZDZ2PCiY--

--===============7514210952155278077==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list

--===============7514210952155278077==--