Kjell Ahlstedt <kjellahlst...@gmail.com> ezt írta (időpont: 2022. aug. 1., H, 11:05):
> Den 2022-07-31 kl. 00:37, skrev Baldvin Kovacs: > > I took a stab at it, PTAL. Another option is to not do this, but document > in both the howtos, and the documentation > of Gtk::Widget that container-like custom widgets are not supported. > > Thx, > Baldvin > > > I have updated the custom container example in the gtkmm tutorial, > https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/master/examples/book/custom/custom_container. > Now it's more like a simplified vertical Box. It works well, except if it's > a managed widget. I've noted this restriction in a comment in the source > code. If you think it's too complicated the explain how to use a > signal_destroy(), we can leave it at that for the moment. > Hello, I took a look at your CL, and indeed it is making it clearer. However, it wouldn't have helped me to avoid spending the few days on this question, and here's why: When I was trying to learn how to use gtkmm, I was primarily interested in learning how to write clean, idiomatic code, preparing on a long journey. One of the questions in my mind were: shall I prefer inheritance, or composition? When I was a kid, it was all about inheritance, but basically every language (e.g. Go) that appeared in the last decade strongly prefers composition. And then I find that Gtk was recently refactored in a "prefer composition over inheritance" manner. Therefore, just reading the comment in the example "this cannot be used as managed" wouldn't have stopped me trying to figure out --- maybe it's just the example that tries to be too simple? And I would have engaged in the exact same deep dive, learning all the deep details of the Gtk destroy sequence over a few days. Just because when I'm in "let's learn the new thing" mode, then I need to get the answers to these fundamental questions. I think that I would have stopped and accepted to use the inheritance pattern only if: 1. https://developer-old.gnome.org/gtkmm-tutorial/stable/chapter-customwidgets.html.en says it explicitly, that gtkmm does not allow a composition pattern in managed mode, and that's why there's no such example 2. the comment in the example says what you say there now, extended with something along the lines of: "and it's not possible, don't even try". I think the comment for the destroy signal is not bad ( https://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/71/diffs). It is something that gives people hints and points them to the right direction. I'm not super happy with it though. Trusting users to unparent from both places without the framework enforcing or at least verifying it is problematic. However, arguably, the current mechanism is problematic, because it says nowhere that managed mode doesn't work in all cases, and the only way to learn about this is from the _extremely_ cryptic error message that have sent me to the bushes. ¯\_(ツ)_/¯ Please read the phrasing I have at https://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/71/diffs , and make a decision. I'm happy with both ways. Baldvin > Kjell >
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
