<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at blogs.kde.org Port 443</address>
</body></html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.52 (Ubuntu) Server at blogs.kde.org Port 443</address>
</body></html>
Yes definitely, the two OS X’s features I miss the most when using KDE are Quicklook and Dolphin with Miller columns. I got really excited to see that at least someone is working on that direction.
Is Whale a new file manager, I’ve never heard of it before.. any hope that Miller columns will return to Dolphin?
Kind of new, yeah. It is the new crop of KDE apps that are designed to be consistently developed and convergent, i.e. that will work on any hardware, desktop or mobile, and as on many software platforms as possible.
It is from the same (very loose) team that make stuff like Tokodon, NeoChat, Merkuro, Arianna, etc.: Carl Schwan, Josh Goins, Tobias Fella, Claudio Cambra, etc.
Well, it’s good that you enrich the KDE ecosystem, I just hope that “convergent” apps will never dominate the “classic” desktop apps – with menu bars, toolbars etc.
This is a terrific update with many useful changes. I have one ongoing pet peeve though.
Kirigami toolbars that don’t add anything tangible, duplicate (or in this case, triplicate) the title bar text immediately next to it, and waste space in the most awkward kind of way.
The Stopwatch screenshot is the ideal example for this. The app would be better off if the entire toolbar at the top would not exist. On desktop at least. Yet, Kirigami pushes everyone into adding this everywhere by default and it’s terrible.
What’s worse though is that optional page actions make this a non-trivial problem to solve. The Clock screenshot shows that we can’t just get rid of the toolbar altogether, because we need to figure out where the actions will go. Yet, two simple actions still add an unnecessary extra title that’s frankly worse than leaving it blank (here: “Time”) and add a whole lot of unused ugly space at the top of the window.
I really believe that we need to get away from the full-width toolbar paradigm in Kirigami. Control visibility per column, so that columns without a good use for the toolbar area will use the entire window height. Make page title visibility opt-in. Hide the toolbar area by default if neither title nor actions are set.
It’s great that we have a mechanism to define pages and actions easily. But developers should use it consciously, rather than having to design around its bad default behavior. It holds us back as a community and development platform.
This needs to be fixed rather sooner or later with a better app design paradigm and corresponding changes in Kirigami. The easy way to make apps must also be the good way.
I agree, the update brings some great improvements overall. But you’re right about the toolbar issue — on desktop especially, it often feels like wasted space. The duplication of title text can be distracting, and sometimes simpler is just better. Hopefully future updates will offer more flexibility with Kirigami UI choices.
No. I’m advocating for keeping the titlebar and not duplicating something like it inside the window itself.
That said, in the long run I’d be interested if KDE could adopt something of a mixed-mode decoration approach, where the application and the compositor negotiate an area of the window (on the top left and/or top right) that’s drawn and exclusively used by the compositor with title bar contents, but which does not have to span the full width of the window.
@jpetso, in the short term, invent.kde.org/libraries/kirigami-addons/-/merge_requests/75 would have assisted users. There’s many a QtWidgets application with similar toolbars, but it doesn’t matter as much when removal is a mere click. The inability to even move a toolbar is much of why I’ve yet to utilise any Kirigami applications by choice.
I agree! I think that would show GNOME how it can be done without alienating other DEs.
“Wasted space” seems unfortunately to be the staple of (“convergent”) Kirigami apps, as it was noticed in the ongoing Reddit thread on Whale.
Oh, nice, I didn’t notice. Still, I definitely prefer Kontact’s UI – and use neither, because of Akonadi. (I attempted to switch to Kontact many times over the years, something in Akonadi always broke .) Also, it’s not themed properly on Oxygen, but that’s not a surprise to me, unfortunately .