Members of this project are KDE Developers and have the power to push to KDE source code repositories.
Tue, Feb 20
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.
Mon, Feb 19
@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 what elements the 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.
Thu, Feb 15
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
Wed, Feb 14
Thu, Feb 8
Thu, Feb 1
Agreed. These aren't needed systemwide.
The kcms are included in KIO but from my point of view they can be dropped
Jan 22 2018
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?
Nov 22 2017
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?
Nov 3 2017
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
Nov 1 2017
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.
Oct 31 2017
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
The grid with margins is the best IMO. It's the best use of screen space (and it looks better than the others) . I totally agree with the frame-in-frame problem (I wish dolphin looked more like your mockup!), but I think that adding too many lines can also end up adding visual noise.
Oct 30 2017
here an example of the view resized in two possible size, one which the thumbnail size matches exactly the available space for the number of columns, and another one that doesn't
margins of the white area always stay fixed, those around are flexible.
hmm, my attention is pretty much taken by the gap there and the step the two rows of buttons do...
perhaps if the row of buttons is still aligned with the others it would look better...
and if the margin around the view is not fixed, but whatever to make the white edges in the view fixed, it could have its why...
The Dolphin mockup looks good. But the KCM one looks somewhat confusing. Elements belonging to each other are not visually related anymore (the list view and the rest of the KCM). Maybe it's just because of the sidebar being white as well. But there is also the problem that not all KCMs have a list view, and then their design would differ greatly from the ones with a list view.
so, to explain the idea i had to reduce visual noise and the " frame in frame" effect, i did a quick and dirty edit in gimp of the window:
Oct 27 2017
Oct 26 2017
latest version of a grid based one
So for my own understanding I'm wrapping up (correct me if I'm wrong):
- Normally list views have a background (which is FCFCFC without any transparency or soft shadows at the borders as in the mockups) in Breeze.
- Current qqc scrollview though doesn't have this.
- So the question is if we should just ignore this background in qqc scrollviews or if there needs to be a version of scrollview with background so that it is like in the mockups and not different from other components.
Here's a mockup I made based on @mart 's:
Oct 25 2017
Are we opposed to using toggles like these? I have hear diverging opinions.
as far i remember the decision back in the day was to use those only on mobile, no idea if the idea may be reexamined now
any idea how to implement the mouse cursor selection size?
i was thinking about an icon, then clicking on it opens a small overlay popup with the choices, which is not super pretty, but ok
any idea how to implement the mouse cursor selection size?
I'll add a small shadow, hopefully will be easy to dynamically disable it when running on the software renderer
blur: another thing i would like to avoid if possible, as we need all this stuff to work correctly if possible also on very low-end hardware where we should render in software mode
Oct 24 2017
I hope it wasn't too difficult and I am already seeing an easier interaction with the themes. Even at this early stage.
early version of the cursor kcm