Re: Unparenting from GtkWidget "destroy"

--===============3588653900576174870==
Content-Type: multipart/alternative; boundary="00000000000032daa905e371be87"

--00000000000032daa905e371be87
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Kjell Ahlstedt <[email protected]> ezt =C3=ADrta (id=C5=91pont: 2022.=
 j=C3=BAl. 10.,
V, 13:06):

> 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. A=
nd
> 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.
>
I'll prep a merge request.

> 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.
>
Correct --- once I've understood this, I moved on by inheriting Box. I
started this thread only to figure out how to help others who run into the
same question.

I'll send a merge request with exposing signal_destroy, and another small
one to the documentation, to the custom widget section.

Baldvin

--00000000000032daa905e371be87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Kjell Ahlstedt &lt;<a href=3D"mailto:=
[email protected]">[email protected]</a>&gt; ezt =C3=ADrta (id=
=C5=91pont: 2022. j=C3=BAl. 10., V, 13:06):<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <div>Den 2022-07-09 kl. 18:50, skrev Andrew
      Potter via gtkmm-list:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div class=3D"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&#39;t b=
e
    done.<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"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&#39;d have to
            settle for subclassing a container, but otherwise I&#39;d prefe=
r
            all signals to be available.<br>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    <p>No, I don&#39;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&#39;s not explicitly ignored, probably because no one has
      been sure it&#39;s useless. And now it seems it is useful, even
      necessary, to some users.</p>
    <p>I don&#39;t mind adding Gtk::Widget::signal_destroy() to gtkmm4. I&#=
39;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></div></blockquote><div>I&#39;ll prep a mer=
ge request.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <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&#39;t mind using boxes, grids and other
      container widgets.</p></div></blockquote><div>Correct --- once I&#39;=
ve understood this, I moved on by inheriting Box. I started this thread onl=
y to figure out how to help others who run into the same question.</div><di=
v><br></div><div>I&#39;ll send a merge request with exposing signal_destroy=
, and another small one to the documentation, to the custom widget section.=
</div><div><br></div><div>Baldvin</div><div><br></div><div><br></div><div>=
=C2=A0</div></div></div>

--00000000000032daa905e371be87--

--===============3588653900576174870==
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

--===============3588653900576174870==--