Alternative UI toolkits
168 views
Skip to first unread message
Stephen De Gabrielle
Aug 3, 2019, 7:42:55 AM8/3/19
to Racket Users
Hi
Has anyone done any work on using racket with other UI toolkits?
I don’t think so but I thought it was worth asking - just in case.
Stephen
-- ----
Martin DeMello
Aug 4, 2019, 10:50:40 PM8/4/19
to Stephen De Gabrielle, Racket Users
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-LvuH3rjm1x7O-iwR33CfW3xuV0Yz2S7SX_eTu%2Bjr%2Ba3g%40mail.gmail.com.
Roman Klochkov
Aug 5, 2019, 5:39:45 AM8/5/19
to Racket Users
https://github.com/Kalimehtar/gir
суббота, 3 августа 2019 г., 16:42:55 UTC+5 пользователь Stephen De Gabrielle написал:
суббота, 3 августа 2019 г., 16:42:55 UTC+5 пользователь Stephen De Gabrielle написал:
Neil Van Dyke
Aug 5, 2019, 6:14:12 AM8/5/19
to Racket Users
Thank you, Roman.
For those who don't know, `gir` potentially lets people use many of the
libraries behind the Gnome GUI desktop environment that's popular on
GNU/Linux and other places. It does FFI to the GObject object system
that backs those libraries, and perhaps also uses the metadata now
provided to making bindings easier.
The Racket cross-platform GUI API, such as is used in the implementation
of DrRacket, already uses a subset of some of these libraries (from both
GTK version 3 and 2 sets) on many platforms, *but* GObject bindings let
you do a lot more than the cross-platform toolkit, on platforms that
support it (though unfortunately you then run only on those platforms).
For related GObject/Gnome/GTK/etc. bindings work, the most active might
be Guile (the GNU project's own Scheme dialect, which has some nice new
work, if you haven't looked at it in a while), which has had a number of
such attempts at GTK/etc. bindings, and a there's new work on
GObject-based bindings: https://github.com/spk121/guile-gi
The other really popular GUI desktop toolkit family (other than
HTML&CSS-based GUIs) is Qt. This has always been the main competitor to
GTK/Gnome, is even moreso now than it used to be, and is something I
considered adding as a new backend for Racket's cross-platform toolkit,
especially for handhelds. Other than Qt, you might want to build a more
lightweight toolkit, atop OpenGL ES and/or Vulkan, and make it friendly
for handhelds, desktop/laptop, and HUD/HR (and preferably also hooked
into Racket's cross-platform GUI API, but you might want to also provide
a non-cross-platform API to it).
For those who don't know, `gir` potentially lets people use many of the
libraries behind the Gnome GUI desktop environment that's popular on
GNU/Linux and other places. It does FFI to the GObject object system
that backs those libraries, and perhaps also uses the metadata now
provided to making bindings easier.
The Racket cross-platform GUI API, such as is used in the implementation
of DrRacket, already uses a subset of some of these libraries (from both
GTK version 3 and 2 sets) on many platforms, *but* GObject bindings let
you do a lot more than the cross-platform toolkit, on platforms that
support it (though unfortunately you then run only on those platforms).
For related GObject/Gnome/GTK/etc. bindings work, the most active might
be Guile (the GNU project's own Scheme dialect, which has some nice new
work, if you haven't looked at it in a while), which has had a number of
such attempts at GTK/etc. bindings, and a there's new work on
GObject-based bindings: https://github.com/spk121/guile-gi
The other really popular GUI desktop toolkit family (other than
HTML&CSS-based GUIs) is Qt. This has always been the main competitor to
GTK/Gnome, is even moreso now than it used to be, and is something I
considered adding as a new backend for Racket's cross-platform toolkit,
especially for handhelds. Other than Qt, you might want to build a more
lightweight toolkit, atop OpenGL ES and/or Vulkan, and make it friendly
for handhelds, desktop/laptop, and HUD/HR (and preferably also hooked
into Racket's cross-platform GUI API, but you might want to also provide
a non-cross-platform API to it).
Neil Van Dyke
Aug 5, 2019, 6:16:33 AM8/5/19
to Racket Users
Sorry, typo: I meant "HUD/AR" as in "head-up display and augmented
reality" (and also VR).
reality" (and also VR).
Stephen De Gabrielle
Aug 5, 2019, 12:35:52 PM8/5/19
to Neil Van Dyke, Racket Users
I was wondering about XUL and Chromium but I don’t know if they count as UI toolkits
S.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/a9eb0d1a-4ef1-8d24-abce-ac73268bde4b%40neilvandyke.org.
----
Neil Van Dyke
Aug 5, 2019, 1:07:34 PM8/5/19
to Racket Users
XUL itself is deprecated/dead. There might be an interesting (but
niche) Racket opportunity with WebExtensions, and you might want to wait
to see how they decide WASM fits into that, and what Racket's WASM story
becomes.
Also, bit of gut-feel speculation... There's some odd noises/rumblings
going on with browser extensions (and PR of same) in recent months, and
a few I noticed in the last week. Anyone contemplating a new project
based on browser extensions should consider that the rules might be
changing soon, more likely than in the past. (Beyond Chrome
anti-ad-blocking moves, which also was a gift to Mozilla when they
needed it. But possibly other restrictions, such as in what else
extensions can do, and on who can effectively publish what extensions.
And maybe an improved or new monetization option.)
niche) Racket opportunity with WebExtensions, and you might want to wait
to see how they decide WASM fits into that, and what Racket's WASM story
becomes.
Also, bit of gut-feel speculation... There's some odd noises/rumblings
going on with browser extensions (and PR of same) in recent months, and
a few I noticed in the last week. Anyone contemplating a new project
based on browser extensions should consider that the rules might be
changing soon, more likely than in the past. (Beyond Chrome
anti-ad-blocking moves, which also was a gift to Mozilla when they
needed it. But possibly other restrictions, such as in what else
extensions can do, and on who can effectively publish what extensions.
And maybe an improved or new monetization option.)
Stephen De Gabrielle
Aug 5, 2019, 5:06:06 PM8/5/19
to Racket Users
Sorry, I meant whatever is used to make Visual Studio Code, and whatever the Mozilla equivalent is.
s.
Aidan Gauland
Aug 6, 2019, 11:26:54 AM8/6/19
to racket...@googlegroups.com
That would be Electron <https://electronjs.org/>, for which
I think Racket would be a really awkward fit, but if
anyone has a crack at it, I'd be very interested to see the
result.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c22cff90-2db7-401d-8965-4f093921222d%40googlegroups.com.
Neil Van Dyke
Aug 7, 2019, 11:36:36 AM8/7/19
to Racket Users
Since I mentioned the Qt GUI toolkit family (which you might also know
as a foundation of KDE)...
* if anyone is looking at that for Racket for some reason, there's a new
"technical vision" statement for the next major version:
https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/
I'm happy with Racket's current support for GTK2, GTK3, and other native
toolkit backends, and so see no need for all the work to add a Qt
backend, but it's nice to have backup plans in mind for unusual situations.
* Also, even if you have no interest in Qt right now, that blog post is
a nice writeup on ongoing vision for an important set of software that's
been evolving for a long time and is pretty popular. So maybe worth a
skim, for a feel of how they're thinking and communicating about that
kind of thing.
as a foundation of KDE)...
* if anyone is looking at that for Racket for some reason, there's a new
"technical vision" statement for the next major version:
https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/
I'm happy with Racket's current support for GTK2, GTK3, and other native
toolkit backends, and so see no need for all the work to add a Qt
backend, but it's nice to have backup plans in mind for unusual situations.
* Also, even if you have no interest in Qt right now, that blog post is
a nice writeup on ongoing vision for an important set of software that's
been evolving for a long time and is pretty popular. So maybe worth a
skim, for a feel of how they're thinking and communicating about that
kind of thing.
Stephen De Gabrielle
Aug 7, 2019, 5:10:26 PM8/7/19
to Neil Van Dyke, Racket Users
Thanks Neil. Mathematica uses QT! Noice.
For my own reference
- https://github.com/servo/webrender/ 'experimental render backend for Servo, but it can also be used as such in a standalone application.'
- https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#using-extern-functions-to-call-external-code - calling Rust functions from Racket and vice versa.
Racket<=>rust interoperability seems interesting.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/528a6a04-9fbc-a64b-4bda-b2fce4d533fe%40neilvandyke.org.
Neil Van Dyke
Aug 8, 2019, 7:29:08 AM8/8/19
to Racket Users
Stephen De Gabrielle wrote on 8/7/19 5:10 PM:
> Mathematica uses QT!
There's a lot in Qt, just like there's a lot in GTK. Occasionally, a
noteworthy project goes to a lot of trouble to switch from one to the
other (e.g., Wireshark).
Thankfully, Racket has meant I mostly don't have to pick GUI toolkits,
and that (in theory) I could migrate an entire desktop suite of
applications to a new toolkit backend, because Racket already has the
seasoned cross-platform layer over multiple native toolkits.
> https://github.com/servo/webrender/ 'experimental render backend for
> Servo, but it can also be used as such in a standalone application.'
Since you're looking at multiple Mozilla HTML-ish application/GUI
toolkits, you might also consider WebKit (which originated in the Qt/KDE
universe, and also spun off Safari and Chrome). These all bring their
own opportunities and burdens, but sometimes they're worthwhile.
> https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#using-extern-functions-to-call-external-code
> - calling Rust functions from Racket and vice versa.
That might work, and could be just the thing for some purposes, but (for
those on racket-users who don't already know) be judicious with FFI and
same-process. If you've never had the experience of debugging a crash
in which you don't know whether it's in any of the native libraries
(including unsafe Rust) you're pulling in, or a bug in Racket, or a
strange interaction of one or more GCs, or a bug in your FFI/extension
bindings, or a bug in how the Racket application code is using a
somewhat-fragile interface... that's a much better learning experience
to have with a hobby project, than in production.
In the past, I greatly improved both the stability and performance of a
large Racket production system by rewriting some C parts in pure Racket
(this can be faster), and isolating other C parts into separate Linux
processes.
That said, sometimes you should just do FFI. As an exercise, I made a
character terminal library without FFI, and in hindsight, probably
should've just done a little bit of FFI:
https://www.neilvandyke.org/racket/charterm/
> Mathematica uses QT!
There's a lot in Qt, just like there's a lot in GTK. Occasionally, a
noteworthy project goes to a lot of trouble to switch from one to the
other (e.g., Wireshark).
Thankfully, Racket has meant I mostly don't have to pick GUI toolkits,
and that (in theory) I could migrate an entire desktop suite of
applications to a new toolkit backend, because Racket already has the
seasoned cross-platform layer over multiple native toolkits.
> https://github.com/servo/webrender/ 'experimental render backend for
> Servo, but it can also be used as such in a standalone application.'
toolkits, you might also consider WebKit (which originated in the Qt/KDE
universe, and also spun off Safari and Chrome). These all bring their
own opportunities and burdens, but sometimes they're worthwhile.
> https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#using-extern-functions-to-call-external-code
> - calling Rust functions from Racket and vice versa.
those on racket-users who don't already know) be judicious with FFI and
same-process. If you've never had the experience of debugging a crash
in which you don't know whether it's in any of the native libraries
(including unsafe Rust) you're pulling in, or a bug in Racket, or a
strange interaction of one or more GCs, or a bug in your FFI/extension
bindings, or a bug in how the Racket application code is using a
somewhat-fragile interface... that's a much better learning experience
to have with a hobby project, than in production.
In the past, I greatly improved both the stability and performance of a
large Racket production system by rewriting some C parts in pure Racket
(this can be faster), and isolating other C parts into separate Linux
processes.
That said, sometimes you should just do FFI. As an exercise, I made a
character terminal library without FFI, and in hindsight, probably
should've just done a little bit of FFI:
https://www.neilvandyke.org/racket/charterm/
Reply all
Reply to author
Forward
0 new messages