Bluetooth UI

[jleclanche]

We should have a bluetooth UI, either through an LXQt module or a third party app.

Basic requirements:

• Toggle device discoverability
• Manage bluetooth devices
  • List paired and available devices
  • Pair a device
  • Unpair a device
  • Connect to an available, paired device
• Share files with a connected device
• System tray icon

Pulseaudio gives us a fair amount of bluetooth audio functionality (unfortunately, no microphone support...), we should make use of it in the mixer.

pcmanfm-qt should allow sending files to a connected device, either through a plugin or through compiling with bluetooth support.

[jleclanche]

Posted on the ML, needs review: https://github.com/sklins/BlueMoon

[emk2203]

If you want feedback from a broader user base, why don't you package the proposed BlueMoon program for popular distributions?

[tsimonq2]

We don't control distributors. We're upstream. 😉

[agaida]

Btw - bluez and blueman work just fine

[agaida]

@tsimonq2 - do we consider bluez/blueman working - i guess we can consider bluemoon a dead horse.

[tsimonq2]

@wxl probably answer the question better.

[wxl]

@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.

[tsimonq2]

But @wxl...

do we consider bluez/blueman working

Despite @agaida's lack of a question mark, that is a question. 😛

[wxl]

> 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 we're talking here about a UI. To that end, Blueman works just fine, but it's GTK. Similarly, Bluedevil works fine, except for the fact that its full functionality depends upon a Plasmoid, so it's pretty KDE-specific. Don't get me wrong, Bluemoon would be nice. It's just dead.

[agaida]

Ok - only my point of view - we should not re-invent the wheel. Despite of being GTK blueman works fine. And we should not really care about the toolkit. Not being Qt don't mean that there is something bad with. Of course we could take over a dead project only because it is Qt - but who will maintain it? The situation would be different if we take over and also get devs who are interested in longterm. Otherwise it would be an additional burden.

[tsujan]

I agree that if there's no high quality Qt app in some area but there is a good GTK one, we shouldn't consider that as an obstacle but recommend the GTK app.

[wxl]

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 came and avoid GTK the better. I would say coming up with some sort of solution would be a good wishlist item, at the least. Bluedevil just needs a panel icon that exposes all the functionality of the Plasmoid and we're done. Doesn't take reinventing the wheel.

[agaida]

This is your opinion - please don't assume that it is shared by everyone. I prefer a modular and working system. I would never ever use a application only because it is Qt. I use applcations because they do what i want.

Re: bluedevil - just write it, if it don't throw in any additional kf5 dependencies we could consider to take over.

BTW:

apt depends bluedevil
bluedevil
  Hängt ab von: bluez (>= 5)
  Hängt ab von: bluez-obexd
  Hängt ab von: plasma-framework
  Hängt ab von: qml-module-org-kde-bluezqt
  Hängt ab von: qml-module-org-kde-kio
  Hängt ab von: qml-module-org-kde-kquickcontrolsaddons
  Hängt ab von: qml-module-qtquick-layouts
  Hängt ab von: qml-module-qtquick2
  Hängt ab von: kio
  Hängt ab von: libc6 (>= 2.14)
  Hängt ab von: libkf5bluezqt6 (>= 5.13.0)
  Hängt ab von: libkf5configcore5 (>= 4.98.0)
  Hängt ab von: libkf5configgui5 (>= 4.97.0)
  Hängt ab von: libkf5configwidgets5 (>= 4.96.0)
  Hängt ab von: libkf5coreaddons5 (>= 4.100.0)
  Hängt ab von: libkf5dbusaddons5 (>= 4.99.0)
  Hängt ab von: libkf5i18n5 (>= 4.97.0)
  Hängt ab von: libkf5iconthemes5 (>= 4.96.0)
  Hängt ab von: libkf5kiocore5 (>= 4.96.0)
  Hängt ab von: libkf5kiofilewidgets5 (>= 4.96.0)
  Hängt ab von: libkf5kiowidgets5 (>= 4.96.0)
  Hängt ab von: libkf5notifications5 (>= 4.96.0)
  Hängt ab von: libkf5widgetsaddons5 (>= 4.96.0)
  Hängt ab von: libkf5windowsystem5 (>= 4.96.0)
  Hängt ab von: libqt5core5a (>= 5.11.0~rc1)
  Hängt ab von: libqt5dbus5 (>= 5.9.0~)
  Hängt ab von: libqt5gui5 (>= 5.9.0~)
  Hängt ab von: libqt5qml5 (>= 5.0.2)
  Hängt ab von: libqt5widgets5 (>= 5.9.0~)
  Hängt ab von: libstdc++6 (>= 4.5)
 |Schlägt vor: pulseaudio-module-bluetooth
  Schlägt vor: <bluez-alsa>

[wxl]

I doubt there's much that's been discussed in these issues that is not (A) an opinion and (B) not shared by everyone else, so that's kind of a moot point. Anyways, I'm not suggesting we use something because it's Qt, because then I'd suggest Bluemoon. I am not suggesting that because I have no reason to believe that it will continue to work in the future. Still, it would be nice to have something that fits well with the rest of the system, thus the resaon this bug was created in the first place. Chances are a solution isn't going to come quickly, but keeping an open mind to the possibility is about all anyone could ask for.

[Jogai]

This is your opinion - please don't assume that it is shared by everyone. I prefer a modular and working system. I would never ever use a application only because it is Qt. I use applcations because they do what i want.

While this makes sense, I'm one of those LXQt users that prefers to use Qt apps over gtk ones. I wouldn't prefer an implementation that's missing features or broken, but given the choice and a Qt alternative that fits my needs, I would choose the Qt one. Besides its just the obivious thing to do, see this very recent question by this user: https://forums.debian.net/viewtopic.php?t=153334

I'm not suggesting that there should be resources redirected to this, but I think this issue should acknowledge that some users are expecting a Qt variant, and if someone ever wants to do this, it would be appreciated.

[aurelienpierre]

For what is worth, monitoring Blueman with powertop, it eats as much CPU cycles just running in background as, say, Nextcloud sync daemon. I find it suspicious since it's merely a GUI (albeit a Python + Gtk one), and the system doesn't need it to automatically connect to (already-known) devices. KDE Bluedevil doesn't provide an systray applet but lets you add/manage devices, problem is it requires KDE System settings app to be accessed.