| ▲ | vhantz 4 days ago | |
Really interesting. I'm bookmarking your comment for later. One thing you can do is separate the information fetching from your bar completely. I have a service that runs every minute or so to fetch available updates from the arch repositories (including aur), it writes its output to a file and then my bar regularly updates it's displayed information based on that file. I don't have the service definition uploaded anywhere, but you can see how simple it is to then integrate it with anything here [1]. This is a status bar I'm building with qml. It's not ready to be released yet, I'm at 0.7.0. Only tested on x11/i3wm so far. Last time I launched it in wayland/sway, there were some issues but it's been a while since. Since it's built with qt complex and non-blocking interactions are available out of the box. For example, switching workspace by clicking an icon in the bar, or switching the format of the displayed date time. | ||
| ▲ | tombert 4 days ago | parent [-] | |
Yeah, the current design is kind of an iterative process; I started with a considerably simpler thing that just had the clock and date and currently selected program, and then I thought it might be neat to try and add add some async stuff and it ballooned from there. I do have the state persisted in a msgpack binary, but the data fetching is done within the app. I don’t know that separating it out would necessarily be better, I kind of like that I have the pipeline set up on such a way that the fetching for sync and async stuff can be reused. I am debating rewriting this to use the slightly lower level NIO selector class instead of core.async, but the memory on this is low enough to where I am not sure that it’s worth it. I have been writing a lot of helper apps in Rust for Sway as well, mostly as an excuse to play with Rust more [1] [2]. I will take a look at your stuff. I have wanted an excuse to learn a bit more about Qt. | ||