▲ 125 points
back
34 comments
I'm guessing this is small because it relies on GObject Inspection.
This is a Gnome feature whereby C libraries are accompanied by an XML description of functions and types. The XML description annotates semantics, not only syntax. Like if a function has a pointer parameter, does it have to be malloced, and does the caller free it or the callee? This information is not possible to determine from parsing C header files.
If you can parse the GObject XML, you can then generate FFI bindings (which can be done in Lisp easily without any textual code generation hacks).
Before people get too up-in-arms about that being XML, that is just the first step in the GObject Introspection compilation.
The second step builds a .typelib file which is a mmap()'able data-structure used at runtime by dynamic languages. It's smaller as it doesn't contain things like function/class documentation.
Additionally, the language bindings tend to use the GIRepository base structure which handles loading those mmap()'able data structures with an C API on-top of it.
Before people get too up in arms about a C API accessing some binary blobs, rest assured there is XML you could process instead.
Well, actually not everything possible via CFFI is possible via GIR. I've run into some issues before. I cannot recall what exactly, but it was a showstopper for me :-(.
Crosscompatiblity? IIRC the same concept was used for some exo-lisp gtk bindings, IIRC fennel, and I couldn't get it work for the life of it under M1 macs....
Also see: https://lispcookbook.github.io/cl-cookbook/gui.html
These may be of special interest:
A lightweight QML-only ECL binding to Qt5/Qt6 : https://gitlab.com/eql/lqml
CLOG - The Common Lisp Omnificent GUI : https://github.com/rabbibotton/clog
+1 for CLOG
It's not good D.R.Y. to reinvent a binding library for each and every application language. What's needed is a state-ful GUI markup standard. Then any language that can emit and read XML can use the GUI kit/browser/component, no binders needed.
What you're describing is GObject inspection. It's literally a series of XML documents that can be used to autogenerate ffi bindings in any language. The future is now.
...which is literally what these Lisp bindings use.
No one will want to write GUI code that directly parses and generates XML, so every language will end up putting wrappers around that, and you are back to where you started with an expensive translation layer in-between.
Having a machine format that describes the interface and facilitates auto-generating the bindings, like GObject introspection is a better option and exists today. Even then the auto-generator will need to be custom for each language, to handle integration with the language's standard library data structures, memory management and the like.
> XML User Interface Language is a user interface markup language developed by Mozilla. XUL is an XML dialect for writing graphical user interfaces, enabling developers to write user interface elements in a manner similar to web pages.
That way, your language can use any toolkit, such as WebKit or Gecko.
If you did that, you limit what the API of a framework can do, you either can't use ones that fall outside that spec, or you have to jump through hacky hoops to get it working.
Experienced engineers know D.R.Y. has it's uses, but isn't a good hill to die on.
What's the advantage? This merely seems to add another layer of abstraction.
I'm not sure DRY applies across language boundaries. If a binding exists in one language, creating a binding in another isn't really repeating anything.
Does GTK4 finally implement its own C coded unicode text shaper (or at least, a roman script text shaper)? No I don't want that horrible c++ diareha which is harfbuzz.
Harfbuzz exposes a C API, why would you need to use C++?
Additionally, it works extremely well with GTK 4 via Pango and you can often interoperate between the two layers if you even need to touch a hb_face_t/etc. In fact, the only time I had to mess with Harfbuzz was when integrating GPU-rendered glyphs via Behdad's GLyphy shaders.
It has a C API, but it is written using c++. A long time ago, I did a build of GTK3, to remove the c++ dependency, I did an implemention of this C API in C, only for roman scripts though. I bet this C API was "obsolescence planned" and if I ever need GTK again (unlikely), I will code again a C implementation for roman scripts.
There is an alternative from IBM, ICU, it was properly coded in C, but it was switched to toxic c++.
Sounds like C++ has hurt you quite a bit.
I mean, I don't use it, and I've been writing C for a solid 25 years, but Behdad is one of the best engineers I've ever met in my life. So I definitely don't share your opinion of the code or the quality.
c++ is toxic for humanity because of its grotestquely and absurdely complex and massive syntax and its compilers. This is not a matter of opinion, this is an absolute unquestionable truth.
Carefull, I am not saying plain and simple C is better: it is only orders of magnitude less worse as there is already way too much in its syntax. Some would call that, the "most reasonable compromise".
So you also only use C compilers written in C, so no clang nor GCC for you I guess.
Indeed, I am currently trying to remove as much as I can gcc and llvm from my stack (I am now targetting much more, probably too much). llvm is financed by apple (vanguard/blackrock), and gcc by the MIT/redhat(IBM). I wish I had that much money to hire ppl in order to remove that toxic c++.
There was article here the other day on a project by herb stutter to improve c++ syntax, I can link it to you if you want.
But I get the impression that the syntax is a fixable problem. Usually critics point so something like the template system or something.
Cool story.
The beyond sanity complexity of c++ is not a story unfortunately. The real sad story is that some ppl think they are smart because they code c++.
What's wrong with Harfbuzz?
What is the problem with harfbuzz? we use it extensively in LibreOffice, works great!
I love that LibreOffice lets me use the full range of OpenType features in fonts. Do I have Harfbuzz to thank for that?
But please let me edit the sample text in the OpenType features modal, so I can actually see the effects of my changes without leaving the entire Font window :)
Perhaps GTK 4.8 is the GTK for you.
https://blog.gtk.org/2022/09/19/inside-the-gtk-font-chooser/
Based on the font chooser, absolutely. Thanks for this link.
...but did they fix the file picker yet?
Without Harfbuzz, I doubt it would have been as easy to implement.