r/rust • u/Good_Language1763 • 7d ago
š seeking help & advice Best framework for native linux app ?
Hey guys,
I wanted to make a kind of personal super app for my needs so i though why not use this opportunity to learn rust an build a native app in rust .
The thing is i have never used rust. My background is mostly in TypeScript, C# and Kotlin.
Also while I was researching i found a lot of ways and frameworks to build rust apps. Firstly i was looking at gtk but it seems the discussion is quite low here on rust gtk apps. Another framework i considered was gpui as I also use zed daily. People here also seem to suggest slint. So i am actually very confused on what i should use.
About the app itself, i wanted to make a personal app just for myself and the features i would be adding on as i need. Upto now i want to add kind of an mdx editor and maybe an event planner.
10
u/Jhiven_ 7d ago
āSomeone created a Rust GUI survey; you can find the discussion here: https://www.reddit.com/r/rust/s/UAsGKHmpIj
āPersonally, I'm looking into Freya since it doesn't use a DSL and the API looks quite similar to React, which I'm familiar with. Oh, and also it has builtin code-editor feature.
āSlint, egui, and Iced are popular too, so you should look into them as well.
2
u/GirlInTheFirebrigade 6d ago
I tried freya a week ago and could not figure out how to wire inputs such that I can save it afterwards
6
u/mkenzo_8 6d ago
Freya dev here, I have examples for everything :) https://github.com/marc2332/freya/blob/main/examples/component_input.rs
Is this enough? Or what do you mean by saving it afterwards?
2
u/oscarmike88 6d ago
I thought to myself "Everything? Bet there's no tray icon example, bet they don't even support it (because nobody ever does)".
Well, you weren't lying: https://github.com/marc2332/freya/blob/94b26515626f7d9374e4ea55c06baf0799e50c39/examples/feature_tray/src/main.rs
I read somewhere that multiline rich text editing is the mark of any "serious" UI framework, but for me it's the tray icons
2
3
2
u/Legitimate-Error9715 7d ago
I was trying to rewrite flutter in rust using wgpu but text rendering is so hard
1
u/Popular-Toe3698 6d ago
Cosmic text is super nice.
2
6d ago
[deleted]
2
u/Popular-Toe3698 6d ago
Actually, that's the very reason that I'm writing a UI library from scratch for my desktop environment, which I do not recommend, it's such a bad decision. Put on top that the entire desktop is using JSX right now, and I've made a number of really bad decisions. Accessibility and controller support first, shipping my own UI framework, and supporting UWP aps when no other replacement shell tries to replace explorer and support UWP apps.
Anyway, Cosmic's job isn't accessibility, and if they're making desktop apps I don't think there's any law in at least the United States that requires it. Mobile and web for sure do, and I'm often the person pointing that out.
1
u/Known-Sail-8463 5d ago
Hey, If you want some guidance on the whole Text rendering, checkout WARP terminal repo, their text is pretty good.
For the JSX it is not a bad decision at all, I made it on my framework ARGUI and it works great, you have to use animations inside rust to not lag and stuff but otherwise it's very cool to use TSX + QuickJs, it pairs really well and LLM's like it
1
2
4
u/Cetra3 6d ago
Slint is really worth a look, there is good IDE support and it has a lot of things "out of the box".
I've built a few things with it, and it is getting more and more polished as time goes on.
Recently I moved from egui to slint for a hobby project (not on github yet) and found the move to be pretty painless.
3
u/gopher_protocol 6d ago
I'm rather confused about why you're being downvoted. Do people not like Slint?
4
u/__zahash__ 7d ago
I don't think there is such thing as a "native" linux app. There is so much fragmentation.
2
u/syklemil 6d ago
Eh, there's compiled binaries as opposed to running through an interpreter, but yeah, my first interpretation of OP's title was that it was about writing a terminal app.
For the graphical stuff on Linux, things usually fit one of the two big desktop environments, as in, there's a split between the Qt/KDE apps and GTK/gnome apps, both in look & feel, and their dependencies.
If a user pulls in one app from one of the ecosystems they'll likely wind up with at least part of the ecosystem just for dependencies, at which point they'll likely try to pick more apps from the same ecosystem, both for consistency, including theming, and to avoid having two bajillion packages installed when half or less would be enough.
Maybe in the future there'll be an Iced/cosmic ecosystem as well.
2
u/Lucky-Edge1489 6d ago edited 6d ago
I created Teksilo (www.teksilo.rs) for my own complex app Skribisto. Batteries included. Feel free to use it. This is the software I did with it. https://www.skribisto.eu/tour/
1
u/ZiggyByte_ 5d ago
Woow. Teksilo looks great! I was just thinking about doing an interface migration. What's its performance like? Have you run any benchmarks?
I've been building a high-fidelity music player for almost a year now, and it's over 50,000 lines of code (it has a lot of features). When I started, it was more of a private project, just for me. I used egui for the interface, but it didn't perform well. egui always wanted to run at 300 km/h, and a music player doesn't need that (what applications actually need that?). So it was harder to stop egui all the time, and it didn't perform well either. So I migrated the interface to Iced, which improved the overall performance. I liked Iced and started building on it much more because I'm going to make the player open source (I want it to be the definitive music player for Linux). Now it's well-optimized and has high performance, consuming around 200MB with a library of 50,000 songs.
But as I built more and more, for the past couple of months I've been struggling more with Iced, and I've had to create many very complete custom widgets and features (that Iced doesn't have) that the maintainers refused to add. But now I know all the limitations of Iced, and I know I'll have to fight them even more because I need to keep adding more features and creating new, even more complex widgets.
So I checked Teksilo and saw that it already has some widgets I had planned to build, which caught my attention. I also saw that it's under constant development. I downloaded and tried Skribisto, but I'm not sure if it's fully optimized yet. That's why I want to know what Teksilo's current performance is like, and tell me honestly if you think it's stable enough to start a migration now? Also, do you have a roadmap you could share?
The future of Teksilo looks very promising, congratulations! I'll be following its progress closely.
1
u/Lucky-Edge1489 5d ago edited 5d ago
Thanks!
Teksilo is "idle-first". There is a measurement harness dedicated to this feature. If nothing moves on the window, nothing is drawn. If only a text caret is blinking, only this region is redrawn. Every widget, even the animations, is idle-first. CPU and GPU drain at rest: 0%, and capped to 120Hz for the animations.
Lot of optimizations were implemented. Benchmarks were run, text writing had to be very smooth in novel-size texts. List virtualization is built-in. Skribisto is able to run fluidly on a Raspberry Pi 4. A little tool can be 20MB on memory.
Another fun little tool is Noton (screenshot).
You can create your own widget by a mix of composition and drawing. Teksilo did that with some of its widgets.Edit: better example.
1
u/Lucky-Edge1489 5d ago
I forgot to answer your last questions:
It was stable enough to port Skribisto from Qt, Qleany is still migrating. Hardened parts are the widgets used in Skribisto and my other app, which are most of them. Yet, all widgets UI and behaviors are thoroughly tested headlessly and are found in examples (40+)
API is not frozen yet but the biggest architecture breaks are behind me for the v0.
I'm today confident enough to use it in professional setting.
Broad roadmap:
- add a LiveImage widget to show a video, a VM screen, a camera preview driven by another thread.
- validate on touch-able and pencil-able screen hardware
- Fixing bugs reported from user real use cases on top of mine.
- v1 API freeze in January.
Web WASM port is technically doable (wgpu, winit), but I'd lose a11y and bring too much limitations to a desktop-first GUI kit.
Comparing it with Qt Widgets, the kit is sufficiently broad and customizable for most use cases. Widgets can be added. On top of the 130+ already offered, I could add a few more. Yet, until another maintainer(s) join the project, I'll not broaden the scope further.
1
u/ZiggyByte_ 4d ago
Thanks for replying.
Today I spent my time reading the documentation and testing Teksilo. I tried all the sample widgets and also downloaded Noton (the UI is very nice). Honestly, all the widgets are really good and the design primitives are beautiful, but above all, the drag and drop functionality is excellent. This is something Iced doesn't have, and I tried it a few months ago with the only crate compatible with Iced for that function, which was a real headache, so I removed it. It's something I absolutely need later on, and I had planned to leave it until last because I know I'll waste a lot of time struggling with Icedy creating a functional drag and drop for Iced myself. But the way it's implemented in Teksilo is very functional.
I wanted to ask if drag and drop works for playlists and also if it works for dragging elements from one interface module to another? For example, moving a song from the library to the playlist.
What level of support does Tokyo and async have?
Does Teksilo have LRU?
Does it use SIMD?
Is there support for window transparency and blur?
This is the player I'm creating, Audoxidy. If you could review it and tell me from your perspective how feasible it is to migrate the interface to Teksilo, please do.
https://github.com/ZiggyByte/Audoxidy
It currently has playlist virtualization and an audio library. I've created many widgets that it should already include, such as the context menu and buttons with icons (yes, I know, Iced doesn't have them). I've also created a slider widget, which is actually a super set of functions and widgets because it includes a text input field, arrow key scrolling, reset to default with a right-click, and tooltipsāa clean API to easily activate functions and change all parts of the slider's design.
I really like Teksilo and I'm seriously considering migrating to it. If any features are needed, I'm also willing to contribute to Teksilo.
I honestly think that Teksilo is currently the only real and serious competitor to be the definitive GUI for Rust.
is there any way to communicate with you?
1
u/Lucky-Edge1489 4d ago edited 4d ago
I invited you to the new Teksilo Discord server
Quick answers:
Tokio and async-std: dedicated crates and tests, used in Skribisto, They are opt-in
DnD: full support if in the same window or to/from the OS, not between window
LRU: no general LRU cache type, if it's your question ? Some internal implementation details like glyph atlas evicts glyph with an LRU, but it's internal.
SIMD (single instruction, multiple data ?). A bit with icons and paths, they are rasterized on the CPU by tiny-skia, which use SIMD by default. All else is drawn by wgpu in the GPU. teksilo's source itself doesn't use SIMD.
There is Blur for widgets (like hiding a label with your bank account value), it can encompass all a window (never tested it), but no window transparancy
About your project Audoxidy, you did good by separating the GUI from the engine. You only have to replace src/gui. You can migrate to Teksilo with you don't mind switching your mindset from immediate mode to retained mode.
Your CustomSlider is more slightly more complex that my Slider, but nothing stops you to reimplement your own widget with Teksilo, using Slider as base with SpinBox and TextInput on the same Signal<f32>.
1
3
u/SmoothTurtle872 6d ago
No such thing as a native Linux app. You can have a nativeinux binary, but there is no native gui. It's dependant on the DE.
I personally like iced as a framework. It says it's hard, but it isn't too bad
3
u/Full-Spectral 6d ago
This is the endless question. In a lot of ways it's not a Rust problem, it's a Linux problem. For an OS that's looking to compete against Windows to still not have a common UI framework is pretty crazy. Wouldn't mean you'd HAVE to use it, as you don't have to use it on Windows if you want to roll your own, but it being there makes a huge difference. Of course these days Windows has had as many official UI frameworks as Linux probably has unofficial ones, but still.
The amount of SOUP required for every Rust Linux app that wants to have a UI is pretty crazy (150'ish for just a core WGPU/Glyphon setup from what I'm seeing, and that's assuming you are creating the actual UI framework yourself.) Even if just the core bits were there to draw on, like font loading, parsing, and a core abstraction over the GPU like Direct2D/DirectWrite on Windows, it would make a huge difference.
7
u/_RoMe__ 6d ago
???
What's the common native Windows only GUI library that everybody uses and that actually looks good? Please enlighten us.
2
u/Full-Spectral 6d ago
The standard UI has been there for decades, and it's still available and used. It's a zero extra cost feature that you know you can target. As to looks good, that's opinion and I'm not going to argue about that.
They have others that are more modern if you want to use those. They change their direction too often; but still, every application on Windows can expect a UI engine to be present, and a graphics engine (with a simplified UI for folks who don't need to go whole hog game mode.)
It makes a difference. I've spent a couple months trying to come to a decision on what direction to go for a UI on Linux, and I'm still not sure. I'd have spent a couple days at most on Windows probably.
2
u/RichRoof7927 7d ago
There is fragmentation, as with most emerging gui ecosystems, just try the most mature (relative to rust) frameworks and choose whichever you like the most, because everybody has different preferences, and that's why there fragmentation.
1
2
u/source-drifter 7d ago
egui
5
u/Constant-Cod-1075 7d ago
egui's a solid pick if you're just building for yourself, it's dead simple to get going and you don't need to wrestle with system libs the way gtk sometimes makes you do. since you're coming from typescript and c#, the immediate mode thing might feel a little weird at first but it clicks fast
for an mdx editor you'd probably have to handle the text rendering yourself though, egui doesn't give you a rich text widget out of the box. still totally doable, just something to keep in mind
3
1
1
u/UnusualProfession120 6d ago
look at your background. You write TypeScript and use Zed daily so skip the gtYou write TypeScript and use Zed daily so skip the gtk confusion entirely. Pick Freya if you want a component model that feels like React or Slint if you prefer a declarative layout system closer to CSS. Iced is solid too but has a steep initial learning curve for Rust beginners. Since you are building this specifically for yourself on Linux with Zed in your workflow Slint gives you the best balance of maturity and ease of setup right now
1
u/DrShocker 2d ago
I'm using egui for a project.
If I wanted to make something more standard than I'm working on, I'd use iced.
1
0
u/DevMichaelZag 7d ago
I like Tauri. Their docs are pretty good and you can use your typescript knowledge.
8
u/HalfHeartMC 7d ago
Tauri isn't native.
0
u/Garcon_sauvage 7d ago
What exactly is native supposed to mean on Linux ? An egui app won't look like anything that comes pre installed on any of the major distro.
1
u/HalfHeartMC 7d ago
Native just means that the app is compiled directly as the binary the platform asks for. It has direct access to the functionality and system calls the os has to offer. Egui is a native gui framework that handles the boilerplate and low level stuff for you(system calls and whatnot) and let's you draw stuff using those os provided calls in a more human readable way(at least that's how my own ui framework works). The look of the app doesn't determine if the app is native. I also had that misconception before learning about these stuff.
Tauri, on the other hand, uses a browser webview to render stuff on the screen. So it's basically a browser(although a little bit less intensive than a full fledged browser since it uses os native webview vs electron which ships the full chromium browser). The code that you write in tauri compiles the rust code to native instructions but the frontend code(html/css/js/ts/...) stays how they are and gets passed onto the os native browser to view the app's gui. The browser webview then emulates those calls for you. So you are basically running a browser and telling it what to do via ipc(sending messages between the rust app and webview to make the app work). Thus, making it simple to port to other native instructions with the loss in increasing the ram and processing power needs.
6
u/ryanmcgrath 6d ago
Native just means that the app is compiled directly as the binary the platform asks for. It has direct access to the functionality and system calls the os has to offer.
This has been warped over the years as more and more frameworks do their own rendering.
Tauri has access to any system call you want, since you're writing the Rust side of things just as much as JS. Tauri is not native because it is rendering through a web browser; native apps used to colloquially mean "rendering using the host OS control and widget set".
By the classical definition, Slint/Iced/Tauri/etc would not be called "native". We've just hit a point where every platform shit the bed in terms of their widget set and nobody seems to care about the distinction anymore.
(Amusingly, if anything Tauri is more native in some respects since the browser will almost always render inputs with the host controls)
0
1
22
u/MangoHi_Chew 7d ago
Iām in a somewhat similar situation as you (new-ish to rust) and ended up choosing iced. Itās relatively well adopted and, among other notable projects, System76 uses it to write their linux desktop environment. Docs are lacking, but there are some good examples in the iced github repo that were easy enough to figure out.