Open jboero opened 11 months ago
@tiktaalik-dev Thank you again for reviving this code years ago. I've always loved this underappreciated tool. I've given it another update and packaged with RPMs for Fedora/yum derivatives. It will work until they completely remove bluez-deprecated
package with hcitool. Forum and inflammatory dbus rant thread in comments. :)
Hi!
I was also one of the (few?) users of this. And, since when I've had to switch to Fedora I really miss it. I've tried to use it from the clone of your pull request, but I can't get it working. When I start it I get the following error:
The program cannot import the module XApp.
Please make sure the GI bindings for XApp are installed.
e.g. with Ubuntu Linux, type
sudo apt-get install gir1.2-xapp-1.0
I know that this is related to the fact that I use Wayland and not XOrg. But, is there a way to get it anyway working? What could I do to use it, apart moving to XOrg?
Thank you! Your work to maintain it is really appreciated!
Did you try to install that then? The Fedora package is python3-xapp
.
Hi, sorry for the late answer. Only now I've found time to test.
After installing several python libraries, and moving all the code into a subfolder of usr/share, I get this:
/usr/share/blueproximity/proximity.py:1423: DeprecationWarning: Passing in an options dictionary to ConfigObj() is deprecated. Use **options instead.
config = ConfigObj(os.path.join(conf_dir, filename),
Using config file 'standard.conf'.
(proximity.py:16626): Gtk-CRITICAL **: 06:25:55.798: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
(proximity.py:16626): Gtk-CRITICAL **: 06:25:56.800: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
(proximity.py:16626): Gtk-CRITICAL **: 06:25:56.803: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
Actually it's impossible to run the software from a user local directory because the paths have been changed. I used to have it in ~/Applications/blueproximity, but I've had to move in usr/share. I suppose due to the adaptations to make a package, hence is totally ok.
The other part, the error, I have no idea of what I could install/change to make it working. I've tried to use it with Wayland, could it be that is this the reason?
I give myself the answer: yes. With X11 it's possible to start it, after having installed all the required python packages. But, it looks it's not working. Even after pairing a device (that was already paired... but I've had to delete and pair again), in the distance field it keeps writing "gone" and the values are not changing.
A question: is it possible to have it working even with Wayland? I would like to stay with it.
I answer myself: yes, switching to X11 it starts. But, there is something strange, it recognizes only some devices. To find the smartphone I've had to pair it again. And, even after finding it and selecting it, it doesn't recognized the change in the distance: it's always "gone".
I've updated and tested this for latest Fedora 38 and finally got around to an RPM spec. Unfortunately the community deprecated hcitool in favour of Dbus and then completely removed RSSI from Dbus so I've included the
bluez-deprecated
package as a prerequisite for the old (but still perfectly working)hcitool
.I can see the RSSI function in hcitool is just using a simple IOCTL to go straight to the source. Dbus evolution has been a PITA on this and it makes sense to go straight to the IOCTL. I would either like to rewrite this in some form using C++ which I'm more comfortable with or to sort out the IOCTL in Python but in the meantime here is a branch that works and includes packaging. The SOURCE0 path in RPM will need adjustment.
Fedora forum thread: https://forums.fedoraforum.org/showthread.php?324423-What-happened-to-Blueproximity