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.
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.
> The demands for memory safety are not unreasonable, in fact, I consider them too feeble for the long term, so responding to the demands is in the interest of C++
> The sky isn’t falling, but unless we act now and get C++ onto a track supporting a flexible framework of profiles (supporting various forms of safety), we risk a painful decline.
He's simply making the case for profiles and trying to rally the people he works with around that as a necessary goal. That's something that any leadership has to do from time to time. That's also something he's done before when he warned everyone about proposing a bunch of incompatible features with no clear vision. Nothing unexpected here, in no way is this "panicking".
It is done by the extension without any fancy stuff. Extensions can load static js / css and bypass CSP with it, if it is declared in their manifest.json. Grammarly's manifest.json is here: https://gist.github.com/Daquisu/11eb1a7000b4141c4404edcc6e16...
For more advanced CSP bypass with extension, you can:
1. Inject JS code into any webpage with a CSP.
2. Create an event listener for your content script and reacting according to it.
3. Use your content script to communicate with the background script.
4. Use the background script to communicate with any website, including blocked websites by the CSP.
Basically, any website <-> extension content script <-> background script <-> any website.
