Kjell Ahlstedt <kjellahlst...@gmail.com> ezt írta (időpont: 2022. júl. 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. 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. > 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
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
