I love that implementation. I bounced back ideas with Marco long ago about this. I think we should implement it in all other KCMs with similar representations.

Does the hug allow for just a search button and a non-always visible search field?

I guess the way that the new theme is created through the ui is also something to consider. Maybe, let's think of a cleaner theme editing process and then the save button will be easier to understand?

Would anyone in our community be able to create a script for localization?

In D18419#400112, @ngraham wrote:

That's good to hear! I'm glad we're on the same page. Let's make sure our plans in T8871: Systematic KCM reorganisation reflect the consensus of a diverse set of opinions so we don't wind up needing to re-do it in the future.

In D18419#399881, @abetts wrote:

In D18419#397699, @ngraham wrote:

I'm trying to get a sense of when we should do this.

1. Improve text on existing QWidgets KCMs to conform to the HIG
2. Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG
3. Port all QWidgets KCMs to QML
4. Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))
   
   Between which items should this re-org be located?

I my mind, it would be #5 since we know that through the porting and improvements we make to the kcms, we end up making them look vastly different, in some cases. This makes it so that a KCM doesn't really belong to the same category anymore. We also discovered that we have a few KCMs with just a couple of options that would make them move to a new category. That would change the organization again.

In D18419#397699, @ngraham wrote:

I'm trying to get a sense of when we should do this.

1. Improve text on existing QWidgets KCMs to conform to the HIG
2. Re-arrange weird layouts for existing QWidgets KCMs to conform to the HIG
3. Port all QWidgets KCMs to QML
4. Merge various KCMs together (e.g. Icons and Emoticons, Widget Style and GNOME Applications Style (GTK))
   
   Between which items should this re-org be located?

Do you prefer a right click over a settings or 3-dot button?

It's amazing to see all the work that was done here. Thanks everyone for working together on this. I hope our users see this new KCM as a step forward.

+1

I am not opposed to a reorg as long as it doesn't touch the KCMs, but be aware that you "might" have to reorg again as we port KCMs. So, do you prefer to do it, potentially twice, or just once?

+1

+1 <3

+1

Hey all, sorry for not showing up earlier in this ticket. I wanted to offer visual direction for this change. Here is the mockup I conceptualized for this kcm.

+1

In T10325#173189, @ngraham wrote:

In T10325#173187, @abetts wrote:

This really feels like a visual regression to me. I vote no on the design. I think we are trying too hard to accommodate to this idea and it is not working out visually. The wallpaper choice depends on the user, if the user feels that the image doesn't accommodate to the login design, then it's their choice to change their wallpaper.

Design accommodates the user, not vice versa.

We are doing this for the users, not to show off our fancy design. If our design generates user complaints and doesn't work with the thing that is most commonly changed (the wallpaper) I think the design not a success. With the current design, we've gotten many bug reports and user complaints. First about the ugly blue background, then about the fact that contrast was poor with many wallpapers, then with the fact that the blur makes their chosen wallpaper unintelligible. When we try to solve any of these issues, it only creates new ones rather than actually solving the problem. Additionally, right now the login screen has no structure and grouping as a consequence of not putting things in a box. The elements all feel disjointed and disconnected, especially the ones jammed into the bottom corners.

As a result, our designers want to endlessly redesign it, which is a sign that it's not the right design. When the design is correct, designers spontaneously stop wanting to redesign it. I've seen this over and over again.

I just don't think the current design works. What we had before in Plasma 5.7 and earlier was better IMO--and notably, it put everything in a box to ensure contrast with arbitrary backgrounds! I wasn't around back then, so maybe you have the missing context: what were the user complaints and unsolvable problems that the Plasma 5.7 and earlier login screen presented? Why did we throw it away and replace it with the current design?

I agree with @ngraham here. I feel that it is not always wise to apply the same UX everywhere. It might feel right but there are user experiences that are common place for other systems and it could become distracting for the user to expect one thing and such thing behaves too much outside of that expectation.

In T10325#173186, @ngraham wrote:

In order to always work with any background, I think it's unavoidable that the UI elements need to be placed on top of a window, box, or frame of some sort. It can look sleek and modern, but we shouldn't have the elements floating above the background with nothing underneath them and nothing to provide grouping and structure. Most themes already do this, including the most of the ones available via GHNS.

Some examples:

+1

Is there a way that the custom date setting can be in its own window pop up instead of building into the KCM and pushing down the control that's below this setting?

Do you have a before and after? :D

In D17975#388981, @filipf wrote:

I have some concerns about this. Mostly it's about visual consistency and notifications having different padding than other plasmoids. Notice how there's currently more or less equal distance to the left of Audio Volume and to the left of the album cover icon?

Wouldn't it be better to somehow add padding globally?

Plus, some desktop themes already add padding, which would make their notifications look bad. Can you test with some other desktop themes?

I like the selection so far. Just ping me when you need an official approval.

I think part of the reason why this seems too big also if because it doesn't do much more than tell you what day it is. If it was able to integrate with a calendar application, it could show appointments. Something like this:

(May I suggest a visual preference? What if the buttons were black by default? I feel that because of their color, they seem odd for a control on a video camera. https://dribbble.com/shots/5673516-Day-32-Made-with-Studio is an example of what I mean. The controls are less obvious to leave the user to focus on the image they see)

Kate and Kwrite seem very similar. Would adding a differentiator graphic help? For example,

How was this not an option ever?

In general these banner images were a good idea but their execution wasn't great. They take up a lot of space and the background are generally dark.

Do you have a before and after gif or video?

If you want, you can go to the KDE VDG Channel and request some design help as you go along. The app is shaping up nicely.

In D17934#386077, @ngraham wrote:

In D17934#386060, @abetts wrote:

If those are the constraints, we can keep it as you propose, I would only make the computer information a lighter gray

It's already a light gray; this patch is proposing to make it the same color as other text.

In D17934#386060, @abetts wrote:

possibly the same size font as the username, and I would make the username label bold or a heavier font weight.

That would require a change to the Heading items since we shouldn't be overriding weights here. E.g. with D17906

FWIW I would support that since I think bold text in headings is conceptually correct and looks good.

In D17934#386059, @ngraham wrote:

In D17934#386058, @abetts wrote:

I can understand that. Are users able to copy the information that displays on hover? If so, that would be one way to get the information you need and at the same time not replace labels?

No, the information is not copyable. It could be selectable, which would make it copyable. But this would be a new feature that should go in a new patch. :) And I wouldn't want for this string to just be always elided.

In D17934#386057, @ngraham wrote:

In D17934#386053, @abetts wrote:

What do you think of having this combination;

USERNAME (dev@pc, etc, etc, etc)

On mouseover, just make the rest of the description appear to the right of the username label INSTEAD of replacing the USERNAME label with the pc information. It will take a little bit more space but might seem more streamlined visually IMHO.

I tried that when I was redoing the header last time. It doesn't work because usernames, computer names, and operating system names can be very long, so in practice something is always elided.

In D17934#386050, @ngraham wrote:

The opacity change makes sense to me: since this text isn't visible by default, there's no reason to make it difficult to read with a low opacity. If you go hunting for it and want to see it, you want it to be readable!

The alignment change I'm not as sure about. Because the username and information label are different sizes, I deliberately used bottom alignment to avoid having the system information label appear to jump up when hovering on it. With your change, the jumpiness is re-introduced:

Thoughts/ideas?

In D17874#385859, @anthonyfieroni wrote:

Video can't handle it. (i've think about screencast but can be recorded by a phone)

Laptop at this configuration, screen brightness < 100%, waits more that 10 min inactivity, plug-in adapter will wake-up screen with brightness at 100%, which unwanted especially at night hours.

Can you pleas provide a video showing the annoying behavior? Just to make sense of it.

+1

I don't have a problem with the font as much as I have a problem with the spacing for the title labels. They seem to be super close to checkboxes, other labels and controls. There should be a clear separation. Adding a heavier font to the title label helps a lot but because of its weight and the closeness with the rest of the elements, it seems crammed.

+1

Love it! IDK how it wasn't implemented already!

I support visual alignment!

Goodness, I think this is all about taste. I am more on the side that it looks good. It visually prioritizes hierarchy with labels. @mart Does it just look bad for you or do you think this will cause issues somewhere else?

+1

In D10083#384946, @ngraham wrote:

This is obsolete now since the button layout was recently made consistent across all KCMs (we put everything on the right). You can Abandon this.

I like the idea and if we select wallpapers we must provide quality wallpapers that fit every screen well.

The labels and checkboxes are not starting with a verb. I think that can be reworked.

Screenshot?

+1

+1

I have seen implementations like this one before and it makes it so that the tab expands and shrinks when the focus is on the tab because it needs to accommodate for the icon that appears and disappears. Is that the case with this patch?

In D17751#381351, @ngraham wrote:

Gotta fix the shadow appearance before we can land this.

If we consider where the light is actually coming from, probably we need for the center part to cast a shadow too.

In T7927#170776, @rooty wrote:

In T7927#170720, @ngraham wrote:

I still don't see who this wizard's target user actually is. Someone who's a font nerd doesn't need or want a wizard, while a layman or casual user will never, ever change these settings, especially if we set a good default.

Anyone who's working in design and/or publishing (and doesn't like ClearType or Apple and their vendor lock-in), isn't tech savvy and is seriously considering Linux as a publishing platform would benefit from a simple font changing wizard.

Windows still butchers fonts geometry in hidpi (they're just bigger so it's less noticeable), and Apple changed the AppleFontSmoothing setting around the time the 2012 MBP retina came out so that if you want low dpi font smoothing to look presentable you have to use 'defaults -currentHost write -globalDomain AppleFontSmoothing -int 3'.

And there's the ClearType tuner argument as well.

Sorry guys, this request here does not seem to have good grounding. I agree with Nate. Can we re-evaluate? More than anything, I would need to see a clickable prototype of the proposed interaction with this wizard. I haven't seen anything yet.

abetts
It is easy to reproduce when more than one monitor is connected, you must set the cursor on any monitor except the first one and block the screen with hot keys, after which you will notice that the focus of the password entry remains on the first screen.
This problem may be associated with the bug 395639.

Can you show a video or gif of this behavior?

Could you maybe provide a video or gif of this behavior from the other OSs? Just for reference.

In T9830#170541, @ngraham wrote:

Let me get specific about this proposal.

We pput a new setting in the workspace KCM:

Application Menu location: (o) Beneath window titlebar
                           ( ) Window titlebar button
                           ( ) Panel at the top of the screen

Clicking the second radio button would add the appropriate window decoration button to the titlebar, on the left side.

Clicking the third radio button would add a new panel with a global menu widget in it to the top of the screen.

The window decoration button and/or panel would likewise automatically disappear if a different option was selected. In the case of the panel holding the global menu plasmoid, we should probably remember any panel customizations and additional widgets that were added to it, such that if the user re-enables the global menu option, the old panel will re-appear, including all the customizations they made to it.

The setting would immediately affect all apps.

Thereafter, the per-application options to hide and show menubars could be removed, because the options to have a more space-saving menubar would be more discoverable.

In D17073#378898, @trmdi wrote:

How about this? I'd send a new patch if it's possible to change 2 things in one patch.

Not sure, what seems to be the main issue?

+1

Thanks Dave!

+1

In general, this patch makes it better. However, I feel that all the items are simply too close to the left edge. Can you add some padding or margin to the left? Maybe something like 5 px?

+1 for improving visuals

+1

In D17346#375165, @broulik wrote:

No. Can we not digress from this, I just need an icon...

+1

Can the section title be called something different instead of using the word "Component"?

Maybe not applicable to this patch, but would we consider making the battery color in the progress bar to be green? Green seems to be very standard to mean charge. We are using blue.

Thanks Dave!

It's looking good. I would say change the last tone to a tad lighter. The gray has too much black in it. I would probably move the hue to the yellow side.

I would probably not make the button that big, but I think it is useful

+1

Love it! +1

+1

I would even go as far as changing the left column where the icons are to some other color too. However, I think this is sensible. It breaks monochrome glyphs that can be confused.

If this patch deals with the UI, is it possible to align the eject button to the middle using the progress bar as the center?

Thank you!

+1

Would you want to move the General section to the top and plugins second?

Instead of connection name, would it make sense to call it, network name instead?

+1

+1

In D17192#368170, @mart wrote:

well, to me part of the problem is that a title became a back button... even tough smaller target to hit, i would have preferred to have a toolbutton followed by a proper title that is just a title

In D17211#368161, @ngraham wrote:

Thanks, the combobox open-on-click feature works perfectly!

I still don't agree with making the wallpaper plugin GHNS button icons-only. That makes it inconsistent with all others in every other KCM and I took great pain recently to make them all consistent. Can we put it on the bottom row with the other one and restore its text?

+1 on visuals

What would this look like in practice? Before/after?

In T9658#169034, @ngraham wrote:

Probably soon-ish I hope! D16031 is ready for review again.

Will we ever be able to land this? :D

In D17220#368147, @trickyricky26 wrote:

I think the distinction is useful. The off icons would then look like this:

Should this style then also be applied to other "off" status icons like touchpad and camera?

Also, I've experimented with a circle with one line through it, as that represents muted better than an X which looks too much like an error:

In D17212#368048, @mart wrote:

I don't really have an issue with the font alignment. I think where I am conflicted is the part where we want this text to have too many purposes. The label is big so as to mean that it is a page title. However, when we place this on a phone, the header text is huge. So the label is trying to be a page title and a breadcrumb. I think that we should rethink the size, at least. The alignment is great.

+1

+1

Is having this feature an optional feature? Can it be turned off?

In D17073#366588, @ngraham wrote:

Staring at these screenshots again, it occurs to me that the artist and title are unnecessarily repeated in the current UI: once right under the app name, and again towards the bottom, on the transparent bar. We can probably get rid of one of these to scrounge up some more vertical space for the album art.