@akaster so my impression of vcpkg was that it's a mess that's best avoided... but as for librsvg, the news is https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9333

Generally it would make sense to expect contributors to an application to be fluent in the framework the application is written in (be it GTK with peel, AppKit, Win32, Android, whatever); in other words to have experience writing proper idiomatic applications using that framework. And they would have to have learned that from some resources external to the project indeed.

But yeah, I can see your point & why peel could be problematic for that use case of yours. If you decide that gtkmm (or plain C, or whatever) fits better, I could help you with that too.

@akaster hey, so, the overall reason is that GObject construction and C++ construction work differently enough that it's not worth to try and make them work in tandem. I have thought about this a lot, because it would be really nice if it just worked (like it does with destruction), but ultimately decided that's not worth it. That is true of many many "core" aspects of peel (like this one): the design has been thought over excessively, even though you might not immediately like the result.

If you want some more details: consider that the C++ constructor expects to initialize all the memory the instance occupies, including that of the parent class subobject, whereas in reality the parent class data will be initialized by the actual parent type's initializer, and C++ has to keep its hands off that memory. Also that GTypeInstance initialization happens in turns, from the root type (GObject) down to the concrete type, and at each turn the object's dynamic type is set to that type being initialized — so e.g. if a vfunc gets called at this point, it'd be that class'es vfunc implementation (C++ also does a similar thing with its virtual classes); and GTK makes serious use of this (Gtk.Widget.init_template() works with the current type of the object) — you can't really make this work if the initialization is driven from the C++ side.

We also cannot require that the class is trivially constructible, exactly because it might not be, you may want to do some initialization. Using e.g. a RefPtr (which defaults to nullptr, and doesn't have to be explicitly initialized in fields of GObject) would instantly kill trivial constructibility too; but this is something we want to encourage, and so make simple, not prohibitively complicated. Also we delete the default constructor for classes, so people don't accidentally try to stack allocate them; trivial constructibility requirement wouldn't work with that either.

In my experience using peel, it ends up not actually being much trouble, especially if you mostly use peel's own types which come with a promise that zero-initialization is fine. For the occasional STL type, yes, you have to call the constructor explicitly. This became even more true once I stopped using std::string in favor of peel::String; now it's mostly vectors that remain.

So are/were you considering peel for some project? What are you trying to do?

@akaster hey. So back when I was building a gtkmm project with CMake, I used something much simpler, just looking up gtkmm through pkg_check_modules and linking to the imported target. But, I wasn't trying to do all of this "build a version from source if not new enough". Which I understand the appeal of, and it's nice when Meson does that for subprojects, without you having to write tons of logic on your side to get it.

But also, I no longer have to use gtkmm  peel is now public, and it comes with some CMake integration (which I've even written the docs for: https://bugaevc.pages.gitlab.gnome.org/peel/using-peel-with-cmake.html). Which is imperfect by the way, and improvements welcome.

@ralen @YaLTeR the one on the right is Microsoft Surface Pro 6. It's a 2-in-1 tablet/laptop indeed. It runs Linux (Fedora Linux + GNOME, in my case) beautifully thanks to https://github.com/linux-surface/linux-surface

(Also your instance appears to be blocked from my other account?)

@akaster ...oh I think I understand what you mean. You mean the user being able to "tear off" the tab and have *the whole tab content (the webview) move into its own window* while being dragged, like Chrome used to do. I don't know much about the client/toolkit side of this, but as far as Wayland protocols go you're going to need xdg-toplevel-drag, see this blog post https://blog.david-redondo.de/kde/wayland/qt/2023/08/08/xdg-toplevel-drag.html
The Qt pull request is here https://codereview.qt-project.org/c/qt/qtwayland/+/470673, see if you can make sense of it & figure out how to use it as an app/widget developer.

macOS, I don't know if there's a non-hacky way to do this (the hacky way would be creating a new NSWindow at just the right coordinates once you detect your tab is being torn off, and messing with events to keep the newly created window dragged), but I wouldn't advise you to do that either: let the system widgetry do its thing.

GTK/libadwaita, too, that's a feature that AdwTabView/AdwTabBar should implement (or not), not an individual app. You might want to talk to Alice M. about hooking up xdg-toplevel-drag to AdwTabBar.

@akaster wait what, /dev/null doesn't support fsysopts? I didn't expect that to be the case 😅

Anyway, my point was, you can look at how the system is set up this way; "mounts" and "device nodes" are really just translators, you can find them in `ps` output, and you can set up your own ones (even without being root). mount(1) tries to present a Unix mount-like CLI and output on top of the native Hurd-ish concepts.