Browsing quickly through the docs I can see we've made some of the same choices. Although I have no plans to support anything other than X11/i3wm right now (simply because that's what I use). And I have things a little bit more clearly separated. I have a small library (qi3pc)[1] to bring i3's IPC to Qt's signal/slot mechanism. And a separate project (buffalo)[2] that's a bar that uses qi3pc. None of them have reached 1.0 yet. That should be soon for qi3pc. And Buffalo eventually. Since they aren't released yet, docs are sparse (for buffalo mostly) and I haven't talked about it online much, but there's a little preview here[3] for any interested.
1. https://git.sr.ht/~hantz/qi3pc/tree/staging/hantz 2. https://git.sr.ht/~hantz/buffalo/tree/staging/hantz 3. https://www.freelists.org/post/i3-discuss/I3bar-doubleheight...
Couldn't find the releases-only feed in Forgejo RSS, the blog seemed to be outdated and who doesn't use X or discord, here is at least a github-mirror where you can subscribe to releases:
People with the privilege to make choices based on their values, and whose values include human rights, and freely accessible information (respectively).
I wouldn’t judge anyone who chooses to utilize either service (I still have accounts on both), but I can certainly understand why some would rather not.
Thanks for the GitHub mirror link, that’s probably where I’ll start. Neat project.
People would have to be living under a rock to not understand issues people might take with X, but it's possible to be on HN and have very little understanding or context of the issues around Discord.
So for others:
- Most content on Discord is not easily discoverable outside of Discord
- Despite using terminology like "servers" and other things associated with open self hosted tech, Discord seems very closed source, for profit and generally opaque.
Regardless of how harmful all that is to an open internet, there seems to be a growing trend of smaller github projects depending on Discord instead of thorough documentation. I feel there must be quite a few people who want a certain world (open tech) who are not aware that Discord often looks to be working against that.
I've used Discord a little, but I don't feel very comfortable or capable with it, so I might be very wrong with this assessment.
https://github.com/search?q=quickshell+language%3Anix&type=c...
This looks very cool!
To get the Qml engine to work with any other code you need to write the bioler plate interop between your language and the Qml engine.
They also essentially have a performance limitation that you need a license to bypass. Slint has removed this performance limitation but is not compatible with Qml.
Can you elaborate?
> qmlsc will be used instead of qmlcachegen if the Qt Quick Compiler Extensions are installed. [1]
> Qt for Application Development Enterprise > INCLUDES: > … > Qt QML Script Compiler extensions for advanced software compiling [2]
[0] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html#summ...
[1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html#the-...
I have found better value from immediate mode GUIs like Iced or Egui.
Still wish there were other scripting options besides QML, and we could tap into the React ecosystem.
These days I only really use a terminal with tmux and a browser so I don't really spend anytime "optimizing" my DE.
Check out dankmaterialshell if you want to see a really nice turnkey setup using quickshell + Niri compositor https://github.com/bbedward/DankMaterialShell
On Linux and BSD, it supports Wayland and X11, though Wayland is better supported.
ie, Quickshell will forever stay completely free for free operating sysems.
Customizing at least the Windows window manager isn't for the faint of heart and its architecture doesn't have a lot in common with Linux so such an effort is very far from a straightforward port, and as a result most Linux desktop software and especially stuff that deeply integrates with the desktop environment is basically never ported or the port is incomplete, buggy, short lived, etc.
KDE4 was supposed to fully support Windows and 15+ years later I'm fairly sure that dream is dead.
[1]: https://windhawk.net
Custom shells might break some shitty old programs relying on Explorer running as a shell, but the Windows 11 taskbar probably killed those off already.
There are API differences between Linux and Windows of course, but nothing that Linux has that Windows doesn't. As this is based on Qt, a lot of API compatibility will probably already have been taken care of. It just requires someone to go through the effort of writing and maintaining their OS ports.
It allowed to switch between new shell experience (Windows 95 explorer style) and old Program Manager
This all strongly hints to the videos being variable frame rate encoded. A quick dump of the timestamps with ffprobe and then a quick transform to the deltas seems to agree with this https://pastebin.com/raw/PbbNGBVy
The most common frametime is 0.006945, which aligns with a 144 Hz target refresh rate. This makes sense as 144 Hz makes perfect sense as their monitor's refresh rate. Ignoring timestamp rounding differences, these are the inconsistent frametime buckets:
0.006945, 0.01389, 0.020836, 0.027782, 0.034726, 0.041672, 0.048617, 0.062508, 0.076399, 0.097235, 0.10418, 0.118071, 0.145852, 0.166689, 0.229196, 0.256978, 0.29865, 0.354213, 0.395886, 0.513957, 0.770935
Watching a VFR recording of a 144 Hz desktop on a 120 Hz display may still seem smooth to you (after all, movies are 24 FPS and most online videos only 60 FPS) but it does not preclude frame targets being missed, as the data shows.VFR video is relatively uncommon as well, so I wonder if that's why people are reporting so many performance issues viewing the video with different setups. I.e. between all of the reports of stuttering, it's probably both the video itself and the devices trying to play the oddly encoded video.
On very fast WiFi & the video is only 2MB so I can only presume something in the page is competing for device perf.