11 ms·
GTK4 Bindings for Common Lisp
- sylware 4y agoDoes 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.
- chris_wot 4y agoWhat is the problem with harfbuzz? we use it extensively in LibreOffice, works great!
- nerdponx 4y agoI 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 :)
- chris_wot 4y agoWithout Harfbuzz, I doubt it would have been as easy to implement.
- audidude 4y agoPerhaps GTK 4.8 is the GTK for you. https://blog.gtk.org/2022/09/19/inside-the-gtk-font-chooser/ https://blog.gtk.org/2022/09/19/inside-the-gtk-font-chooser/
- nerdponx 4y agoBased on the font chooser, absolutely. Thanks for this link. ...but did they fix the file picker yet?
- colejohnson66 4y agoWhat's wrong with Harfbuzz?
- audidude 4y agoHarfbuzz 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.
- sylware 4y agoIt 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++.
- audidude 4y agoSounds 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.
- sylware 4y agoc++ 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".
- audidude 4y agoCool story.
- 4y ago
- deleted 4y ago[deleted]
- ducktective 4y agoAlso see: https://lispcookbook.github.io/cl-cookbook/gui.html 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 https://gitlab.com/eql/lqml CLOG - The Common Lisp Omnificent GUI : https://github.com/rabbibotton/clog https://github.com/rabbibotton/clog
- kaeland 4y ago+1 for CLOG
- kazinator 4y agoI'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).
- audidude 4y agoBefore 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.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- kazinator 4y agoBefore people get too up in arms about a C API accessing some binary blobs, rest assured there is XML you could process instead.
- jmercouris 4y agoWell, 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 :-(.
- paines 4y ago
- tabtab 4y agoIt'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.
- 13415 4y agoWhat's the advantage? This merely seems to add another layer of abstraction.
- JasonFruit 4y agoThat way, your language can use any toolkit, such as WebKit or Gecko.
- Spivak 4y agoWhat 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.
- nerdponx 4y ago...which is literally what these Lisp bindings use.
- spicybright 4y agoIf 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.
- pavon 4y agoNo 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.
- mikessoft_gmail 4y ago