IRC channel logs
2024-09-26.log
back to list of logs
<solid_black>it's new C++ bindings for GObject-based libraries, an alternative to existing gtkmm and cppgir <solid_black>which of course lead to some drawbacks, but also make other things so much better <solid_black>even if you disagree with the design choices (which you houldn't :D), you could at least marvel at the code generator (peel-gen) <solid_black>it's way more capable than what I've seen in cppgir or Rust's gtk-rs <solid_black>granted, it's a huge fragile Python script full of hacks and special cases <solid_black>and it's got a testsuite (see tests/ in the source tree) that verify none of the tricky cases break when I make changes <solid_black>guess I should explain the broader context: GObject is the object/type system that: <solid_black> 1) adds OOP concepts (classes, interfaces, inheritance, etc) to C <solid_black>2) is dynamic, a lot like Objective-C or scripting languages, so you can for example look up a class by its name, make an instance of the class, set some properties on it, all without statically knowing which class it is <solid_black>3) is designed to be used from languages other than C too, or in other words: to enable making bindings to any GObject-based library with relative ease <solid_black>there is introsepction support, and dynamic languages like Python or JavaScript can just look up types and methods, and synthesize wrappers for them, on the fly <solid_black>whereas more static languages like C++ and Rust are intended to statically generate the binding code, based on the same introspection data <solid_black>since C++ is almost an extension of C, you can use GObject-based libraries from C++ by just doing the same things you'd do in plain C <solid_black>but people also want to use C++'s native class/method syntax, smart pointers, etc with GObject <solid_black>hence, bindings such as gtkmm, and cppgir, and now peel <kilobug>hi solid_black thanks, interesting project and comprehensive explanation but I can't stop from wondering how is that related to the Hurd ? any Hurd-specific usage in mind ? <solid_black>I just mentioned that I've been busy with it on the mailing list, and azert asked for more details, hence me dumping all this info here :) <azert>So what is the principal design difference with gtkmm and cppgir? <solid_black>the principal design difference I would say is exposing GObject concepts and leaning on GObject whenever GObject and C++ are "in conflict" <solid_black>gtkmm tries really hard to make things seem idiomatic C++ <solid_black>but then you want to do some actual GObject thing, and you learn that gtkmm's tricks are just incompatible with that, and you just cannot do that at all <solid_black>also: peel really ephasizes "zero-cost"-ness, i.e. no (or very minimal) runtime overhead, compared to equivalent plain C code <solid_black>there are no helper/wrapper objects that don't get fully optimized out for example <solid_black>all of the design has been guided by this contraint, every new feature I introduced I had to check with godbolt what code it actually compiles down to, to ensure it's no worse than C <solid_black>none of {gtkmm, cppgir, gtk-rs} achieve this, they all have runtime overhead, sometimes non-trivial <solid_black>also unlike cppgir, the generator is much more capable, but I already mentioned that <solid_black>peel is header-only (cppgir is too, I believe), which is normally a bad thing I would say, because I'd rather people distributed their pieces of logic as proper shared libraries <solid_black>whereas header-only libraries is basically vendoring things into every propject (and worse, every source file) separately, which is gross <solid_black>but exactly because peel compiles down to nothing, there is no libpeel.so, so header-only is appropriate <azert>I think that was the original c++ philosophy. Also templates that generate code on the fly <solid_black>and the generator is intentionally written in Python with no expternals deps other than Python's stdlib -- that's so it's easy to run on basically any platform, including windows <solid_black>Python is ok to require, since Meson is used to build the gtk stack <solid_black>compare that to horrors of building gtkmm on windows <solid_black>but yes, one downside of going the GObject way whenever GObject and C++ can't be integrated nicely is you cannot have C++ virtual functions in your GObject subclasses for example, since that would require a C++ vtable, and GObject already has its own vtable-like thing (class pointer) there <solid_black>you cannot have C++ constructors, you have to use GObject-style initialization for GObject subclasses (which is in a way only fair) <azert>But can you use standard c gobject on your Peel objects? <azert>Are them pointer compatible? <solid_black>it's all completely intrcompatible, yes, so you can cast a peel::Gtk::Button to a C GtkButton and call any C method on it, or the other way around <solid_black>I even have an example of how one would get both gtkmm and peel to interoperate inside the same codebase <solid_black>I also have an example of how one would expose a type implemented in C++ w/ peel to plain C <solid_black>(and by the way, while peel is primarily targeted towards GTK, it should work for any GObject-based library, I have examples of how to use libdex or libsoup for example) <solid_black>whereas both gtkmm and cppgir require C++17 I believe <azert>Im an user, PyGTK works great when performances is not a concern <solid_black>but if you have C++20, I have optional integration with ++20 coroutines <azert>But I dislike python for anything that is not simple scripting or numerica <azert>It’s a substitute for matlab <solid_black>with the caveat that C++20 coroutines are themselves not zero-cost (not my fault, C++ committe's) <azert>For instance, it’s still a single threaded language <azert>It’s not a serious programming language, even for the web <solid_black>but it is a good language for gluing together components written in a lower-level language (C) by others <solid_black>they have recently -- finally -- implemented support for non-GObject-derived types (types in the GObject type system that are not derived from the GObject class), such as Gtk.Expression <solid_black>and I believe integration of the glib main loop with python's own asyncio <solid_black>so yes, if you don't have a preexisting C++ codebase nor strict performance requirements, Python is fine <solid_black>there's also Vala, which is obscure, but very GObject-native <solid_black>I have some gripes with it (it doesn't let you write propper setters w/ notify, it doesn't let you write initializers, only constructors, and having a constructor actually disables a fast path in gobject.c, it doesn't properly integrate properties in D-Bus interfaces, ...) <kilobug>I don't agree about Python for the Web, it's a great language for the Web, many Web tasks are IO-bound (like waiting for a database or an external API to answer) and Web applications are very easy to run in multi-processus mode, so the GIL isn't that a big deal for the Web <Arsen>solid_black: vala is dead also, and I am always quick to urge against using domain specific languages <solid_black>it's not exactly dead, but it's not under active develoepment either, that's true <solid_black>otoh, how many features did say C gain in the last 10 years? :D <Arsen>ISTR its C code generator fails to build code GCC 14 can parse <Arsen>and doesn't matter, C implementations have many maintainers <Arsen>I'm not talking about features but bitrot <Arsen>(and also C isn't exactly a standard of excellence) <solid_black>you wouldn't pick it for some general project that doesn't use gtk/gobject <solid_black>but if writing an app using the gtk/gnome platform, it is very nice <solid_black>kind of like Swift I guess, although of course Swift has a lot more momentum behind it <azert>kilobug: check out Go for the web <jab>sneek: later tell solid_black You are working on a C++ bindings to gtk right? Have you ever tried using racket to make GTK apps? In my opinion, racket is the best way to build GTK apps. I would know. I've never built one!