A bit more than four years ago I started the xi-editor project. Now I have placed it on the back burner (though there is still some activity from the open source community).
The original goal was to deliver a very high quality editing experience. To this end, the project spent a rather large number of “novelty points”.
I’ve written the CRDT part of this retrospective already, as a comment in response to a Github issue. That prompted good discussion on Hacker News. In this post, I will touch again on CRDT but will focus on the other aspects of the system design.
An immediate mode GUI library written in Rust. Works anywhere you can draw textured triangles.
sailfish actix qt gui
Ever since it’s illegal for me to leave my house, my weekends have been filled with rewriting Whisperfish. Whisperfish is an app, originally by Andrew E. Bruno, that natively implements Signal for SailfishOS. My goal with the rewrite is to modernize the non-GUI code such that it uses the official libsignal-protocol-c instead of the Go-reimplementation. For this, I would either use C++ or Rust; the title of the post probably spoiled which one I prefer.
I’m imagining two target audiences for this blog post: either you’re a Rustacean, and you’re here for the Tokio and Actix magic, or (and that’s not xor) you’re from the SailfishOS community and you’re wondering what all the Tokio and Actix buzzwords are even about. With that in mind, I’ll make an introduction on both topics, and depending on your background, you can skip either.
Alchemy is a Rust GUI Framework, backed by native widgets on each platform it supports, with an API that's a blend of those found in AppKit, UIKit, and React Native. It supports a JSX-ish syntax (RSX), styling with CSS, the safety of building in Rust, and a familiar API for many developers who build UI on a daily basis. The goal is to provide an API that feels at home in Rust, while striving to provide a visual appearance that's easy to scan and parse. It does not, and will never, require nightly. It's still early stages, but feedback and contributions are welcome.
One of the primary reasons computers are so ubiquitous in modern society is their ability to let humans and software cooperate to achieve a desired goal. That is, to be interactive.
Creating interactive applications can be pretty annoying for a programmer. Unlike a computer which is predictable and will blindly follow any instructions given to it,
The ideas and concepts shown in this article aren’t overly advanced. In fact, if you’ve been programming for a couple months (especially if it’s part of a formal Computer Science program) you’re probably already familiar with them.
The difference between an “ordinary” programmer and a Software Engineer isn’t in how many advanced concepts they know, it’s the ability to identify a pattern, understand why it exists, and employ it to solve a problem. The experienced software engineer will do this in a way which won’t make them sad 6 months from now when they need to revisit the code because the boss has asked for a shiny new feature.
Tobias from our design team created an excellent Librem 5 app design tutorial, which covers GNOME design philosophy, going from sketches to mockups, convergence and even how to name your app. The three part series designs a Wallabag app for the Librem 5 called Read it Later. Wallabag is a link saving service with apps for various platforms, which now includes the Librem 5 thanks to Bilal Elmoussaoui. Bilal is a passionate community member who turned Tobias’s designs into a fully featured app. Purism community member Thibault spoke to Bilal about the development process and contributing to the larger ethical software movement.
When it comes to creating modern looking Desktop applications, JavaFX is a tried-and-tested weapon of choice. The rise of the Kotlin programming language as a Java replacement makes the proposition even more appealing as it comes with new powerful features while cutting down on verbosity. The good news is that it can be interfaced with a Rust WebAssembly library thanks to the Asmble tool. This tutorial is an example of how this can be done.
As I’ve worked on my Pushrod library over the past year, one of the major struggles I encountered was trying to figure out how to draw using just the GPU, instead of drawing directly to the on-screen Canvas.
I originally started this project using Piston (thus, the engine analogies), and found that library to be overly complicated for what I wanted. Although it provided all of the features I wanted, it introduced a lot of overhead that was concerning. Not to mention, Piston is a more game-oriented library.
I ultimately settled on SDL2.
In trying to figure out the best reactive structure for druid, as well as how to communicate that to the world, I’ve been studying a wide range of reactive UI systems. I’ve found an incredible diversity, even though they have fairly consistent goals. This post is an attempt to find common patterns, to characterize the design space as a whole. It will be rough, at some points almost a stream of consciousness. If I had the time and energy, I think it could be expanded into an academic paper. But, for now, perhaps these rough thoughts are interesting to some people working in the space.
When talking to various people at conferences in the last year or at conferences, a recurring topic was that they believed that the GTK Rust bindings are not ready for use yet.
I don’t know where that perception comes from but if it was true, there wouldn’t have been applications like Fractal, Podcasts or Shortwave using GTK from Rust, or I wouldn’t be able to do a workshop about desktop application development in Rust with GTK and GStreamer at the Linux Application Summit in Barcelona this Friday (code can be found here already) or earlier this year at GUADEC.
Implications of Rust's borrow checking and memory ownership on GUI development (simple case)
I’m one of the maintainers of Winit, the main pure-Rust window creation library. Even if you haven’t used it directly, you’ve probably heard of projects that depend on it - Servo and Alacritty being the best-known applications that depend on our codebase. If you’ve done any graphics programming in Rust using Glutin (or dependent projects including gfx-rs, Glium, and Amethyst) we’ve been the ones making the windows actually show up on your desktop.
This announcement details the major changes since Winit 0.19. Also, we are looking for new contributors! If you are interested in working on the foundations of Rust’s GUI story, now is a great time to join the project.
View all tags