Sun, Jan 19
Welp, this is done now!
Sat, Jan 18
Fri, Jan 17
Thu, Jan 16
Wed, Jan 15
Tue, Jan 14
This is happening; see the linked patches. Here's what's happening:
- On the desktop, scrollbars return to their prior thickness and are always visible in a separated track regardless of the toolkit (QTWidgets, bare QQC2 on desktop, Kirigami on desktop
- On mobile with Kirigami or bare QQC2, scrollbars are always overlay style with no layout hacks, which means they can cover the content while in use. When not in use, they flatten out and hug the edge, remaining (barely) visible to serve as an indication of scroll position without getting in anyone's way
Mon, Jan 13
However clearly Latte's genesis was for people dissatisfied with the default appearance and functionality and wanting more control and a better look. So it makes sense that it targets tweakers and ricers. If Latte were to become the default panel solution, clearly it would be adapted to become more user-friendly for the default and productivity users.
There's another category of user you're missing: the productivity user. This person uses their computer for work. This person may or may not be a technical expert, but they know more about their computer than the novice. Because this person's computer is a work machine, they have better things to do than tweak things. This person is sensitive to good defaults and wants to be able to turn on the machine and immediately get to work. They may customize some things, but the customizations are more likely to be functional than visual. Because of this, if they go to customize something but find a huge number of visual tweak settings, they will get frustrated.
-1 from my side. Latte is awesome for a ricer who want to customize is desktop, but for the average user it isn't an improvement over Plasma. Anybody who want to use Latte can easily install it from Discover.
Okay, I think aside from Windows and OSX, we already have most major DEs and keyboard-driven environments here, and it's been a while since we had input from other people. Part 1 of section Tasks to be done in order to achieve this is already quite significant. I'll continue working on that, but that does not hinder discussion here, to be clear.
Thu, Jan 9
Thanks for the support, I quite like it too. :)
I'd like to argue a bit in favor of the vertical panel. With widescreens being so prevalent and even wider ones on the horizon (ultrawide) it makes little sense to take up the horizontal screen space with the taskbar.
On the other hand if you have a browser open, even with 2 windows side by side most pages aren't wide enough to use all the screen space, so a taskbar fits in there as well.
Plus it gives you enough room to make the icons a little bigger and to have 2 smaller icons in the notifications area side-by-side.
Please, push a commit to fix the headers. See https://binary-factory.kde.org/job/Website_hig-kde-org/157/console
Wed, Jan 8
Tue, Jan 7
I've landed this for you in https://cgit.kde.org/websites/hig-kde-org.git/commit/?id=ad3d052e47f0d24f0548bd14cff2749345ea5968
Apparently I am not that important :(
Shipit! Do you have commit access for the HIG repo?
Mon, Jan 6
Done, I'll leave it to the VDG/consistency goal to be sure things match.
Ok, will update.
Having played with it a bit, I agree with @sefaeyeoglu here. Reversing them from what's currently proposed feels nicer to me. Things enter faster, which is ultimately what you want for things that animate from invisible to visible.
Fri, Jan 3
As mentioned in D18000 I think the following two things should be adjusted. I think it is more natural that way.
So I'm not getting a ton of love for the vertical panel idea, which is fine; it's not a critical part of this proposal. Windows uses a horizontal IOTM and the entire world hasn't caught fire yet.
Thu, Jan 2
Since Windows itself now defaults to an IOTM equivalent (since Windows 7), and most office workers who have multi-screen setups are using Windows, either an IOTM isn't actually a problem for this use case, or else people with multiple screens are probably the kinds of people who can configure their workspaces for efficiency and aren't impacted as much by the default settings of their OSs.
@esokrates, I think that's a good idea. It does make sense to me to be able to collapse it even further. This would make a "Hide Sidebar"-button in a toolbar even less necessary. So consider it added to my proposal.
Could you please add hiding the sidebar altogether to the proposal? If you go that expansion path, further collapsing from the vertical could lead to the sidebar being hidden altogether with only a slight visual hint that there is something that can be expanded (like the libreoffice sidepane).
There is no workflow that fits all, but we can make educated guesses about the workflow that fits most (this is the point of defaults, after all). As I mentioned in the description, I think the reason why this makes sense is because most users today have an app-based workflow moreso than a window-based workflow. This is due to the changing nature of how apps work today: more and more are single-window apps, with integrated tabbing features for working with multiple documents/views/emails/whatevers. I'll admit that this is a bit of an educated guess on my part, but it's based on observations of the functioning of apps used by me and others I know, and I think it's notable that every other platform has switched to a Dock-style paradigm. Clearly they all thought there was some advantage.