Walter Lapchynski

@tsujan Then maybe as a nice wishlist thing we could make use of that. @bzb2 Another way to read this discussion is that there's no hope of change in Lubuntu...

@tsujan I agree it's a good idea if we can make it happen. I also agree it would be best to remain as agnostic as possible with regards to external...

I agree with #1110 and emphasize that it's also useful for anyone to configure any keyboard options, including stuff like: * compose key * control key behavior * caps lock...

BTW see the [forum](https://forum.lxqt.org/t/google-summer-of-code-2020/1067/2) on this subject. Also here's some things that would be appropriate, I think: * easy * fix terms lxqt/lxqt-globalkeys#127 * desktop entry metadata fix on lxqt-config-input...

I think at minimum allowing one to enter a series of arbitrary [`xkeyboard-config`](https://manpages.ubuntu.com/manpages/eoan/man7/xkeyboard-config.7.html#options) options, of which there are *indeed* many, would be a good idea. LXDE did exactly this in...

Sounds like this might be a good candidate for an upstream issue with `QScreen` then, no?

Um, wow, Alf, I didn't know you were *that* guy. I'm all for Unicode, though. And you save a little real estate! Just make sure if you use [em dashes](https://www.thepunctuationguide.com/em-dash.html),...

@agaida and I came to the same independent conclusion. It's so dead. Why we continue to wonder otherwise despite all proof otherwise is beyond me.

> > do we consider bluez/blueman working bluez is the kernel stack. Yeah, it works. `hcitool` and all can do everything anyone could possibly want on the command line. But...

While I don't disagree, this is LX*Qt* not LX*whatever*. One of the attractive features of it is exactly that: it's Qt. The more we can keep things in the Qt...