[HN Gopher] GTK4 Bindings for Common Lisp
___________________________________________________________________
GTK4 Bindings for Common Lisp
Author : oumua_don17
Score : 90 points
Date : 2022-09-20 15:42 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kazinator wrote:
| 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).
| audidude wrote:
| 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.
| [deleted]
| [deleted]
| tabtab wrote:
| 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.
| JasonFruit wrote:
| That way, your language can use any toolkit, such as WebKit or
| Gecko.
| spicybright wrote:
| 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.
| 13415 wrote:
| What's the advantage? This merely seems to add another layer of
| abstraction.
| Spivak wrote:
| 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.
| pavon wrote:
| 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.
| sylware wrote:
| 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.
| chris_wot wrote:
| What is the problem with harfbuzz? we use it extensively in
| LibreOffice, works great!
| nerdponx wrote:
| 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 :)
| audidude wrote:
| Perhaps GTK 4.8 is the GTK for you.
|
| https://blog.gtk.org/2022/09/19/inside-the-gtk-font-
| chooser/
| nerdponx wrote:
| Based on the font chooser, absolutely. Thanks for this
| link.
|
| ...but did they fix the file picker yet?
| colejohnson66 wrote:
| What's wrong with Harfbuzz?
| audidude wrote:
| 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.
| sylware wrote:
| 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++.
| audidude wrote:
| 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.
| sylware wrote:
| 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".
| audidude wrote:
| Cool story.
| sylware wrote:
| 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++.
| ducktective wrote:
| 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
| mikessoft_gmail wrote:
| [deleted]
___________________________________________________________________
(page generated 2022-09-20 23:01 UTC)