As trying to con ubiquity into using a local test file just seems to crash it, I pushed my draft exclusion list to the seeds to allow testing with images spun by the ubuntu infra.

Ok. My first draft.

Yep, landed in Frameworks 5.45. So if we want to do this, and we don't ship with 5.45, we'll need to cherry-pick that patch.

Landed?

Now in the archive -release pocket

FW 5.44 is uploaded to Bionic 18.04, and is going through autotests.

Works for me. Uploaded.

Giving up as a bad job.

This should be added to and re-checked.

Launchpad tracking bug: https://bugs.launchpad.net/ubuntu/+source/digikam/+bug/1756136

Patched 5.6 building in: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc

Yup, the issue seems to be fixed now with that ISO!

In T7981#132629, @mparillo wrote:

Fix verified:

Fix verified:

Looks like we managed to convince virtually everyone in T8187: Single click vs double-click that Double-Click is a more appropriate default for new KDE users. That was an upstream discussion, so I think we're pretty safe doing this for Kubuntu (not that upstream should care anyway).

Network connected without double password prompt via Ubiquity and from the live boot panel icon (rebooted to test both). All secure networks were correctly marked as "secure".

This part of the issue resolved at least. The full fix lies in casper I think.

In T8142#132000, @joselema wrote:

Hi Marco,

I couldn't reproduce the possible issues you have described. However, a test like yours, just adding backports-landing could be flawed (see below).

Is it possible I need to install backports first, and only then install backports-landing?

They are 2 possible upgrade paths:
a) upgrading from a 'plain' xenial installation, i.e. without backports
b) upgrading from a xenial installation where you already have backports, i.e. plasma 5.8.8 among other things

If you are testing the upgrade path a), and it seems to me that's what you are doing, the correct way to proceed is:

1. Add *both* backports and backports-landing via add-apt-repository
2. Upgrade you system, For instance doing "apt update && apt dist-upgrade".
   
   The reason to do this is that backports might have packages that backports-landing isn't providing, and that could explain that packages being held back.
   
   Regards.

Please join me in T8187: Single click vs double-click to continue this discussion.

Commenting here because this might set a precedence for all of KDE/Plasma and it touches one of the most fundamental UI principles present since the beginning of KDE:

Please test the iso here: http://kci.pangea.pub/images/iso_bionic_stable_amd64/current/

Change not made yet. The above is what changed in a local ~/.config/ dirs when I changed settings.

@raddison this change is not in relation to what is or is not better in overall usage, instead this relates to what is expected. If a user wants to have single-click activation then that is great and they can go into the settings and change it. The issue is a vast majority of people expect it to be double-click and that is why it should be default. It should be default because making people deal with customizing on the first day is a bad idea for on-boarding of users.

So if D11244 lands, then we can do this if we ship with Frameworks 5.45, or if we cherry-pick that patch into 5.44.

Just tested, and text does indeed look awful when a non-integer scale factor is used and PLASMA_USE_QT_SCALING=true is active. So that would be a regression for people who use non-integer scale factors.

Andrew, would you mind testing at multiple scale factors (including non-integer ones) and see if you can find any glaring regressions? I fear that at non-integer scale factors, we'll run into blurry pixellated text all over the place due to PlasmaComponenets Labels not using the right Qt Text rendering (see https://bugs.kde.org/show_bug.cgi?id=391691).

@raddison What about those of us that use touchpads? I have tap-to-click enabled (as pretty much everyone using a laptop on any OS does), and if I tap to select a folder or file in Dolphin for example, it will launch, rather than select it. Very annoying and confusing at first. Kubuntu is supposed to be the go-to distro for new users. New users are already adapting to a lot of other things with a Linux system, interface usability shouldn't be another one. This should be the same as Windows/Mac.

Yes yes yes! I had no idea about this variable. It fixes a bunch of icon scaling and spacing issues. Lots of people will still be using Xorg for a while due to missing features in Wayland (such as myself). Enabling this for them will go a long way to making Plasma look good on newer computers. The only thing I noticed that happened to me, was my panel reset it's width (it's on the left of my screen).

+1 for single click. An extra click does not improve usability. As a former Windows user, I had no difficulty to adapt to single click. As a matter of fact, I didn't use to double click even in Windows. With all due respect, I think this isn't one of the defaults that need to be changed.

Hi Marco,

Still present in the beta for me. I tried on teo separate pieces of hardware: an old crappy one, and a nice modern one. Both experience the issue when attempting to connect to a wifi network that is identified in the widget as password-protected.

If the problem is Kickoff (and Kickoff has other problems too unfortunately) then we might consider switching to Kicker: T7979: Use kicker by default for Application Launcher : Wait until 18.10; re-test

I'm currently on the fence with this change. On one hand it does make it look a bit better on rendering but on the other Kickoff does looks a bit odd in size with 11 vs 10. So the other options in the panel will look a bit off as well. This is nothing that the user can't change if needed.

Default system font sizes on other platforms, for comparison:

• macOS: 12pt (hardcoded and unchangeable, boo)
• Ubuntu Unity: 11pt
• GNOME: 11pt
• Windows: 9pt: far too small and too light and wispy; not something to emulate

I tried 3 different ways to reproduce on modern laptop (UEFI BIOS):

• panel
• during install from live
• straight to install.

Capser does:

From https://bugs.launchpad.net/ubuntu/+source/kwallet-kf5/+bug/1430426

• Update 34disable_kde_services to really disable kf5 kwallet and baloo
  • LP: #1430426
  • LP: #1431587

Rik confirmed in chat that he can reproduce the issue.

Done in plasma 5.12.3 packaging.

Pre-provisioning would involve casper I think. In the way that it changes defaults in a few other ways for our live session. e.g. screenlocker timeout and installer icon

Today's.

The live session has the new nm. What daily build did you try?

Still broken on the live session for me, I'm afraid: after you enter the wifi password in the network manager widget, a dialog box immediately pops up asking you for it again.

I just tried today's daily ISO and this is still a problem in the live session: after you enter the wifi password in the network manager widget, a dialog box immediately pops up asking you for it again.

+1 for Fade, I think it's much more pleasing and professional.

How about the Fade effect, then? It's a lot more subtle than Glide. I do think some sort of animation would be nice here.

Tested upgrade from stock 16.04.4 in a VM to backports, then bp-landing. Plus the same but in one go.

full-upgrade -y gave me 84 packages to update after the final XX release candidate. Looked clean in konsole. After a re-booting my VM,

This appears fixed now on the daily iso for me. Can others please confirm?

In T8116#131026, @valorie wrote:

mparillo, what packages besides Firefox would be excluded by your no-gtk rule?

mparillo, what packages besides Firefox would be excluded by your no-gtk rule?

I know I got push-back in the -devel channel, but I would like us to consider excluding:

With a +4 from KC and no objections, this happened.

+1

+1

In T8061#130145, @rikmills wrote:

That update is currently stuck in -proposed pocket, so it may be some time before we see that on our iso.

+1 from me too.

+1 for the removal of it.

In T8088#130548, @rikmills wrote:

It will still be in the archive and installable. Just not installed by default with the restricted addons package.

In T8088#130546, @franklin wrote:

Unless it can be available from old or other repository, I prefer to keep it until its EOL, since though fewer and fewer, there are still some important sites unable to work without it. Such condition is still serious in Taiwan.

Unless it can be available from old or other repository, I prefer to keep it until its EOL, since though fewer and fewer, there are still some important sites unable to work without it. Such condition is still serious in Taiwan.

+1 from yofel in IRC