Michele Calgaro wrote:

Hi Emanoil, I have no experience in blues (either 4 or 5) so I can't say much about that. Regarding the packaging part, IMO you could first focus on getting bluez functionality to work and later worry about the packaging part. Keep in mind that TDE is available also for rpm based distro, not only deb based one, so we will have to package it also for them, with a little help of Francois :-)

I want to build the package, so that I may install all necessary files, so that I may test I think it is easier to test the binaries as now it says protocol not supported and alike. This does not mean that the code won't work in an rpm package.

regards

On 2016/12/05 03:36 PM, deloptes wrote:

Michele Calgaro wrote:

...

On 2016/11/23 03:07 AM, deloptes wrote:

...

Hi all, I downloaded kdebluetooth-1.0_beta8 and ported the code to TDE 14 (I have most of the tools and libs at 14.1). I can build it without errors. I am now looking into what needs to be done for the code to actually work. The major part is the dbus/bluez5 code. Do you have any hints that could perhaps help me? I have only basic understanding of both dbus/bluez5 and some user experience with both. I read briefly a guide for updating bluez4 to bluez5 and reference to dbus interface.

Another challenge is the debian packaging part, perhaps someone would like to help there as I am not sure how TDE packages are build (paths), but even if no one has the time, I have to sit down and learn about it as I would need it in near future so again any hints where to start are appreciated. I have some good understanding how debian/* works, so I need more TDE specifics here.

Thank you in advance and regards

Hi Emanoil, I have no experience in blues (either 4 or 5) so I can't say much about that. Regarding the packaging part, IMO you could first focus on getting bluez functionality to work and later worry about the packaging part. Keep in mind that TDE is available also for rpm based distro, not only deb based one, so we will have to package it also for them, with a little help of Francois :-)

Cheers Michele

Is it to expect that there is bluez4 in use on the supported distributions? If yes it would be more complicated. Should I drop bluez4 support?

Thanks!

Francois is maintaining TDE on some old distros. I think as a rule of thumb you should expect bluez4 on old distros and bluez5 on newer ones. Conditional compilation is needed based on the actual version install. Ex: in wheezy bluez is 4.99, in jessie 5.23 Cheers Michele

Michele Calgaro wrote:

Conditional compilation is needed based on the actual version install. Ex: in wheezy bluez is 4.99, in jessie 5.23

I'm not sure if it wouldn't be easier to build a new package like tdebluetooth for bluez5 or alike and just port the old code as is. I would like to sort this out before going deeper into changes, but this would be my preferred way as too much changed on bluez side.

regards

Michele Calgaro wrote:

Hi Emanoil, I have no clue either. I see two possible ways to proceed:

1. have conditional compilation as discussed previously
2. have two different version of tdebluetooth, one for bluez5 and one for

bluez4. Both have advantages and disadvantages. As far as I am concerned you have the freedom to choose the way you think is better/easier. Cheers Michele

Hi Michele, yes indeed these are the two options.

1) it would make sense if code/system would be maintained in the future. Given the all changes done KDE -> TDE, Qt -> TQt, dbus, bluez ... it would be the hell of conditionals in the code

This is why I tend to go for option 2. In case of wheezy/bluez4 it would mean to port from KDE -> TDE (with some minor updates/corrections) For the rest/bluez5 the code needs to be changed to implement the bluez5 interface

I'm just asking, so that I know how you see it

thanks

why is it that nobody replys to anything in this mailing list :( ?? sorry, I wish I can help you.

respectfully

On Wed, Dec 21, 2016 at 1:19 AM, deloptes deloptes@gmail.com wrote:

I am afraid I am missing something like python dbus.mainloop.tqt for the kblueplugd

from python_tqt import qt import dbus import dbus.mainloop.qt <<<<<<< HERE import distutils.spawn

kbtcmd = [ 'kbluetooth' ] quitprogs = [ 'kdebluetooth', 'kbluemon', 'kinputwizard' ] # FIXME: quit kbluelock too?

app = qt.TQApplication(sys.argv) if app.isSessionRestored(): sys.exit(1)

dbus.mainloop.qt.DBusQtMainLoop(set_as_default=True) <<<<<<< HERE bus = dbus.SystemBus()

try: manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager') except: print "Unable to connect to bluez." sys.exit(1)

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@ lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists. pearsoncomputing.net Read list messages on the web archive: http://trinity-devel. pearsoncomputing.net/ Please remember not to top-post: http://trinity. pearsoncomputing.net/mailing_lists/#top-posting

This functionality in kblueplugd can be moved to tqt code ... to handle the programs. But I really like the blueman option to switch on/off the adapter (rfkill), so I would prefer to keep the main app in the tray, which kind of obsolates kblueplugd and advocates for moving this functionality to the main app.

The code "as is" doesn't work in wheezy unfortunately (and there is no time for it).

It goes more and more into redesign and rewrite for use in future tde.

regards

Mike Bird wrote:

I short note as I don't seem to be alone in running into problems with many of the available bluetooth tools.

For me (and YMMV) the most reliable mechanism by far is obexfs -b 'AA:BB:CC:DD:EE:FF' -- /mountpoint

Seasonal Best Wishes,

--Mike

Thanks Mike, the discussion is about porting old kdebluetooth code to TDE. I am now using blueman, but it comes with some additional gtk overhead. I was wondering if it is possible to get a real tde bluetooth manager. It looks like it will take more time and effort to get it right.

regards

Michele Calgaro wrote:

Hi Emanoil, looking at packages available in Debian/Stretch, I see there are these packages: - python-dbus.mainloop.pyqt5    (for python 2)

• python3-dbus.mainloop.pyqt5   (for python 3)
• python3-dbus.mainloop.qt      (fpr python 3 - qt4)

These packages supply support for the Qt application main loop in python. I guess we need something similar for python 2 and Tqt3, which is currently not available AFAIK. I guess/hope (I could be wrong of course) that starting from the source code of the existing packages you could come up with something like that without too many modifications. If you do so, we will be very happy to add such package for R14.1

Hi Michele, I am not a python coder and it is beyond my interests. The purpose of the code (if I understand correctly) is to spawn the kbluetooth app (which appears in the system tray) when adapter is plugged in. As stated I would prefer the functionality as in blueman. This means the applet runs always and user can enable or disable the adapter etc. - the python code is obsolete for what I want to do, but it is nice to have.

As also mentioned unfortunately the code is not running "as is" in wheezy with TDE. It does not make sense to me to work on it.

The code has good conceptual and functional design, which can be reused into some extent, but the rest would need to be redesigned and rewritten ... I may try to do it. I could learn a bit more about TDE ... and about designing complex apps with dbus.

regards