Blueberry doesn't work with gnome-bluetooth >= 42 #123
Comments
|
@leigh123linux FYI. we have an awkward case in Fedora Rawhide right now: to build GNOME 42 Beta we need to update gnome-bluetooth to 42, but doing that will break blueberry. |
blueberry will never work with gnome-bluetooth 42, the UI part of the API isn't exposed to introspection on purpose, as its sole intended consumer is and always was gnome-control-center. Only the non-UI part of the library is has bindings through gobject-introspection as its sole consumer is gnome-shell. FWIW, I learnt of "blueberry"'s existence today, when I learnt that it was keeping me from packaging gnome-bluetooth 42 as a simple package bump in Fedora when its two users (gnome-control-center and gnome-shell) got updated. I'm not too pleased that somebody relied on an implementation detail of the GNOME platform to create this application. |
|
That's fine. gnome-bluetooth used to be a tool which had its own UI and worked on all DEs before it was turned into something that could only work as part of gnome-control-center and basically deprived MATE, Cinnamon and Xfce of the BT tool they were using. When that happened, we weren't too pleased either. Going forward there are multiple solutions. We're already facing connectivity issues and sound profile problems with the gnome-bluetooth backend and considering replacing it with blueman, so one solution is simply to stop developing blueberry. @AdamWill If 42 provides GI to be used with Shell we can probably use that. I don't think that was possible at the time, or at least that's not what GCC was doing. We'll have a look and get back to you. |
|
For the record I'm not primarily interested for myself, I use GNOME; I just wanted to give a heads-up when we ran across this issue while doing the GNOME 42 builds for Fedora. @leigh123linux would be the main Fedora person to follow up with I think. |
Have you asked the fedora blueberry maintainers? |
There's nothing stopping you from forking gnome-bluetooth and maintaining it, then, or now. It would certainly require doing slightly more work than you were up to that point, that's for sure. |
|
Blueberry used the gnome-bluetooth widget the same way gnome-control-center did. It's extremely basic. That project is nothing else than the window and menu launcher you removed from gnome-bluetooth. There's very little work involved in it. We didn't implement anything, we just fixed the regression and brought back gnome-bluetooth's compatibility with other DEs. If you maintained that BT stack, which worked everywhere before, with a little bit of consideration for people who use it outside of the GNOME DE there would be no work involved at all. Instead, there was a tiny amount of work here, and "slightly more work" elsewhere, in blueman. Blueman handles it all and for all DEs. You might think it's a good thing but it's the result of an unnecessary fragmentation. It already has a better backend and the work put in it sadly doesn't trickle back or benefit gnome-bluetooth. Forking yet another BT backend is a terrible idea. Either we'll adapt blueberry and it will continue as a frontend to gnome-bluetooth, or we'll stop the project and focus our efforts on blueman. |
|
@AdamWill I had a look at https://lists.fedoraproject.org/archives/list/[email protected]/thread/644RTSO5KXRKW76KHZ6CYHP3O7USPPA7/ and had a chat with @leigh123linux in one of our slacks.
|
Totally normal usage: https://github.com/linuxmint/blueberry/blob/master/usr/lib/blueberry/blueberry.py#L172
I'm sorry, but I owe you, or the other desktops, absolutely nothing. I'm not sure which part of gnome-bluetooth made you think it was built to work on desktops other than gnome. You should be grateful to not have had to maintain your own Bluetooth tools for as long as you did, especially given the contributions made back to gnome-bluetooth as a result of that usage. And I find it weird that you expect me to maintain a UI for other desktops until the end of days when you can't be bothered to maintain your own for a day. |
|
There's quite a lot you don't understand. That's fine Bastien. We don't need to agree on anything. |
clefebvre
changed the title
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
The new version is incompatible (see linuxmint/blueberry#123) This re-adds the old one, but just for blueberry, until the compatibility issue is fully resolved
…nome-bluetooth_1_0 - Add missing geocode-glib dependency for gnome-panel - Reintroduce gnome-bluetooth_1_0 for gnome-flashback, blueberry and gnome-bluetooth-contract Related: - https://gitlab.gnome.org/GNOME/gnome-panel/-/merge_requests/49 - #166569 (comment) - linuxmint/blueberry#123 - elementary/gnome-bluetooth-contract#1
|
I would like to make everyone aware of what I consider to be a deficiency in the 'blueman' alternative. Although it does have some nice features, it was designed so that the device discovery listing is not persistent. After the user has done a device search, the front-end utility is taken out of discovery mode and devices start disappearing until the listing is empty. This occcurs spontaneously after 15-60 seconds. I had a conversation with the 'blueman' maintainers and it was clear that they have no intention of fixing the problem, even after I pointed out the fact that they are an outlier. As you know, every other bluetooth front-end gives the user a persistent listing of discovered devices. That's true on GNOME, KDE, Android and even Windows. It would be unfortunate if 'blueman' became the default wrapper for Cinnamon, Xfce or MATE. Cinnamon is a perfect DE for my use and I would be forced to switch to either KDE or GNOME. Ideally, someone with more influence than I would convince the 'blueman' maintainers that their device listing should be persistent (i.e., the discovery dialog should remain in discovery mode as long as it's open). As I pointed out to them, an older bluetooth device might take some time to become available and with Blueman out of discovery mode, it might never be connected. |
|
This might be a bit off topic but I really like this bluetooth client, it is by far one of the best lightweight bluetooth clients out there not just for mint but also for the Other DE's of the tiling variety and it would be a shame to see it go EOL over the gnome-bluetooth debacle. Help?! PS: Also I've used blueman and IMHO its pretty terrible |
gnome-bluetooth 42 was released recently, and makes major changes to the API. It also, AIUI, requires GTK+ 4.
blueberry probably won't work with gnome-bluetooth 42 and GTK+ 4 without major changes. Not sure if you want to do that, or instead maybe fork gnome-bluetooth 3.x? I don't believe upstream intends to maintain it any more.
The text was updated successfully, but these errors were encountered: