Are you suggesting we drop this?

Although it would be better to have the colorful icons, the e-papirus make them look in the menu. And it might be hard to maintain the .desktop in the different languages, if only we could "touch" some lines and not the whole .desktop.

I wouldn't recommend installation of nvidia by default, I believe it can bring us more problems than benefits.
I'm dealing with nvidia, still is a pain, manually had to blacklist nouveau and fonts appear very small apparently because of dpi miss lecture and and when xorg.conf is created back screen appear https://askubuntu.com/questions/1189311/ubuntu-19-10-nvidia-xconfig-makes-screen-black

@hmollercl update from the various upstreams? I think at the very least we can implement the changes to LXQt applications for everyone.

Flipping this to upstream since we'll wait for them and if it gets down to the wire, we'll do what @hmollercl suggests and take the git version.

instead of patching we might have to take a whole git version, there are to much commits from the last release. We should try to get a new release and establish a deadline to get it or do the git/patch

Ok, I made 2 changes to better match the whole theme. Changes are background color and selected. I put the same of the menu.
Please tell me if you like it to upload the changes to phab.

Thanks @rikmills for the assistance.

There is some good information in this forum thread. This is currently waiting on some upstream movement. I don't think the fix described is necessarily suitable for all scenarios.

Do we want to patch this or wait for a release? I personally feel like we shouldn't wait as a release may not come in time.

This moved to wishlist upstream we should probably follow suit.

However, this is how the in menu search looks with breeze dark, lubuntu arc, papirus-dark.

This could have some releations with the "redraw" of the menu. If you change a .desktop icon (directly not icon theme) or category it won't be notices untill you restart.

@tsimonq2 Why not just use the Xsetup and Xstop scripts to setup and tear down the guest user as outlined in the issue referenced in the upstream issue?

Another idea is that lshw maintains a GTK GUI that perhaps could be ported. It's pretty much all C++, too.

Doesn't our packaging module already do this? Perhaps this needs further explanation.

A quick update: 2.43.1 has been released upstream and there's a pre-build of 2.43 in proposed. It seems our fix is tagged in both so you could probably enable proposed to see if the fix is there. Oddly, I couldn't find it in the Ubuntu changelog, which is bizarre since it comes from the repo, but whatever. At the very least, coming soon.

I found out that with breeze qt style is quite easy to change between dark and light breeze color schemes
The color schemes are in: /usr/share/color-schemes
and to used one it need to be copied to ~/.config/kdeglobals
so this make the magic happen:
cp /usr/share/color-schemes/BreezeDark.colors ~/.config/kdeglobals
(restart pcmanfm-qt icluiding --desktop for it to be seen in pcmanfm-qt) and to revert erease kdeglobals or:
cp /usr/share/color-schemes/Breeze.colors ~/.config/kdeglobals

installed (again) on sony vaoi ultrabook using ISO 2020-01-17; (UEFI, full disk, NO-encryption, internet)
grub did not show; a couple of reboots & I couldn't get grub to show.

Installed today's daily (2020-01-15) on hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) (BIOS, full disk, internet)
rebooted; logged in (forgot to look at grub; was focused on finishing qa-test install)
sudo apt update; sudo apt full-upgrade; reboot

@apt-ghetto The new login button actually helps in switching users
Useful in our case as we don't have anything like gdm or kde's lock screen. Sddm currently lacks the ability to switch users.

Thanks @guiverc for testing, closing this task now.

Clone the master. Create a patch from the PR. Apply it and then build and install from it.

Sorry for double posting but we got something interesting in the launchpad report:

I can take care of fixing the packaging if we all agree this is the way to go.

@apt-ghetto I am confident that despite your issue surrounding zsh, something is wrong with the way Lubuntu handles Snaps until a Snap is installed and a log out and back in is completed.

Thank you all for testing, but it is a problem, that is not really related to LXQt or Lubuntu. Meanwhile I have found out, why it does not show up in my installations of Lubuntu 19.10 and Lubuntu 20.04, on different hardware.

Installed Lubuntu 20.04 (2020-01-04 ISO), (d755-8, c2d, 8gb, radeon hd 2400, BIOS) for T119
Sorry grub appeared as text, no pretty picture, no blue logo :(
(update as requested on iIRC)

Installed Lubuntu 20.04 (2020-01-04 ISO), (d755-8, c2d, 8gb, radeon hd 2400, BIOS)

Not sure where this is headed but by suggestion of the people on Snapcraft's forums, I've opened a bug report: https://bugs.launchpad.net/snapd/+bug/1858303

In T139#2870, @kc2bez wrote:

In T139#2869, @The_LoudSpeaker wrote:

I'd say we give the users an option to enable snaps using the "Welcome Center" and let them know that it will cost approx 50MB.

Having the option to enable it in the "Welcome Center" won't be any different from the experience that is provided now. The user will still have to logout/login for the menu etc. to work properly.

One thing that's true is that once you have the core snap installed, you can't uninstall it.

In T139#2870, @kc2bez wrote:

Having the option to enable it in the "Welcome Center" won't be any different from the experience that is provided now. The user will still have to logout/login for the menu etc. to work properly.

In T139#2869, @The_LoudSpeaker wrote:

In T139#2866, @wxl wrote:

From what I can tell ~50M doesn't seem like much to worry about to have such a poor user experience when Snaps are becoming increasingly common:

Bruv 50MB is a considerable amount as compared to our current usage. (>= 10%) I'd say we give the users an option to enable snaps using the "Welcome Center" and let them know that it will cost approx 50MB.