Posted by signa11 10 hours ago
In 2004, the Eclipse IDE established consistent UI guidelines, built upon a cross-platform GUI library. API desgin is great, Looks and feels robust. The future of desktop GUIs looked bright. Little did we know that 25 years later it would turn out to be such a disaster.
Yeah, this can be a little extreme, and I feel we can benefit from being a little more open to trying new things.
The part about designing specifically for large displays and widescreen monitors was interesting. We can also reverse it, though: right now I'm away from home, and I only have this old laptop which is mostly great but has a shitty touchpad as the mouse, and I have to think this must be really common. However, this situation seems to be completely ignored by all desktop UX design. We seem to be pretty good at coming up with ways to use the mouse in our programs, but when the mouse is hard to control and unreliable, it causes pain. I guess I can use ratpoison or something, but that seems to be giving up too much.
Regarding the AI going deep into the filesystem and organizing my data...I'm extremely skeptical of inserting any kind of inherent unpredictability into how I interact with the computer. Giving a command or input should produce a well-defined and predictable (in principle) action. Getting rid of that paradigm fundamentally changes the relationship between the user and the computer in a way that, in my opinion at least, greatly diminishes its usefulness as a tool.
Sure, sometimes, when we have the time and surplus to deal with changes to things that already work well enough, and are not essential to doing our actual job.
That should be something you can opt in to.
Changing things for someone who's actually doing real work on top of the existing setup, is an undesired hurdle.
People are change-averse because they've been taught that change is costly, and they completely rationally ask "what's in it for me?". You want them to buy in to the change, you better give a good answer to that, one which is a more than negligible benefit in a few cases that the user may not care about. "Good enough" is good _enough_, it doesn't _need_ changes. Any change has to pay for its own retraining cost, in time and mental effort, otherwise it's a net negative for that user.
Being change-averse is the rational default behavior. Ignoring that, or even belittling it, is disrespecting your users.
The main issue with going beyond the mouse is that it involves changes across the event handling stack. For track pads, you have to build multi-touch infrastructure up ro a point and then there is a decision: what are gestures that are handled at a desktop level? What are gestures that get converted into semantically similar events (e.g. tap->LMB click)? What gets passed through as multi-touch? This ends up touching a lot of parts of the desktop software stack and the amount of required buy in to get this done on Linux seems massive.
And the original UX issue is much easier solved by bringing a mouse with your laptop.
... or using an Apple laptop. The one thing they haven't broken yet is that their machines are perfectly usable without a mouse.
Of course, the argument is weakening with every recent OS release, since they try to make it useless in other ways.
I try to use my partner’s windows laptop and it’s borderline unusable for me. She only almost uses it with a mouse plugged in. Meanwhile I don’t think I’ve ever seen someone plug in a mouse to a MacBook that wasn’t docked to a monitor and keyboard.
Are you on X or smth?
Or was there a different meaning?
Making it easier to choose allows for much more experimentation. I'm using Niri right now, which certainly isn't something you can just give users as a default.
That's obviously wrong, you could install an alternative start menu and stay where you are
Meanwhile it's been years since KDE Connect allows devices to talk to each, sending SMS on desktop from phone, pausing phone podcast from desktop, sharing files from XR headset to desktop, etc.
A lot could be improved but the modern open-source desktop is already doing great.
Many people don't use a clipboard manager at all, and even what exists today would be a huge upgrade for anyone accustomed to only a single clipboard "slot" that's instantly overwritten the next time you copy anything. Windows has one built in (though turned off by default), KDE Plasma ships with one, MacOS has third-party ones IIUC (not a Mac myself).
But imagine a clipboard manager that wherever you hit Ctrl+C also simply grabs the title of the active window and a deep link/URI that points to the cursor's current location (if a browser then it would be a URL, if a local program then some kind of local file:// URI). If you want to be really fancy, snap a screenshot too (maybe make this opt-in both for privacy and screenshot storage size concerns).
Then, whenever you pull up your clipboard history, a) it reminds you where you grabbed whatever text or image or document etc. that is, and b) with one click you can navigate back there.
I think we might get something like half of what Scott is talking about with "working memory" by adding this one affordance to existing clipboard history paradigms.
But for those who want to experiment, I've seen: - Tiling window managers (I3, Awesome, etc) - Highly customizable panels and launchers (Rofi, Lemonbar, etc) - Scrolling window managers (Nori, and others I think)
Honestly, the linux desktop has a lot of criticisms you could level at it, but lack of innovation isn't one. Where Windows and Mac have agreed on a standard that hasn't changed much in the last 10 years, Linux has about a zillion different visions for what a desktop can be.
Only a relatively small subset of tech enthusiasts want to tweak everything, and there are PLENTY of options for those people.
It's not on the program itself to restore its position, but on the compositor, who has every right and control to do just that. AFAIK it does work in plasma Wayland.
It's also a perfect use for local System One models that can classify prompts and forward them to the right module - calculator for math, distrobox for shell commands, LLM for natural language questions and normal search for everything else. Not using a fixed classifier because plugins should be able to add their own question types.
The article mentioned WinFS and relational filesystems. That's another good idea, integrate metadata so you can support use cases like finding all pictures of your dog or all playlists with Ed Sheeran songs (to remove them). Everything bound to the file entries instead of ID3 tags inside the file or app specific databases. It would be a lot more reliable and probably faster.
IIRC bcachefs is already a relational database but I don't know how good the query APIs are. If we can't do full extendable tags then at least add user defined groups/tags like Work and Games and Photos to make finding things easier. People remember what a file is better than where it's stored.
So I’m looking at the Raycast web site, and aside from the UI being a little different, Raycast seems like it is itself a clone of the already long-existing KDE Plasma start menu (Kickoff) and KRunner? I guess the only thing missing from the KDE one is “AI”. Is there something I am missing about how Raycast is some innovation not already realised in the Linux desktop?
> If we can't do full extendable tags then at least add user defined groups/tags like Work and Games and Photos to make finding things easier. People remember what a file is better than where it's stored.
Extended attributes[0] already exist if you want. But, as the linked wiki page indicates, filesystem attributes are fragile. And what is the tangible benefit? In practice, users can already just dump all their files into a random directory and use Baloo or whatever. Which is probably better anyway since it’s easier to have a D-Bus API with multiple user-space implementations than having to wipe and reformat to use a different filesystem if you have some problem with it.
KDE krunner has plugins. But there is not afaik a big tent ownership system like Raycast. And krunner is only going to attract KDE users. Raycast is mainly mac, but also, there's Vicinae which runs on a lot more systems, and it can run >50% of the Raycast plugins without a sweat, is designed to be drop in compatible.
It's also absurdly easy to write Raycast extensions. It uses web platform technologies that "just work", that don't have ornery toolchains and need lots of dev libraries installed. With KRunner you can probably use whatever library you want to do whatever you want, which is good, but hard, where-as with Raycast there's a pretty comprehensive and powerful API that offers a ton, that is well defined, and that other plugins will show you the way on. https://developers.raycast.com/
I can search and enter my search, and expect same results everytime, so muscle memory friendly. Gnome's search does calculation in search just fine, or search files, no need of any models. And app can provide their own search endpoint that gnome uses, to search in the app. Repetable, simple, and light.
Its boring, but hey, your everyday thing that is your starting point of the day do not need random behavior, or getting dependent on some 3rd party app that suddenly pulls the rug from under you.
This everything AI is so tiring.
Why would that be the case when you can have a no-scrolling-required list of apps you actually use?
I'd love to see an agentic OS where the OS and apps can both talk in terms of MCP things like resources, tools, skills. Yes these are primarily geared towards agents, but they are also acceptable machine-to-machine interfaces to script against too (so long as the type signature remains compatible).
Android's Intents feel related, similar-ish. It's a pity no one bit on PK's WebIntents. That could have been an interesting way to create abstractions for intents, for activities, for stuff happening on the computer. Notably the xopc actually had activities and a journal that let apps contribute meaningful intent to the OS as a whole. But mostly it just ended up as a history viewer there. Android mostly uses intents as a launcher. But this idea of having the activities of the system as available abstractions could go much further.
(link timestamped to 29min, where the demo starts.)
Scott is a very good presenter, and he clearly thinks about this stuff a lot. I really liked the demo for moving windows to the sides of the screen, since it's kind of how I use the alt-tab interface -- look at the preview for the window/app I'm looking for then tab to it or click on it. Having a visual overview of all currently open windows could be useful to me. (It might actually get me to close things I'm not currently working on! Although my dozens and dozens of browser tabs tell a different story...)