Don't worry: After many years working as a usability consultant and UX designer, I know that I have to distinguish between my own needs and user needs.

In D7905#147514, @jensreuterberg wrote:

The hamburger menu was my suggestion so I should probably say something about it - for me the "launch" option is completely meaningless fluff. Another button to nothing. That being said, if this is something critical in normal usage then it should be in there - and as we have no chance to do a proper test of it doing what everyone else is doing might be preferred.

Why don't we simply copy the Firefox dialog?
Firefox has a big userbase and with the default settings, the vast majority of users will see this dialog at some point. Therefore if their wording was problematic, it's very likely someone would have flamed them for it.
So I'd consider their dialog "real-world tested".

In T6842#107369, @paulb wrote:

To me this "together" is what makes KDE unique.

So something like:

Building Freedom Together

@bshah The "Halium Unifies Mobile Linux" section of the article "Plasma rocks Akademy" [1] seems to cover the things you mentioned above.
Do you feel that what should be said about Halium has now been said, or are there more things that should be promoted about Halium?

In T6842#107293, @paulb wrote:

The answer to that is share.kde.org (our Nextcloud installation).
The cleanest way to do that is to ask sysadmin to create a shared folder there along with an Identity group that gets access to it and contains everyone in this project.

Since Piwik can already track if people come to our articles from social networks, I'm not sure if URL shorteners provide us with any additional information. They don't track things like number of followers or number of likes or reshares anyway.

Final edit from my side:

Final tiny nitpick:

Sounds really good!

Okay, to be honest: I don't fully understand what you guys are talking about ;)

• Is the mouse-driven workflow mentioned here new in Plasma 5.10, or is it so hidden in 5.9 that I simply cannot find it?
• Where do these shortcuts come from, where do they already exist?

It definitely should not be an option. Either it's better, then it goes in, or it isn't, then it doesn't.

Who has complained about this? Can we see the reports?

If it's most likely to be decided only on the distribution level, we don't necessarily need a GUI for switching it, do we? We could also just have it as an unexposed parameter in the config file.

2.1 MB, much better! :)
The cover page looks like has some compression artifacts in the text. Is it a bitmap which has been compressed?
If so: Would it perhaps be possible to use a different format for it which can be shrunk to a usable size without any loss?

Looks good, but why is the PDF 55MB big? There must be some gigantic images in there...
That would make it quite heavy to send via email or for people to download...

Version 2 (top toolbar, no colors) looks the best to me, with the downside that the install button does not stick out. If we go without colors, we'd probably at least need an icon for the install button to not make it totally blend with the rest.

@paulb @skadinna To avoid such editing conflicts, I'd recommend either using notes.kde.org, the Collabora Online on share.kde.org or if it's a more complex plain-text document even creating a Git repository (there might even already be one for promo, I'm not sure).

Final comment: Do whatever makes sense, keep only the context menu if you like. I'm out.

In D4838#91404, @Fuchs wrote:

In D4838#91286, @mart wrote:

i don't see the split button a very feasible option on a technical standpoint (and pretty bad purely on aestetics, would also be a thing we use only here and visually clashes with a combobox)

Okay, personal opinion on why split buttons are among the most horrible things related to UX:
(And whilst some of these points might not apply to this very specific use case here: they will elsewhere, and once one component users this button, others will too, see e.g. spectacle)

• They are very prone to accidental clicks. If you want to click the (little) arrow but hit the button instead, worst case you get an undoable, destructive action. This gets a lot worse with touch.

In D4838#91009, @subdiff wrote:

I thought of something like this:

Is this in line with the HIG?

In D4838#91004, @broulik wrote:

Just as well or as badly as a regular "Open" button. If in this scenario you hide the Open button because it has no valid target, then of course there would be no split Open button, either.

So, how can I access the menu options for the invidiaual files, here?

In D4838#90994, @broulik wrote:

A file manager has a menu bar, however, so the context menu is never the only means to execute an action.

Dolphin does not by default. I don't see an "Open" or "Open With" action anywhere in its menus, neither the file actions (compress, activities, send to, etc).

You don't have that in a file manager, either, and this thing represents a file.

even Windows and Mac have deprecated them in favor of persistent notifications!
Not only it's already implemented, but also it is what every major desktop and phone OS out there already use!

I agree that what Android does makes a lot of sense. What they have is

• a permanent icon in the top bar for each application that still has an open notification - basically an SNI, minus the direct interactivity (which makes sense given that tiny icons are not much fun to interact with on a touchscreen)
• a drawer that shows all notifications that are still valid (plus the same on the lockscreen if enabled)

I'm all for the change, obviously ;)

+1 from me, with clicking on a notification that does not define a default action doing nothing

Since there does not seem a clear "best solution", isn't this something that should be decided on a cross-desktop level?
After all, it's not just about what users expect, but also what app developers can expect to happen with their notifications.

In D4215#78928, @mck182 wrote:

If you just want to close then you have the big X, no?

That doesn't change the fact that the behavior of clicking the popup itself would change in an unpredictable way. One time it's close and other times it's execute and there's no visual way of telling when it will do what. That's the actual problem.

>>>! In D4142#77861, @colomar wrote:

Hm, that's not easy to decide. Whether one likes the "click to make go away" behavior or not is highly subjective. I, for one, find it very annoying on e.g. OS when a notification covers something I want to see on the screen and there is no way to make it go away other than waiting. Others find it annoying to have to explicitly click a button to execute the default action.

Same thing: the framework giving access to this feature doesn't mean your app has to use it. Even more: it doesn't even change the behaviour in Plasma! In Plasma the default action will still appear as a button unless we change the plasmoid. This will, however, make it possible to use this feature on desktops that do support default actions.

Hm, that's not easy to decide. Whether one likes the "click to make go away" behavior or not is highly subjective. I, for one, find it very annoying on e.g. OS when a notification covers something I want to see on the screen and there is no way to make it go away other than waiting. Others find it annoying to have to explicitly click a button to execute the default action.

Yes, that is certainly a downside. One idea could be to move it into a submenu if there are more than X entries (though I'm not sure yet which number to choose). The downside of that would be that people who often add and remove places might get confused by the context menus jumping between submenu and no submenu

To solve the problem of the context menu getting very long: How about putting the places in a submenu?

We always have to keep in mind that usind multiple layouts is an advanced feature used by a minority of users. Therefore, as long as a feature only becomes active when there are multiple layouts (and in this case only when multiple layouts are used _and_ the login failed), we do not need to worry too much about UI clutter.
For that reason, I don't see mich of an issue with the patch.

Sorry for not replying earlier.
While this proposed behavior might indeed not be expected by everyone, this is not really a problem: Those who would not expect the wrap-around behavior would not expect anything to happen at all, and therefore not even press the shortcut if they are at the left-/rightmost window. If they do press it anyway (maybe by accident), they might be surprised at first, but it will be easy to them to get back to where they were before, and then they can still decide whether or not they want to use the shortcut in such situations in the future.
So, long story short: The benefits clearly outweigh the risks here, so +1 for the patch from the usability side.

Yup, makes sense!

Great improvements!
Is the desktop / Activity only shown if

• there are multiple ones and
• the task manager shows tasks from different ones?

+1 for the patch (I don't think the icon is close enough to the login button to be problematic)

I'm sorry that I have not commented earlier, I blame it on an overflowing inbox :-/

+1, definitely looks better to me (and Jens will love any killed animation, anyway ;) )

Really nice!
The single thumbnail might be a bit too large, as having large notification windows pop up could be irritating. Maybe half the size would be big enough?

I haven't had the chance to play with it and I think we should still have a plan B if we get negative feedback on it during beta tests, but the concept as it is described in the latest comments makes sense to me.

In D3210#62062, @mart wrote:

Whoa okay, that is complex...
Given that I failed to understand what the proposed checkboxes were supposed to mean, I fear it will be the same for users.
Therefore maybe not gibing the option at all is indeed the better solution, and your suggestion to turn the feature off when animations are turned off makes sense to me as well.

Great feature!
I just fear that the naming scheme might make it look like the device name is the name for the port, like "A microphone called Audio Adapter".
Maybe naming
Port (device name)
would make it more clear?

Very useful patch!

In D3210#60963, @hpereiradacosta wrote:

In D3210#60602, @mart wrote:

in this latest version there are 2 checkboxes: "show scrollbar only on mouse over" and "small scrollbar" which both defautls to true

If I understood it correctly (that there is only a checkbox "Only show full scrollbar on mouse over" added to the config) then that is exactly what I had in mind.

It does make sense to me to give the option to turn the slim scroll bar as such on and off. I can imagine some people being uncomfortable with the animation on mouseover.
Being able to configure individual parameters is probably overkill, however.

Our users will be very happy about this being back!
I agree that there needs to be some way to access it via keyboard. Pressing alt to shift keyboard focus to the menu bar sounds like a good idea, if pressing alt again shifts it back to the window content again.

Sorry for not replying earlier.
There is nothing that speaks against offering this context menu. However, all the actions in the context menu must be available in the main UI as well. Due to discoverability reasons, context menus must never be the only way to access an action.
So, this patch is good to go, but there needs to be a way to do these things without the context menu as well.

+1 for the change!
I think the string for failed unlock while capslock is on should be "Login failed (Caps lock is on)" though, as the "login failed" part is the more important one.

Also it really needs to be a config option somewhere. People do multiple login. We made LightDM reuse sessions and got tonnes of comments.

Definitely a good change!

Behavior sounds sensible, wrapping around would make sense, though.

On the other hand, we could open in the overlay mode for the single connected display when there's only one screen. When another screen gets attached, we remove the overlay and show the overview with positioning. I haven't made up my mind about that, but maybe it's a viable option down the road, so that's just a first shot.

@mart The upside of that would certainly be a clean appearance, but the downside would be that what sebas described as a typical usecase - You only have one screen and want to change its resolution - would then be two clicks instead of one.

I've updated the main mock.
Changes:

• Disabled displays are now in a separate box. Rationale: A disabled screen cannot ever be part of the screen setup anyway
• Rotation is now done via rotate left/right buttons
• Setting Primary display is done via positioning it in a box in the center. Rationale is that in most cases, the primary display will be in the center of the physical setup as well. Of course one can decide to e.g. only put further screens to the right of the primary screen if one does not want the center screen to be the primary one
• Advanced section removed
• Refresh rate setting removed, is now integrated in resolution

Perhaps the best is to show all resolutions, pick the max refresh rate for a given resolution (the current "auto" setting), but warn the user that this mode has a low refresh rate and advise to pick a lower res with a higher refresh rate? This would allow users to shoot themselves in the foot, but makes it a bit more intuitive to pick what's sensible for the eyes.

That could work, but it needs a conscious choice if we allow the user to set up a sore eyes config (high res at low refresh rate).

You say it matches the mental model, but I don't think that's actually the case: you normally drag the screens in the KCM to match how they're on your desk, not "create a large virtual display". To me, the fact that I could even put displays on top of each other wasn't evident until I fixed bugs where this case happened.

On the top of resolution vs. refresh: Yes, there's a clear case where this matters. Graphics cards support a maximum resolution at a specific refresh rate. If you lower the refresh rate, you can get higher resolutions (and sore eyes), if you decrease resolution (possibly below the display's native res), you can get higher refresh rates. They're really inter-dependent. (Think of the product of number of pixels and refresh rate, that's the maximum bandwidth the graphics card can push to the display.)

As to scaling the kscreen kcm ui live while dragging ... I'm not so sure about it. It does sound neat, but it also bears the risk of UI bits falling outside of the screen (and thus input area), window being repositioned (if we choose to do so), and at the very least the slider control slipping away under the mouse. Sounds like a nice idea in theory, but it has so many problems attached to it, I'm not sure we want to go down that route.

displays on top of each other is a perfectly valid case, also with different resolutions, so I'm not sure this would

• work well
• be discoverable by users

Thank you for the feedback! Let's see...

I have added a mock of a redesign proposal (wireframe status).

I've just asked the other VDG members for their take on the font size.
Since this is not a big issue either way, the patch is fine to go in anyway.
If the VDG decides we'd like the font to be smaller, it would be nice if it could be changed in another patch.

In D2753#51248, @broulik wrote:

Because that's an idea Martin and I had a while ago iirc. And also I don't see how we could make this one scrolling page, since it's a QML thing with a ScrollView embedded in a widget environment.

In D2753#51234, @mart wrote:

as far i know the guidelines for new kcms are no tabs?

There is always still the possibility to use one of the Action Buttons as a close button (as shown in the Gallery) if it gets too long to easily swipe away.

There is always still the possibility to use one of the Action Buttons as a close button (as shown in the Gallery) if it gets too long to easily swipe away.

In D2383#50991, @andreaska wrote:

ordinary I had more often the problem that the notification stuff is empty but I'd like to know what happend in the past.

most of the time I see no new notification but I'd like to see the old ones (5.7.4) maybe 5.8 change this behavior

In D1771#50973, @broulik wrote:

Can we have something more concise than "Visual feedback (On-Screen Display) for status changes not triggered via a graphical user interface". Perhaps just "Visual feedback for status changes"?