Re: user settings, yeah I don't have a good solution except perhaps a post-inst script that checks for the lxlock definition and queries the user to change it to light-locker? @tsimonq2 do you think that makes sense?

Part of me wonders if we shouldn't actually reverse all these changes and leave nm-tray as it is and instead use conman like upstream suggests. @tsimonq2 seems to be against it but it's not clear why.

Since we have changed nm-tray to use nm-connection-editor instead of nm-tui, it's not relevant to depend on a terminal; otherwise it would make sense.

The patch got merged, so someone needs to get that in if we don't get a new release. @tsimonq2 do you know if they plan on doing an LXQt release before, say, FeatureFreeze?

Can you share the debdiff for the change just to be perfectly clear?

Looks like btrfs just got swapfile support, perhaps making this more of a possibility upstream.

I would say this is a basic security feature and should function as expected. I wouldn't say that this bug is a security issue since it is still possible to lock the screen, but it just makes it harder. I guess it's a security issue if a user hits the button expecting it to work and walks away without paying attention.

Fixed now in Eoan. debdiffs for other supported versions added and ~ubuntu-sponsors subscribed. Now we wait.

Sounds like we're done. @tsimonq2 can you find the right place to put this, please?

Merge request submitted for Eoan.

P.S upstream is here. Will need to get it into Eoan and mark the bug as Fix Released before the SRU can be sponsored.

PPA now available.

Also you've got some Travis stuff in the diff you should probably get rid of.

See the description of the parent task. There's a link there.

So who's landing this thing? What's the next step?

Nope. Everything we put in the archive affects anyone that installs it. Every package is available to everyone.

Oh no! I just realized there's a problem with this: we need to make network-manager-gnome a dependency in debian/control! Perhaps better to call it a recommend as it's supposedly a "pure Qt application" according to the description.

We test to see if it works. If it does, then we will need to prioritize that first. I doubt we will get a new release, so we'll have to patch our version in Ubuntu. Once that's settled, then we deal with putting this in the right place. According to the Qt docs, barring a local config, QSettings (which is what the pull request uses) will look through XDG_CONFIG_DIRS. As our wiki implies, this should equal /etc/xdg/xdg-Lubuntu:/etc/xdg:/etc:/usr/share. rDEFAULTSETTINGS already has a /etc/xdg/xdg-Lubuntu/lxqt folder so that's where this would end up if this does work. Naturally, what we'll be putting in there is the whole file and not this patch, so things will be a bit different in final implementation.

Good job!

Looks like there's a potential upstream pull request for making globalkeys respect XDG, so this may end up going to rDEFAULTSETTINGS after all.

Remove the "Lubuntu specific keybindings" line, please.

The SRU is now in the wild (well, in proposed):

As I said on D18, we should move the media keys (the XF86 ones) over to globalkeyshortcuts.conf. I understand you don't have the keys. No big deal. You can make the definitions to something else ridiculous and then hand edit the file.

path=/panel/desktopswitch2 should be path=/panel/desktopswitch

In little 640x480 VirtualBox, the big logo looks scrunched and the Hummingbird is a bit pixelated.

Sorry to be particular, but we're training you, so we're going to make you do it right before we set you free to fly on your own 😄 That said, please remove this:

Regarding the patch, remove this:

So I've confirmed it is hardcoded and it seems to be a known problem but it's kind of a bugaboo. @tsimonq2 maybe we should just go the route of patching globalkeys now and later when we get the patch to respect XDG, we can move that patch to default-settings?

One thing you could do while we figure this out, though, is to clean up your diff as aforementioned.

Love it!

Love this. Though I certainly don't mind dealing with these sorts of things, it would relieve a lot of time for me.

I've already personally verified this works, so I'll go ahead and land it.

As I said on IRC, the "window tiling" shortcuts are not anywhere near real window tiling. It's a substandard implementation. I'm not willing to compromise other things just to support something that doesn't even work well compared to an actual tiling window manager. So I would opt to remove it. If someone's going to insist on it, it must not be a first or second level shortcut and it must not use the Super key.

Good call @guiverc. We need to add changing the manual to the specification. There's actually two places:

Well if you look, Darin Miller tested Secureboot when we did 19.04, and we had Lubuntu in it then, no?

Yeah I don't know why we didn't do that before. It's a no brainer. Make it happen @kc2bez.

Yeah and let's slow our roll here. We might want to see if lxqt-globalkeys doesn't actually support XDG. It should. If so, this can go in default settings after all.

I presume there will be a corresponding differential revision for the LXQt side of things?

Anything with a W key will need to be removed from Openbox or we're going to run into trouble.

According to T62 it sounds like @tsimonq2 is definitively saying we need to set this to Ubuntu, or not change the behavior from the way Ubuntu sets it, which is to say we need to go with option #1. This may require doing some shell work ahead of time to set bootloaderEntryName programmatically.

Better specification:

Looking at the documentation for the NextWindow action it looks like it allows you to cycle between the panel and the desktop. That said, I can't figure out what's useful about that once you're on the panel. Maybe if the panel had its own shortcuts that weren't globally accessible, that might make sense. Kill it with fire.

Do you not see the hummingbird logo next to your selected option, @guiverc ? I don't see it in the pic.

Niiiiiiice. So that's in VirtualBox. I'd like to see what it's like on real hardware, various different graphic cards, etc.

Waiting on upstream on this one. Apparently there's no repo with the current version????

It seems there's an upstream issue specifically about swapfiles.

This is fixed in Eoan:

Whoo hoo it works!!!

This is the incorrect solution. @Tj is working on the actual fix.

BTW here's some stuff from the previous version of this bug:

Looks like MATE no longer installs the theme by default because it's problematic with some hardware it seems. Curious.