The KDE Community wrote:

You think we used Aero to make the video? Seriously?

AERO is the intellectual property of Microsoft. Only KDE e.V. can determine whether the use of AERO was appropriate or not under the given circumstances. I think the video is damaging the image of the KDE Community whether Fair Use is applicable or not. The video is well bellow the standards the KDE Community should be aspiring to. I couldn't believe what I was seeing. It's just my opinion. It doesn't necessarily mean that I'm right. I just needed to let you know what I think. I cannot emphasize it enough that this is not a personal issue in any way, shape, or form.

In T12444#217286, @linuxpusher wrote:

Please understand that the Windows users still on 7 are very likely to be quite averse to change. That means getting them to switch operating systems is also quite the challenge. Having a theme that apes the look of Windows 7 helps significantly with convincing them to switch to Linux.

Also IMHO casual consumers should be able to easily understand the concept of a desktop environment being separate from the underlying OS. Most of them are already exposed to Android, where the different manufacturer skins are analogous to DEs. Explain it to them like that and they'll get it fairly quickly; I've done that numerous times before and it has never failed yet.

https://youtu.be/TJzfaqRLfpY Windows is a full operating system, while Plasma is a Desktop Environment. Now sort out the confusion that has been created. Explain them that the underlying GNU/Linux is different to Windows.

@clel No, it was for Mike.

I'll be politically correct.

I'm sorry but I had misunderstood the purpose of the task. This task is about improving single click. Has nothing to do with double click. @ngraham My apologies.

Closing because the discussion here is probably not going to yield any more fruit. Let's focus on improving the single-click UX over time.

Agreed.

The motto of Plasma includes "simple by default" but this makes it not simple because people will be forced to deal with ...

It exists though https://community.kde.org/Distributions

What's the point of so much text? Bring methodological proof of which is overall better than the other. Leaning towards what the sheeple expect is populism. Please avoid the pitfalls of democracy or else democracy may backfire. The metrics only reveal that most people are not intelligent, hence not qualified to make decisions. I don't believe in elitism proper but voting is a skill and not a random intuition. The same applies here. Thank you.

You've got my blessing.

In D16031#373947, @filipf wrote:

In D16031#373904, @raddison wrote:

but I don't see why the lock and login screens should necessarily be identical in design

I do. The the login and lock screens should be visually consistent with each other. It's a no-brainer. How do we mitigate that?

It's far from being a no-brainer. There is a temporal and functional difference between the two screens. The user will spend only a very short amount of time within the login screen, whereas a lock screen may stay on the screen longer. The user will also use the SDDM predominantly just for logging in, whereas the lock screen is functionally more diverse - offers some control (e.g. media playback) over and insight (e.g notifications) into the machine.

Allow me to show an example: what is the point of having a huge centered clock in the login screen? It would make more sense to, for instance, jam it down into the newly created panel in order to simply have SDDM focused on what it's supposed to do: log you in. This is why some environments such as Windows, Deepin or GNOME don't have a big clock in the login screen, but have one in the lock screen; they were most likely thinking about conceptual differences instead of just advocating visual consistency solely for visual consistency's sake.

On the other hand, having a big clock actually makes sense on the lock screen if I'm working on something next to my computer and I want to check the clock.

I think I'll have to use Gimp. When is the deadline? :)

ngraham wrote:

but I don't see why the lock and login screens should necessarily be identical in design

@filipf Indeed. Thanks! @ngraham Clear sailing ahead!

... those who like it can use a forked 5.14 Breeze SDDM theme or the Chili theme.

In T9658#169679, @ngraham wrote:

In T9658#169678, @raddison wrote:

If they will work with what you're trying to implement,

What I'm trying to implement is a change to the default Breeze theme. It doesn't impact other themes in any way.

In T9658#169677, @ngraham wrote:

In T9658#169676, @raddison wrote:

My objective is a win-win situation not a win-loose situation. I don't want either of the parties end up frustrated. I favor mitigation over exclusion. The thing is all desktops that are popular and/or have a significant market share use blur at login one way or the other. Would it be possible for those who favor full-screen blur to easily tweak their login (say via a third-party theme), should the proposed login pass?

Yes, the login screen is themable, and there are already a number of attractive high-blur themes available.

My objective is a win-win situation not a win-loose situation. I don't want either of the parties end up frustrated. I favor mitigation over exclusion. The thing is all desktops that are popular and/or have a significant market share use blur at login one way or the other. Would it be possible for those who favor full-screen blur to easily tweak their login (say via a third-party theme), should the proposed login pass?

@filipf I think it looks great but the input box is breaking the guidelines. https://hig.kde.org/style/color/index.html

This patch adjusts the Breeze SDDM theme to remove the semi-permanently-blurred background, which has not been especially popular.

In D16031#368991, @ngraham wrote:

In D16031#368953, @raddison wrote:

I've also looked at the test plan and it's not exactly a stroke of genius if it looks like https://phabricator.kde.org/file/data/w3iyc7eov3ys6kmhrwi7/PHID-FILE-nya3nyqpjbmnijijvlwm/Screenshot_20181129_233236.png

You have two options:

• Stop insulting people and their work
• Go away
  
  Coming up with realistic solutions to difficult and controversial issues is hard. We have gone over a bunch of different designs and all of them have strengths and weaknesses. You are welcome to propose alternatives in T9658, but please do it with respect. Thanks.

In D16031#368865, @ngraham wrote:

In D16031#368861, @raddison wrote:

@ngraham Is it going to look something like that? https://phabricator.kde.org/file/data/zaerjwktbynwubnvu3ja/PHID-FILE-y52h6nwujyugxuqkc73z/maxresdefault.jpg

No, screenshots for the current proposal are in the Test Plan section of this patch. The image you're referring to was the old Plasma 5 design that was replaced in Plasma 5.8. I would support going back to that style of design because it solves virtually all of the problems here. But so far there doesn't seem to be a lot of enthusiasm for that. The

In D16031#368787, @ngraham wrote:

In D16031#368739, @raddison wrote:

Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

I think the same. Sacrificing the blur would result in dullness without any significant benefit.

Instead would it be possible to have a similar timeout for hiding the controls and unblurring as for the lockscreen (with visible controls and blur in the beginning)?

Yep, that would be great because it would result in a cohesive visual experience.

@romangg +1

I addressed all of that already: https://phabricator.kde.org/D16031#354282

I'm in favor as well :)

Still I find the original version with full blur and darkened background way better to read for many background pictures. I don't think it's wort it to sacrifice this usability factor to allow a better view of the background.

In T9152#162722, @jriddell wrote:

Breeze is maintained by Plasma and VDG teams

This task has become irrelevant. It's been fixed for quite a while now. Who maintains it then? Just curious.

Thank you, Nate.

Do you plan to share the answer with us?

In T8693#157894, @ngraham wrote:

Why don't you ask them?

@valorie Neon does not have apport. They say apport is undesirable. Do you have any idea why?

@valorie Cool! Thank you.

In T8693#157382, @valorie wrote:

In T8693#157223, @raddison wrote:

You also tend to formulate your words in an accusatory and inflammatory way that puts people on the defensive.

I intend no harm. Lower your shields :)

Then please stop accusing.

Another actionable path: purge all of Ubuntu's crash handlers from the iso. If users want them, they can apt install them. KDE strives for privacy software. Shouldn't Kubuntu as well?

As the release manager, I will not agree to this. Flawed apport might be, but it is *not* snoopware. In fact, I very much wish that Dr. Konqui would be expanded to allow kde-bug packagename as apport facilitates via ubuntu-bug packagename. This is entirely under the control of the user and make quality bug reporting easy.

Filing issues like this on phab without otherwise interacting with the Kubuntu team is counter-productive. We very much want increased interaction with our upstream KDE, which is why we have our Phab instance here. At least assign the issue to someone so that we can dialog. Just filing an issue without any interaction is like shouting into an empty room. Frustrating and exhausting for no purpose.

You also tend to formulate your words in an accusatory and inflammatory way that puts people on the defensive.

I have translated the Neon slideshow so I'm pretty sure the text is not incorporated into images. Anyway, making the text translatable is a necessity IMO. Non-English users will not be impressed by a partially translated installer.

reports suggest kerneloops is on the ISO

it must be frustrating for you too since you don't manage to get anything done.

Absolutely.

Surely there are more fun or productive things you could be doing with your time.

Correct.

Lol, Nate, you know what I mean. I had to formulate it somehow :)

In T8693#153830, @ngraham wrote:

What snoopware?

@oysteins Let us collaborate. Please post the text from all instances right here and I'll try to re-write it in English.

Actionable path: purge all snoopware out of Kubuntu.

In T8381#153814, @mparillo wrote:

Would that make translations more difficult? That is, instead of merely substituting text, images need to be re-created?

@ngraham Would you favor an all-image slide show, where text is incorporated into images (kinda like what Neon does)?

In T9303#153597, @oysteins wrote:

Raddison, please read the description again, and you'll see that I proposed to fix the full stop. And while I agree that other texts could benefit from polish, may I suggest that you submit that in a new task; this one is merely about these two sentences.

No space after full stop. Signing out :(

I'll look into it as soon as I get a moment.

It should all be re-written from scratch. It's way too verbose and contentwize meaningless. 16.04 actually makes some sense but 18.04 is awful. No offence intended but that's the obvious truth.

That wasn't my intention in the slightest but I'll still take your advice.

It should have been obvious as soon as the defaults were changed. That way upstream could have been engaged earlier or the altering couldn't have been delayed. It was an unfortunate happening. All I'm saying is that maybe we can learn something from it. Lol, I'm not blaming anyone. It was OUR failure.

Oh, c'mon! Let's not blow it out of proportions. I just stated my opinion.

It was a upstream bug indeed. Which should have been sorted out before and not after altering the defaults. So the order was all wrong.

A good example of why you should be cautious when changing upstream settings.

I trust that whatever you choose, it'll work for anyone *who knows* how the desktop works so +1 from me. Still, this task lacks any logical or methodological framework.

Whatever you like, but I can't shake the feeling that you're pushing your own agenda, instead of the wider community's. You're also implying that the user base is not very smart. I don't know who on earth coined this "new user" concept that is void of any real significance and it's just a a front-end for propaganda. The user is expected to learn how the desktop works and all these deviations from upstream defaults are not very smart. This is not addressed to anyone in particular. Changing some defaults won't make Kubuntu any better.

I think it would also be beneficial for Kubuntu to consult KDE's policies on data collection and telemetry. https://community.kde.org/Policies/Telemetry_Policy and find out whether Kubuntu is compliant with those.

Any news?

:)

The whole point of good defaults is that they should work well for the majority of people and use cases without needing to be changed.

VLC is a Qt 5 app, which is great. We should get in touch with the devs and propose them to package it with breeze icons. https://forum.videolan.org/viewtopic.php?t=145054

Since one can customize his/her setup, your proposal doesn't bother me at all. Different people are likely to favor one setup over the other.

Thanks! Now we investigate the issue and try to find a fix. :)

Rik is right. The best possible scenario has been chosen.

In Kubuntu 18.04, there are no scrollbar arrows in Firefox and it looks better that way.

Thank you, Nathan. It should be fixed asap.

:)

If I kill and restart plasmashell the behavior stops happening.

https://bugs.kde.org/show_bug.cgi?id=396247 :(

In T8604#149845, @oysteins wrote:

In T8604#149841, @ngraham wrote:

This was fixed upstream with https://cgit.kde.org/plasma-workspace.git/commit/?id=ee48796ec5561f540ed8b328a302e44b4364a234

FWIW I *can* reproduce this on Neon with Plasma 5.13.2, which should already have the fix you linked to. But I had to create a *new* Activity to trigger the bug (was not triggered in existing Activities).

@ngraham Like .pdf file that is downloadable from Kubuntu's site explaining in great detail what the packages mentioned in the task's title are and which are and which aren't included in the Kubuntu ISO by default. Just an example tho.

Kubuntu doesn't use ubuntu-report

@michaeltunnell Wouldn't you agree?

It's not that https://wiki.ubuntu.com/ErrorTracker is not documented, but it's not very obvious to the user base (if at all). Trust can only be regained by helping people to get rid of their misconceptions. Granting them easy access to information plays an essential role in it. I wonder how can this be done in Kubuntu's case.

I recommend changing this to "Enabled", and in the "Configure..." dialog, set "Sub-pixel rendering type" to "RGB" and "Hinting style" to "Slight"

Please report a bug rather than creating a task here for every small glitch/bug. That way, should anyone else happen to be experience the same, they can find it in bug reports, confirm and give more info.

T7618 Probably the root of the issue.