22 Nov
2016
22 Nov
'16
7:07 p.m.
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
23 Nov
23 Nov
2:04 p.m.
New subject: [trinity-devel] kbluetooth
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
6:09 p.m.
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
5 Dec
5 Dec
6:36 a.m.
Michele Calgaro wrote:
On 2016/11/23 03:07 AM, deloptes wrote:
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!
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
7:27 a.m.
New subject: [Bulk] [trinity-devel] Re: kbluetooth
On 2016/12/05 03:36 PM, deloptes wrote:
Michele Calgaro wrote:
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
On 2016/11/23 03:07 AM, deloptes wrote:
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!
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
12 Dec
12 Dec
9:39 p.m.
New subject: [Bulk] [trinity-devel] Re: kbluetooth
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
14 Dec
14 Dec
12:42 p.m.
New subject: [trinity-devel] Re: [Bulk] [trinity-devel] Re: kbluetooth
On 2016/12/13 05:39 AM, deloptes wrote:
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
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
7:05 p.m.
New subject: [Bulk] [trinity-devel] Re: kbluetooth
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
20 Dec
20 Dec
11:19 p.m.
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)
22 Dec
22 Dec
11:30 a.m.
New subject: [trinity-devel] Re: kbluetooth
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(a)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
3:25 p.m.
Abdorhman Ayman wrote:
why is it that nobody replys to anything in this
mailing list :( ??
sorry, I wish I can help you.
respectfully
I guess everybody is busy, but from time to time someone writes back.
I actually want to get rid of all gtk or qt4 dependencies ... but I still
don't have a concrete plan :)
I decided to first make it work on wheezy as less changes in the code and
stumbled upon this py-qt4 kblueplugd ...
regards
23 Dec
23 Dec
11:39 p.m.
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
11:46 p.m.
New subject: [trinity-devel] Re: kbluetooth
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
24 Dec
24 Dec
9:05 p.m.
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
27 Dec
27 Dec
2:42 p.m.
New subject: [Bulk] [trinity-devel] Re: kbluetooth
On 2016/12/21 08:19 AM, deloptes 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)
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 ;-)
Cheers
Michele
6:04 p.m.
New subject: [Bulk] [trinity-devel] Re: kbluetooth
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
2917
days inactive
2952
days old
16 comments
4 participants
participants (4)
-
Abdorhman Ayman -
deloptes -
Michele Calgaro -
Mike Bird