racket
Better GTK support
racket/gui has no support for builtin gtk icons (out of the box), and most widgets (such as text-field%) don't need to be using a canvas under the hood (though, this canvas is capable of exposure, and thus backwards incompatible - Perhaps it could fall back to canvas when a canvas is requested?).
This is more of a racket/gui issue than a rhombus issue since I'm sure there's a backward-compatible way to achieve this. Could someone with appropriate permissions transfer this issue to the racket/gui repo?
I understand the next step would be GTK4 support?
GTK4 support would be nice (and I hope to get around to adding it eventually, if no one beats me to it), but it isn't directly related to these feature requests.
racket/gui has no support for builtin gtk icons (out of the box)
Functionality from racket/gui is supposed to be supportable across platforms, and I don't know offhand of an equivalent to GTK icons in the native APIs for Windows or Mac OS. That suggests this feature probably isn't a good fit for racket/gui.
If there is a cross-platform core to this feature, here's something I wrote about the path to adding new functionality to racket/gui, starting with one platform and building from there:
That said, there is also room for incremental improvement. For a recent example, a way to react to switches into or out of dark mode was added in https://github.com/racket/gui/commit/9682a952eb5742a0065ec18195bef7f4db7b7e25, initially only on Mac OS. GTK support was added in https://github.com/racket/gui/commit/223e6099dac482762c5e00c797eadb453c9527a1 a week later, and, for Windows, https://github.com/racket/gui/issues/197 is still an open issue. If you can implement a feature for one platform, others may be able to fill in support for the rest. Of course, before you put in too much time on a patch, it may be worth checking with others that your approach sounds reasonable and doesn't pose any avoidable issues for other platforms.
If this is, in fact, platform specific functionality, it's reasonable to want to add it as a separate library that works on GTK only. To add platform-specific extensions to racket/draw you can use the get-client-handle method of window<%> to grab a GtkWidget pointer and drop down into GTK.
There is definitely room for improvement in making this sort of thing easy to do. In particular, I have thought it could be useful to make a public ffi/unsafe/glib library, analogous to ffi/unsafe/objc, to export the Glib FFI utilities from racket/draw/unsafe/glib, mred/private/wx/gtk/utils, and maybe a few other places that aren't specifically tied to drawing or GUI contexts. Being able to share the existing support would be especially nice since racket/draw/unsafe/glib sets up logging with Racket's private glib-log-message primitive. (At a glance, it looks like there aren't breaking changes in Glib associated with Gtk4, but it would probably be worth confirming that any new public functionality is not deprecated.)
most widgets (such as text-field%) don't need to be using a canvas under the hood (though, this canvas is capable of exposure, and thus backwards incompatible
Text-related widgets tend to work this way because, as you note, they expose Racket's cross-platform editor<%> framework for advanced uses.
However, it is reasonable to want access to the platform-native widgets. In this case, the functionality definitely does exist across platforms, so I think it would be reasonable to expose it by adding new widget classes to racket/gui.
A different direction for enhancement is making canvas<%> instances, including editor-canvas<%>es, not just opaque leaf nodes from the perspective of the platform APIs. I wrote some long thoughts about this in a Discourse thread: in brief, it would be nice to be able to nest widgets inside canvases, as identified in Lief's PhD thesis, and it is also very important (though a large and difficult project) to provide accessibility information to the OS for screenreaders and other assistive technologies, as discussed in https://github.com/racket/drracket/issues/219#issuecomment-1223556356.
I think that, unrelated to GTK icons and the other widgets mentioned in the original description, being able to use GTK4 would be great. It's unclear to me from the documentation what the best way to do this would be. I think that the GObject Introspection would be a promising start, and (of course) things could be done through FFI; I wonder if there are any examples GTK4 being used in Racket out there to be referenced
to be clear: the "GTK icons" in question are the same as what Qt uses, and both use them on all platforms - as both widget toolkits are already cross platform - but they themselves are part of the FreeDesktop specification, and FreeDesktop is only used by Linuxes, BSDs and smaller, not by macos and windows.
https://specifications.freedesktop.org/icon-theme/latest/
I think that, unrelated to GTK icons and the other widgets mentioned in the original description, being able to use GTK4 would be great. It's unclear to me from the documentation what the best way to do this would be.
To start, you would need to update the definitions of gdk-lib, gdk_pixbuf-lib, and gtk-lib to try loading GTK4:
https://github.com/racket/gui/blob/8ea1bf5dd5a61fe018e8ca36a617cf2b1baf5a15/gui-lib/mred/private/wx/gtk/utils.rkt#L64-L89
Some of the actual logic is implemented here:
https://github.com/racket/gui/blob/8ea1bf5dd5a61fe018e8ca36a617cf2b1baf5a15/gui-lib/mred/private/wx/gtk/gtk3.rkt#L8-L18
Then, you would need to update conditionals that check gtk3?, and probably add some new ones for API changes in GTK4: https://github.com/search?q=repo%3Aracket%2Fgui+gtk3%3F&type=code
to be clear: the "GTK icons" in question are the same as what Qt uses, and both use them on all platforms - as both widget toolkits are already cross platform - but they themselves are part of the FreeDesktop specification
This inspired me to refresh my memory, and it looks like there have been some interesting developments on the Qt side.
Until recently, the only icons with built-in cross-platform support from Qt were the relatively small number accessible via QStyle::standardIcon(). I found a visualization of them here: https://gist.github.com/centaurialpha/cfd7de48cb3e4d8e0d17f475b7ad3118
You could use QIcon::fromTheme() across platforms to access icons according to the XDG Icon Theme specification, but Windows and Mac OS (let alone Android and iOS) don't provide a system default icon theme. A portable application using QIcon::fromTheme() would need to ship its own icons for non-FreeDesktop platforms (probably by picking some existing free/libre theme, likely Breeze for Qt folks). IIUC, this is also the status quo for cross-platform GTK applications that use icons from a FreeDesktop icon theme.
But apparently, since Qt 6.7, QIcon::fromTheme() can also “access to the native icon library on macOS, iOS, and Windows 10 and 11” (and Android, with some caveats). This suggests that there probably is a cross-platform subset of functionality, after all, which would more or less correspond to the members of the QIcon::ThemeIcon enum. And the Qt folks have presumably done the work of correlating the different platforms' ways of referring to the corresponding icons!
Still, I think it would be worth giving careful thought to the scope and purpose of any racket/gui API for this. As you may know, there is debate even within different parts of the free desktop community about the usefulness and desirability of the XDG Icon Theme specification. (The fact that I am writing this on my KDE-running laptop reflects my personal leanings toward the pro-theming side, but the anti-theming people do have some points worth considering about how much complexity to inject into applications.)
A cross-platorm core of the feature does seem to exist, though.