The issue with KDE is not the "UX", the issue is the crashiness and jank, which is an issue of C++ and the OOP-ness of Qt, respectively and no amount of philosophizing will fix that. Users can excuse high memory usage, users can excuse low FPS, users cannot excuse jank and crashes.
It is very hard to pin down the problems with Qt because on the one hand you can produce well-working UIs with QML if you are committed to it, see Telegram which has a near-perfect UX and I've never had it crash on me. But I think this is more of a cultural problem: KDE is spread thin, has no real leadership and tries to create a "inoffensive medium" of a desktop that pleases "everyone".
What would be better is a) finally ditching Qt Widgets completely and using QML for everything across all applications, b) moving towards a more functional-reactive approach and getting rid of the OOP mindset inherited from Qt Widgets (which fuses visual and domain data) - hard to achieve with Qt and c) requiring the developers to use some version of Windows and macOS in between, because it happens often with Linux users that they get "blind" to their own issues habitually, they need to experience what 90% of the world uses, so then they can take the good ideas to KDE. But if you use Linux 100% of the time, obviously it'll be "the best" because you're so used to its jank.
Also, develop a target audience. He hates on Omarchy in the video, but at least Omarchy has a target audience: the agentic-first, keyboard-first hypebro libertarian SaaS web developer. Okay, maybe a niche audience but at least that's something. KDEs target audience is... "everyone". Which then results in a "mid" desktop which just has to be worshipped by the fact that "it's open-source". And now, apparently the target has switched to "corporate users / governments". I'll say this is a bad idea because that's like an abusive relationship, you have constant bureaucracy, have to agree with their politics and views, have tons of red tape and low IT literacy. But at least it's "a" target audience, better than pleasing "everyone".
I will believe KDE cares about UX once they finally fix the clock to have the same font size for date and time, like Windows does it - first rule you learn in web design is to not use too many font sizes and KDE immediately breaks a very basic UX rule and has inconsistent font sizes everywhere. Then afterwards, they need to learn about stem widths and why using "1px borders" and thin fonts is not exactly the best thing for readability or low-resolution monitors. There's just so much wrong with KDE and Qt, architecturally and visually, that the "bad UX" problem is just a downstream result and I don't think a glorified Stage View will fix this.
> I will believe KDE cares about UX once they finally fix the clock to have the same font size for date and time, like Windows does it
At least the date time on KDE taskbar is readable and you can change it to show date and time side by side and that uses same font size for both.
Windows taskbar date time are so tiny (with so much empty space around it) and doesn't even change if you change font scaling.
On the other hand, Windows doesn't make excuses for literal decades why you can't set the time format to THE international standard which is the only format that makes sense.
Robert Braxman's provisions have ranged from highly insecure devices, EOL devices, charging for TOR as a service, an "e2e encrypted" chatroom that sends the key in plain text, etc.
I only used their "DeepWiki" automatic docs, they are pretty decent at getting an overview of a large project and are relatively accurate, with diagrams and anything. Haven't tried out their coding agent stuff.
The len(pics) can be O(n), especially if iterators are used like here. Also, an O(1) lookup would require a previous O(n) pass over the data anyway.
The picture selection algorithm's kind of single-pass iterator usage might have been more performant back in the XP days, as it avoids possibly expensive operations.
Modern CPU/other optimizations might make a multi-pass approach more performant due to better memory locality or other factors.
They got that from Anime seasons. Every prompt has yet another cliffhanger to keep you hooked. But the Season II story arc where Claude-chan fights the NsPasteboard boss battle on the journey to the UIViewMainController, I thought that was pretty intense. I guess I just gotta keep watching my terminal to see what happens to the main character input - rooting for him to survive the next season, but you know they always kill off the good input characters early.
I just go over the comments with Gemini 3.1 Pro at the end which has a much more normal "voice" and it doesn't lose nuance as a cheap model would. I don't care so much about what Claude writes during the debugging as I just do all the cleanup at the end instead of at every commit.
Maybe we should think about laws to make this "scraping without caching" behaviour punishable, i.e. "if AI companies do scrape sites, they're required to implement caching and use the most efficient method and not abuse the other persons resources". Maybe difficult to do in practice, but at least it could be a deterrent to some extent. Where are all the environmentalist politicians when you actually need them?
I still have quite a few systems which doesn't have a GUI attached to it, and I access them via a pure console.
Most, if not all these systems have Matrox G200 or similar low end 2D integrated graphics which are just there to see the text during boot, nothing else. I sometimes SSH from these systems to my own systems to use TUI or CLI tools.
If I want to go a step further. We have a couple of real VT320s.
Working at a datacenter has it perks, it seems. :^)
That's awesome, I have one too and I fell in love with it. I fixed up the old gif320 program to run properly on modern machines a while ago and made a C# port too:
How do you deal with modern programs not respecting TERM/LANG capabilities? I found even using man pages on my machine would sometimes result in the terminal getting caught up on some invalid byte sequence emitted from some unicode that snuck its way through or such.
I ended up writing a program I called VT320 Translator, or vt320t for the name of the binary, which in broad strokes runs your target program in a background terminal and sends curated updates to the VT320 while passing through keyboard input. (You can kind of approximate this with just screen and some other things but it doesn't end up being very good IME) This lets me do some neat things like translate unicode characters into DRCS (Dynamically Redefined Character Set) sequences that you can actually see on the VT320, use optimized heuristics for screen updates tuned to the exact hardware, etc.
At the core is a vtparse-based VT320 emulator that strives to be as accurate as possible with an accompanying diff generator from one emulator state to another. If you're interested I could get into more of what I've done here and even get the code onto my github - it's been private for a while because it's being used in an upcoming game demo but I could easily separate out the non-game-related parts that make up vt320t.
Yeah, these terminals are something else. They are built like tanks and they just run. Also congrats on fixing up gif320 and developing vt320t. This is how old systems got preserved. I recently learned that a PDP-10 I have a photo of has been transported to a museum and restored to running condition. This is the second good news which made me really happy.
If it's not a problem, can you share the vt320t source code on GitHub, if not you can share it privately and it can stay between us. I'm not in gamedev, even remotely, so the game parts has no utility for me. It's completely up to you. I'd love to read some low level code talking with vintage hardware. You can find my contact information at my homepage, which is on my profile.
On the other hand, our VT320s doesn't do anything fancy these days. We generally use it to talk with our networking devices like switches and routers over RS232 since they can communicate really well with each other. While we have lots of hardware to tend and projects to run, maybe I can hook-up one of the VT320s to something for fun.
Thanks for your lovely comment and spending time for all of these. It's greatly appreciated here.
Oh, also your homepage is great. I liked it a lot.
Here you go, just finished getting it all together. I do plan to add the game stuff here relatively soon - I'm just saving it for a certain demo to be released, but I did include a screenshot, as well as some pictures of vt320t running with real hardware.
> Oh, also your homepage is great. I liked it a lot.
Oh, thank you! I'm probably even going to put a WebGL/whatever Unity exports to these days for web up there when I can so the terminal emulator can be used on there.
The software model has to however be easy for agents to debug in a loop, then it works very well. I recently got Fable to take a desktop app (AzWriter[1] - screenshot Mac: https://imgur.com/31DBG04 + Linux https://imgur.com/1IavBvS) from about 150 Mb -> 80 - 90 Mb on a reasonably complex UI (around 40 pages of text, paginated, etc.), even beating KWrite (160Mb even on KDE, even though KWrite doesn't do pagination or complex text layout, was a surprise to me).
What was important for this was the fact that I can run JSON-defined e2e tests[2], also good to find frame-based leaks, stale-ID problems and general "program shows its using lots of memory in the task manager" (task managers are wildly inaccurate for this, as I found out).
So, I can just tell it "okay, loop this e2e.json test over and over again, use heaptrack, samply, find out why and exactly where it's slow, memory-hungry - find the section in the codebase, figure out a solution" and then let it run overnight. The biggest difficulty here is that many perf tools are still written for humans and that things like "how much memory are we using" is a wildly complex topic (lots of problems actually getting the correct number without over-allocation, memory allocator slack, OS-level page size, memory fragmentation, etc.).
But Fable was able to track down things like "LCD font hinting causes 90k allocations that are unnecessary", etc. etc. - which then also improve frame time, usually. Memory optimization + better perf pretty much go hand in hand (less allocations = more perf). I could track them down manually probably, but it would take way more time.
Having some basic understanding of data-oriented design, cache locality, memory tiering (L1/L2/L3/main RAM), does massively help with architecture decisions (e.g. Azul can use a single buffer for the entire DOM node list, in difference to normal browsers which do the more "object based" allocation model, which massively helped page breaking performance on html-to-pdf use cases[3]). Pure-functional style also helps (f(State) -> UI) because then it gets very easy to drill down exactly where things are slow and where caches are needed.
I used it in https://fschutt.github.io/printpdf for the HTML-to-PDF layout, just as a note. It is very useful, thanks for your work. Good luck on Blitz.
It is very hard to pin down the problems with Qt because on the one hand you can produce well-working UIs with QML if you are committed to it, see Telegram which has a near-perfect UX and I've never had it crash on me. But I think this is more of a cultural problem: KDE is spread thin, has no real leadership and tries to create a "inoffensive medium" of a desktop that pleases "everyone".
What would be better is a) finally ditching Qt Widgets completely and using QML for everything across all applications, b) moving towards a more functional-reactive approach and getting rid of the OOP mindset inherited from Qt Widgets (which fuses visual and domain data) - hard to achieve with Qt and c) requiring the developers to use some version of Windows and macOS in between, because it happens often with Linux users that they get "blind" to their own issues habitually, they need to experience what 90% of the world uses, so then they can take the good ideas to KDE. But if you use Linux 100% of the time, obviously it'll be "the best" because you're so used to its jank.
Also, develop a target audience. He hates on Omarchy in the video, but at least Omarchy has a target audience: the agentic-first, keyboard-first hypebro libertarian SaaS web developer. Okay, maybe a niche audience but at least that's something. KDEs target audience is... "everyone". Which then results in a "mid" desktop which just has to be worshipped by the fact that "it's open-source". And now, apparently the target has switched to "corporate users / governments". I'll say this is a bad idea because that's like an abusive relationship, you have constant bureaucracy, have to agree with their politics and views, have tons of red tape and low IT literacy. But at least it's "a" target audience, better than pleasing "everyone".
I will believe KDE cares about UX once they finally fix the clock to have the same font size for date and time, like Windows does it - first rule you learn in web design is to not use too many font sizes and KDE immediately breaks a very basic UX rule and has inconsistent font sizes everywhere. Then afterwards, they need to learn about stem widths and why using "1px borders" and thin fonts is not exactly the best thing for readability or low-resolution monitors. There's just so much wrong with KDE and Qt, architecturally and visually, that the "bad UX" problem is just a downstream result and I don't think a glorified Stage View will fix this.
reply