Very nice! I have been working on something similar so I'm glad more people are going in this direction. QML is so obviously one of the best things that happened recently for GUI development, but it's not used enough.
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.
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.
mshockwave 19 hours ago [-]
I thought the original comment meant “_for_ who doesn’t use X or Discord, here is the github mirror link”. There’s a “for” missing, and thus I think they agree with you
1dom 6 hours ago [-]
I think there was a typo so you took the opposite meaning from the post - I think that's fairly innocent an unavoidable, we're all human. But how you chose to respond to what you'd inferred wasn't really helpful, actionable or informative for someone who might be naively using Discord.
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.
3 hours ago [-]
gr4vityWall 5 hours ago [-]
At least from the demos, that seems to be a drastic improvement in iteration speed compared to other native/not-web-based toolkits. I'm gonna give it a try.
Still wish there were other scripting options besides QML, and we could tap into the React ecosystem.
I'm not a fan of the language but QtQuick & QML is what I'd use for this type of widgets. OTOH I am starting two projects at work, one being a traditional desktop app and another being an HMI with lots of functionality, and decided to just go with QtWidgets and save myself from all of QML's JS influences and C++ interop boilerplate.
vhantz 10 hours ago [-]
What boilerplate?
ethan_smith 4 hours ago [-]
QML's declarative syntax combined with C++ performance and its property binding system makes it uniquely powerful for responsive desktop UIs without the overhead of web technologies.
nylonstrung 3 hours ago [-]
It would be wonderful for games as well but I don't see it used there much
jp1016 7 hours ago [-]
Looks futuristic! I really like the modular “building blocks” idea. I’m working on something similar in a different space with BeaverGrow, a productivity tool where you can drag and drop blocks to build custom dashboards with the widgets you need. you can checkit out here - https://beavergrow.com
zekenie 1 days ago [-]
Neat! What OSes does this support?
RGBCube 1 days ago [-]
Currently Linux and I think BSD, and the creator has said he wants to support MacOS and Windows, though those will only be included in the paid product.
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.
oblio 1 days ago [-]
Weirdly, the fact that the Windows and MacOS versions will be paid makes me more optimistic.
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.
outfoxxed 22 hours ago [-]
I expect Windows to be easier than Mac, especially if attempting to respect SIP, though I've not done much research yet and don't plan to until the Linux version is in a state I'm happy with or I'm forced to heavily use a Windows/Mac machine and need to make it bearable.
8n4vidtmkvmk 22 hours ago [-]
I'd probably pay to skin Windows if it worked really well (fast and no flashes of unskinned stuff). I've wanted to tinker with that for ages but I don't even know where to begin.
accoil 19 hours ago [-]
Windhawk[1] has some plugins for styling (using XAML). I don't really style anything apart from removing the "Recommended" section from the start menu, so I'm not sure how fast styles get applied.
I was remembering this from when? 20 years ago? I was using Linux already but have to use Windows at work and couldn't tolerate not being able to change things to my liking
pmarreck 1 days ago [-]
gonna say "linux only" given linux is the only OS this configurable
jeroenhd 19 hours ago [-]
Custom Windows shells go all the way back to Windows 9x. All you need to do is hide the task bar (or kill explorer.exe) and run your own replacement. Even Microsoft released a downloadable window manager of sorts with PowerZones and they added a registry key at some point so people could stop breaking their updates by replacing explorer.exe and just specify a replacement executable instead.
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.
jdiff 1 days ago [-]
Both macOS and Windows have alternative window managers available, although macOS does need to be mutilated somewhat heavily to make it happen.
yjftsjthsd-h 16 hours ago [-]
Linux isn't the only F/OSS user-friendly OS; in terms of desktop customization, FreeBSD, NetBSD, OpenBSD, and illumos distros are basically all equally good.
nathan_compton 5 hours ago [-]
Now I need a tool for quickly destroying widgets, doodads, animated boingos, and general visual noise, from my desktop.
alpaca128 3 hours ago [-]
That's achievable in multiple ways. A standalone window manager for example. KDE with all widgets removed and "do not disturb" mode should work too, but I haven't used KDE in a long time.
actinium226 1 days ago [-]
Looks nice!
19 hours ago [-]
burnt-resistor 1 days ago [-]
[flagged]
treetalker 1 days ago [-]
To be fair, I think that's just the background on one of the highlighted user creations that the website is showcasing.
burnt-resistor 1 days ago [-]
[flagged]
jdiff 1 days ago [-]
I'm no fan of 3000 year old vampire dragons, but this is not a 3000 year old vampire dragon. The whole of Japanese animation should not be reduced down to 3000 year old vampire dragons.
zahlman 1 days ago [-]
I don't think I'd even call it anime in the first place.
Valodim 1 days ago [-]
similar to how counter strike celebrates gun violence, right?
mmh0000 1 days ago [-]
[flagged]
jdiff 1 days ago [-]
Interesting that the video being used as a showcase is dropping so many frames. Is QuickShell particularly heavy, the system recording particularly anemic, or something else? For the first half of the video I didn't realize QuickShell supported transitions at all and thought it only had hard cuts between different states. It looks like a very interesting project though and a worthy time sink, especially with those transitions being supported.
egypturnash 1 days ago [-]
It’s something else, in your connection or your computer. The video plays fine on the old iPad mini I’m using right now and shows transitions from the very first action.
zahlman 1 days ago [-]
The page actually crashed my computer the first time. ("Why did you try again?" I've had the same issue with a couple of other specific things — most notably the clipping interface on Twitch, which causes it reliably — and I'm trying to figure out an ultimate cause; but I really don't know what I'm doing there.)
LoganDark 1 days ago [-]
The video is 125fps (according to ffprobe) and appears smooth on my 120Hz display, so maybe you're the one dropping frames.
zamadatix 23 hours ago [-]
125 fps should actually be a huge red flag, not that the video FPS is the be-all-end-all of what the render FPS actually was anyways, as that's extremely unlikely to be their (that is the recorder's) refresh rate. Since the other video has a different (but equally odd) refresh rate, we know it isn't their refresh rate for sure, which also means we know there would at least be judder (recording at a mismatched framerate from the content) or at worst drops.
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:
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.
dietr1ch 23 hours ago [-]
Yeah, it's outstandingly smooth for a web video.
lucideer 23 hours ago [-]
fwiw in Firefox on my old Android phone I saw the same choppiness watching it in page but downloading & watching it locally it was smooth.
On very fast WiFi & the video is only 2MB so I can only presume something in the page is competing for device perf.
downrightmike 17 hours ago [-]
FF is certainly choppier
jmrm 23 hours ago [-]
I can also watch it totally fine in a cheap recent Android phone at Firefox
Rendered at 15:30:38 GMT+0000 (Coordinated Universal Time) with Vercel.
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...
https://github.com/search?q=quickshell+language%3Anix&type=c...
This looks very cool!
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:
https://github.com/quickshell-mirror/quickshell
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.
Still wish there were other scripting options besides QML, and we could tap into the React ecosystem.
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.
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:
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.