Totally agreed. A better way to explain the feature is also definitely needed here.

it would not allow 2, but rather n alterantives, since there are people who might have e.g. 3 use cases (all windows, all of current VD, all of current activity)

Thanks @Fuchs. Even if KWin doesn't support an arbitrary number of switchers, I think we should consider this "additional task switcher" feature to be for power users and maybe hide it behind an Advanced button or something.

Andy Betts, [07.06.18 06:20]
and yes, I was asking if you could help me track those KCMs where we introduced changes to the mockups

Andy Betts, [07.06.18 06:20]
Hopefully it is not a huge list?

Eike Hein, [07.06.18 06:21]
I'm not sure. I'd suggest going over the Phabricator KCM reviews (the ones I can think of right now: Language, Icons, Launch Feedback, Colors, Widget Styles, Cursors, etc. - maybe more). In terms of components, we have a new "Grid" style KCM and a new "List" style KCM and we figured out how we want to do draggable lists and we made FormLayout with its various abilities (reflow, clickable sections, etc.)

Eike Hein, [07.06.18 06:22]
So now it's about "If I had to do the design with these components, I would ..."

Eike Hein, [07.06.18 06:22]
So for example take the Keyboard KCM, which is now going to reuse the new "Draggable list" component/pattern we made for the Language KCM together - in the mockups, the Keyboard KCM is actually just blank, the mockup has no content

Eike Hein, [07.06.18 06:22]
There's probabl other cases where we didn't know the answer at the time, where we have a more solid idea now

Eike Hein, [07.06.18 06:24]
The process has been: Make initial mockups -> Consolidate ideas and come up with reusable components for consistency between KCMs and now it needs to continue with -> update mockups to reflect new components

Eike Hein, [07.06.18 06:25]
And this cycle will probably continue as we identify the need for new components, make them, ...

Eike Hein, [07.06.18 06:26]
Maybe @kbroulik also has an opinion here since he was one of the people who expressed frustration with aging mockups

Andy Betts, [07.06.18 06:30]
Oh this is good information

Andy Betts, [07.06.18 06:30]
Can you copy this into the ticket?

Andy Betts, [07.06.18 06:31]
Just so I can review after work?

Andy Betts, [07.06.18 06:31]
Please? :D

Task Switcher > Alternative (https://phabricator.kde.org/M112/390/) - What does this actually do?

I agree, the user doesn't know what to expect.

FWIW, I agree with @ngraham here, interactive elements should be visible in the view at rest. Buttons appearing on hover violates the principle of least surprise, makes selection unpredictable, and raises cognitive load.

I got plenty to do! Thanks Nathan.

I went through them all and I have the following observations and rcommendations:

@hein Can I ask to please list the changes we have decided on that require that I update the mockups? I know we have a few, but I am not sure that I know all of them. @ngraham Can you point those out to me as well please? I will work on a smaller KCM mockup subset to show the updates.

I had some comments about the date & time KCM mockup, I followed that up on https://phabricator.kde.org/T7248 as here has quite a lot of cross-talk

What KCM are your comments about @broulik ?

I wrote these comments on October 23rd, but they got stuck in a draft. I can't seem to delete them. A couple are still relevant though.

@abetts The font itself has already a preview in the font chooser. This is okay for me. What I meant to have a preview for is what elements a font is used for. For example it is a little unclear what "small fonts" is used for unless you apply the settings and try it out.
But I'm not sure how a preview for this would look like either.

I like those suggestions. I would probably not move the previous, however, since they are already loaded in a different screen. But maybe, what would be helpful is to use a menu that showcases the font in some way. For example, like this:

FYI, I was going to take on the clock for the next release. I've got some questions

Agreed. These aren't needed systemwide.

The kcms are included in KIO but from my point of view they can be dropped

I am kind of wondering if KDE needs to include the following KCMs at all:
T7302: Connection Prefs
T7303: SSL Prefs
T7304: Cache
T7305: Cookies
T7306: Browser Identification

I see your point, I am just afraid of the opposite effect: the general structure of current settings has even more mobile in mind that the proposed one. And as there currently is not much development on that side, I am trying to not let it slip out of the way completely, as this year could well be our last chance to jump into mobile.

I highly doubt that we will turn this work into a mobile app in the same way. We are not close to that discussion yet. Empty space works best in desktop. It allows people to focus. To cram every corner of the interface with a lot of data is also very challenging for finding your way. I can definitively review the margins. As of right now, we don't have a lot of work going into this project so I prefer to address this question once there is more development into it.

The mockups are nice, although there is a part I do not particularly like: all of them have a lot of empty areas, which means they are planned for big screens. By just scaling the pictures so that fonts had normal size, I get a window higher than my 15'' 16:9 laptop! :)
Also, I am concerned about those designs on mobile... Is the spacing supposed to scale? How would the 2-level drawer look on a phone? Could you picture those?

Could you maybe add a rough mockup of this suggestion? Just for more clarity. Also, we discussed some time ago that it would be ok for the "install" from file to be in Discover and that GHNS would "also" be in discover. What do you think? Should we do that or keep "install from file" in the same window where the themes are?

Love it.

as part of the work of other kcms which have a form layout, a layout component in kirigami which would be used for it https://phabricator.kde.org/D8641

Ok, the second stage of this redesign might be a little easier, it is aligning labels, shrinking comboboxes, and others to the center. Putting labels or "titles" on the 1st third of the space while the rest of the elements are on the 2/3 to the right. I will add a mockup to explain this.

let's do it!

ok, so let's make it final the "pure grid" one wit the version of the flexible spaces around the grid view.
we can then start with a mixed one and see how it works there

Thank you for your comments. @mart I have some mockups where this is the case and there is a mix of edge to edge content with other controls. I didn't think it looked bad honestly but feels a bit out of place. I can post something on it later tonight.

I have to say I'm not a huge fan of the screenshots posted at the top of the thread--the proposed total visual redesign. It seems like we would be throwing out a lot of work and all the embedded lessons learned and bugfixes accumulated over the years, and it looks like... well... it looks like Windows 10. :-( This modern depth-less totally flat interface trend is really not well suited for the desktop IMHO. It will look "stale" in a few years and we will be yet again on the treadmill of visual redesigns. My vote is for incremental improvement on what we've already got, which is really nice and has a timeless quality to it, like it's got more immunity to the UI fashions of the day.

well, there are two mutually exclusive designs at the moment which are being moved forward which should be chosen from, basically the last couple of screenshots and like last januz comment.
personally, i think my latest screenshot is the "easiest" to implement, but the other option (which i still don't know how to solve a bunch of problems) looks more modern

That's really nice, @mart.

I love it! Shall we move to the next phase?

actual implementation of the proposal with flexible lateral space