61–70 of 225 posts
The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.
The simplest examples have over a thousand (literally) dependencies. Amongst them, are GTK, GDK, pango, etc. It literally depends on another toolkit, which is the weirdest thing IMHO.
I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.
Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them. This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like…
> lose styling consistency Yes. And that is (almost always¹) a good thing. Only the designers of an app, product-owners etc. want their app to "look consistent over platforms". Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native. ¹ Obviously some software excepted. E.g. categories like "e…
Videogames.
Excel still supports MS-DOS Lotus 1-2-3 "/" commands, although it certainly doesn't look like Lotus for MS-DOS.
Basically any software people care about is an exception to your rule.
Rust certainly needs more GUI component collections. There are lots of GUI toolkits, but a comparatively small number of prebuilt components you can use with any of them. This collection looks quite useful, though the component list is mostly indistinguishable from a list of components for a web framework. The webview component is the only one that seems somewhat specific to native applications. So for something like…
> lose styling consistency Yes. And that is (almost always¹) a good thing. Only the designers of an app, product-owners etc. want their app to "look consistent over platforms". Your users want the file-dialog, window-chrome, menus etc consistent too. But for them consistent means consistent with the 20+ other applications they use on a daily base. So native. ¹ Obviously some software excepted. E.g. categories like "e…
I don't think what you posit is true at all, at least not in 2025. Windows itself has abandoned consistency between its native applications, with more custom and modern styling that looks nothing like what you get out of the box with Windows UI frameworks. Almost every piece of software currently running on my computer has custom chrome: the web browser, my VPN, VSCode, Discord, Steam, mouse driver, keyboard driver, laptop fan driver. The only one that doesn't is qbittorent, and it looks like a complete eyesore. It is quite literally the odd one out, so much for "consistent with 20+ other applications".
Maybe it's different in MacOS land, but from my perspective you're 20 years behind if your application is trying to blend in with the OS in any regard other than the corner in which the X button is located. That way of thinking went out of fashion decades ago, and good riddance to it because things look much better now. What I mentioned above is a pretty good representative sample of my daily use, and the more I think about other software I occasionally use, the more I am grateful that nobody else still thinks like this. LiveSplit and Asesprite come to mind as two applications that strongly benefit from having bespoke chrome and wouldn't be nearly as nice to use if they looked anything like a native Windows application. Of course, my own software uses custom chrome as well, because looking nice makes it more pleasant to use, wouldn't you know it.
Earlier quoted context omitted.
That did seem excessive to me as well. I do worry about the DX of trying to work on an app with this. After each edit, I would expect a solid compile time to simply try your work.
I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem. The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds. [0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/s…
(dioxus-7-rc.3)
It usually only works when reordering elements, or changing static values (styles, attributes, etc).
Which, to be fair, does speed things up a lot when tinkering with small details.
But 70%+ or so of my changes still result in recompiles.
Earlier quoted context omitted.
I think this is pretty common on Linux. You would want to GTK (or Qt) I would think to draw the top level window and perhaps system menus, etc. even though the UI itself is drawn using a GPU canvas.
Are GTK/Qt memory safe now?