Hello all,
I'm currently trying to get kdebluetooth reviewed into Fedora Core (and
RHEL).
As some of you may be aware, the current version of kdebluetooth has no
support for recent (>= 3.9) bluez DBUS interface.
As an interim solution I decided to write a small wrapper that can be
used as a bridge between kdebluetooth's kbluepin and bluez-utils 3.9
(running on the about to be released F7) - basing my work around
bluez-utils' passkey-agent.
While working on it I decided to further expand it - making it
configurable and script-able which in turns, makes it entirely possible
to create passkey dialog boxes in non-X modes (using 'dialog') or in
low-end machines with minimal WM's (using 'zenity' in
IceWM/Fluxbox/etc).
As it stands I got two options:
A. Use this code as a stop-gate until qt-dbus + kdebluetooth is released
(KDE 4?) maintaining this code as a Fedora-only blob.
B. If its of any use to anyone (read, you), get it submitted into
bluez-utils while maintaining it (and expending it - if so required)
upstream.
Comments?
Is it any use for you?
http://gilboadavara.thecodergeek.com/bluez_pinhelper-0.1.tgz
P.S. this code was tested against i386/x86_64 Fedora Rawhide installs
running bluez-libs 3.9. I've yet to port it to 3.11.
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2007-05-29 at 13:27 +0200, Stefan Seyfried wrote:
> On Sun, May 27, 2007 at 09:41:40PM +0300, Gilboa Davara wrote:
> > ... But if an unsupported patch is used, you're S.O.L.
> > You can't report the bug upstream (not their code) and you can't
> > report the bug to SUSE people. (Not their distro)
>
> Have you tried this? I'm quite sure that Daniel appreciates a good
> bug report against his code and that he does not really care what
> distro his code runs on.
I already talked to Daniel and he kindly offered his help. (If things
will break)
As such, I plan on pushing the patched version into the Fedora
repository ASAP.
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, May 27, 2007 at 09:41:40PM +0300, Gilboa Davara wrote:
> ... But if an unsupported patch is used, you're S.O.L.
> You can't report the bug upstream (not their code) and you can't
> report the bug to SUSE people. (Not their distro)
Have you tried this? I'm quite sure that Daniel appreciates a good
bug report against his code and that he does not really care what
distro his code runs on.
-- =
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg | "Well, surrounding them's out." =
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daniel,
> > please do releases and do them often. It is important to have releases,
> > because otherwise nobody really tests the code. Trust me on that one.
> > Only core developers check out the source from the SCM directly.
>
> That's true...
>
> I run out of time will hacking on kdebluetooth for KDE3 and KDE4 (and other
> projects) at the same time. I try to replace the kdebluetooth trunk version
> with the kdebluetooth-dbus-integration branch the next days.
sometimes a broken release is better than no release. However you need
to be prepared to fix it as soon as possible. So following release early
and release often might help to get this progressing faster.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Monday 28 May 2007 23:11:56 Denis KENZIOR wrote:
> What are your plans with kdebluetooth? =A0Are you going to make KDE3 based
> releases or wait until KDE4? =A0I'm asking since Qtopia Bluetooth is Qt4
> based and uses Qt DBUS bindings internally to communicate with BlueZ.
kdebluetooth for KDE3 consits of a libkbluetooth which got ported to BlueZ =
DBUS interface in the kdebluetooth-dbus-integration work branch:
http://websvn.kde.org/branches/work/kdebluetooth-dbus-integration/libkbluet=
ooth/
KDE4 will still take some time, so there is need to have something working =
in =
KDE3 in meantime. I would use the Qtopia Bluetooth API for a new Bluetooth =
Solid backend in KDE4. Which would replace:
http://websvn.kde.org/trunk/KDE/kdebase/runtime/solid/bluez
best regards,
Daniel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Daniel,
What are your plans with kdebluetooth? Are you going to make KDE3 based
releases or wait until KDE4? I'm asking since Qtopia Bluetooth is Qt4 based
and uses Qt DBUS bindings internally to communicate with BlueZ.
> I have to take a deeper look on the implementation of the BlueZ DBUS
> interface... is there any plan to wrap also BlueZ Service APIs like the
> Input Service? Or is this already done?
>
Yes, we're planning Input service for 4.4 and PAN for 4.4. Actually services
are probably the least useable by KDE the way they are now. Mostly because
we use our own IPC mechanisms, they could probably be easily adapted to any
IPC mechanism though.
> Or you going to implement the Authorization Agent as well?
Yes, this only went non-experimental as of 3.10.1, so we're probably going to
add this in 4.4.
>
> Actually i plan to implement all the services which are available by BlueZ
> ... So it would be very interesting which BlueZ services get
> implemented/used by Qtopia. Or should it be possible to make use of all
> services via
> QBluetoothAbstractService?
The QBluetoothAbstractService is more of a framework class, to help build
service implementation and insure certain features are supported (starting /
stopping services mostly) To use a service you still need to use an
interface class, very similar to BlueZ.
>
> On which version of BlueZ will be Qtopia 4.3 based? bluez-utils 3.9 like
> Qtopia 4.2?
This is the most likely case.
>
> Are you going to keep the OBEX support or make use of the BlueZ transfer
> service in the future?
OBEX support in 4.2 is not that great, we improved it considerably in 4.3. It
wraps OpenOBEX, but makes it very easy to use. We're planning to implement
FTP, PUSH, BPP and BIP profiles over OBEX using this infrastructure. Some
(PUSH client/server, FTP client) are already done.
>
> A separated package would be great...
OK will try prioritize this :)
Regards,
-Denis
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Monday 28 May 2007 10:29:56 Marcel Holtmann wrote:
> please do releases and do them often. It is important to have releases,
> because otherwise nobody really tests the code. Trust me on that one.
> Only core developers check out the source from the SCM directly.
That's true...
I run out of time will hacking on kdebluetooth for KDE3 and KDE4 (and other
projects) at the same time. I try to replace the kdebluetooth trunk version
with the kdebluetooth-dbus-integration branch the next days.
Sorry - i'm really bad in managing my time.
best regards,
Daniel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Monday 28 May 2007 01:39:31 Denis KENZIOR wrote:
> As part of our work on Qtopia we've wrapped the BlueZ DBUS interface and
> some of the Bluetooth socket types in a nice Qt way. =A0We've also done s=
ome
> work on OBEX support in Qtopia 4.2, with much nicer API in Qtopia 4.3.
>
> Check out http://doc.trolltech.com/qtopia4.2/qtopiabluetooth.html. =A0If
> there are some things which can be used by KDE (beats duplicating effort),
> I can work on separating the Bluetooth classes as a separate Solutions
> package or something. =A0Same goes for OBEX support.
Sounds very interesting! =
I have to take a deeper look on the implementation of the BlueZ DBUS =
interface... is there any plan to wrap also BlueZ Service APIs like the Inp=
ut =
Service? Or is this already done?
Or you going to implement the Authorization Agent as well?
Actually i plan to implement all the services which are available by BlueZ =
... =
So it would be very interesting which BlueZ services get implemented/used b=
y =
Qtopia. Or should it be possible to make use of all services via =
QBluetoothAbstractService?
On which version of BlueZ will be Qtopia 4.3 based? bluez-utils 3.9 like =
Qtopia 4.2?
Are you going to keep the OBEX support or make use of the BlueZ transfer =
service in the future?
A separated package would be great...
best regards,
Daniel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Gilboa,
> > > kdebluetooth aside, If -I- (being, among others, the IceWM Fedora
> > > maintainer) can use this wrapper (coupled with zenity and/or xdialog)
> > > and create a workable out-of-the-box bluetooth experience on IceWM
> > > (without the bluez-gnome dep-chain) and other low-end WM's - doesn't it
> > > enhance the user experience?
> >
> > I agree that the bluez-gnome dependency chain is crazy, but that is a
> > GNOME issue. However you can write a simple nice passkey agent for every
> > windowing system that you wanna use. The scripting part is not a clean
> > solution. We should have never used scripts for entering pin codes at
> > all, but at that point of time any useful solution was not ready.
>
> OK.
> I can't say that I agree (IMHO having bash/scripting support for
> right-about-everything is major feature in Linux/Unix - not a
> drawback), but I accept the fact the being the upstream-man, you get
> to choose what goes in and what doesn't - and this code doesn't.
from a security perspective, I am not doing this again. We already had a
major issue with the PIN helper script in the 2.x series.
Everybody is free to write their own passkey agent and if it uses
scripts to get the PIN input, that is fine. However bluez-utils will
probably never contain an installable passkey agent. These have to be in
the Bluetooth desktop packages or as an additional add-on. The major
reason is to keep the dependency chain small. With the old Python GTK
based helper script the package maintainers went mad and an install of
bluez-utils dragged GTK and Python onto your system. Not really funny if
you build an embedded box. Nowadays it is only D-Bus that is needed.
Even if the dependency chain of your wrapper is not a problem, I have
seen too much misuse of passkey-agent.c that I am going with it. Lets
keep bluez-utils clean and free of UI. This includes your code, even if
it is technically not UI code.
> > > ... And hopefully I took it, expanded it, and put it to good use.
> > >
> > > At best, I managed to enhance the bluetooth experience on
> > > low-end/older/minimal distro/machines/configuration/etc. At worst,
> > > (after some clean up) I created yet-another-how-to-do-passkey example.
> > >
> > > Having said all that, I'm far from forcing the issue down your throat...
> > > I merely suggesting. If you don't like the idea, I'll keep it
> > > Fedora-only, until a working DBUS patch is released... or until KDE4
> > > comes out.
> >
> > I am fine with having something KDE specific since I don't really care
> > about KDE, but this is not solution that is acceptable by Bluez
> > upstream.
>
> Just for the sake of the archives, this wrapper is completely generic - it has
> nothing KDE (or kdebluetooth) specific in it.
Please see comment above :)
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daniel,
> > As some of you may be aware, the current version of kdebluetooth has no
> > support for recent (>= 3.9) bluez DBUS interface.
> Thats correct - it's even quite unmaintained for a while...
> I started at the #1 BlueZ Meeting a kdebluetooth-dbus-integration branch:
>
> http://websvn.kde.org/branches/work/kdebluetooth-dbus-integration/
>
> The libkbluetooth got a full rewrite and wraps the full BlueZ DBus API (and
> the Input Service so far ...) - main goal: avoid any linking against
> bluez-libs.
>
> The kio_slaves (kio_bluetooth, kio_sdp) and kcm_btpaired got ported to the new
> libkbluetooth API. The kbluetoothd got rewrite and renamed to kbluetooth and
> is now a "simple" tray icon application like bluez-gnome. And acts as
> (Default) Passkey Agent and Authorization Agent. It also includes a (very
> experimental) bluetooth input device wizard which makes use of the BlueZ
> Input Service.
>
> Actually i planned to make the first release last week ... but i run out of
> time. Feel free to give the latest SVN revision a try...
please do releases and do them often. It is important to have releases,
because otherwise nobody really tests the code. Trust me on that one.
Only core developers check out the source from the SCM directly.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Daniel,
As part of our work on Qtopia we've wrapped the BlueZ DBUS interface and some
of the Bluetooth socket types in a nice Qt way. We've also done some work on
OBEX support in Qtopia 4.2, with much nicer API in Qtopia 4.3.
Check out http://doc.trolltech.com/qtopia4.2/qtopiabluetooth.html. If there
are some things which can be used by KDE (beats duplicating effort), I can
work on separating the Bluetooth classes as a separate Solutions package or
something. Same goes for OBEX support.
-Denis
On Monday 28 May 2007 09:19, Daniel Gollub wrote:
> On Sunday 27 May 2007 15:52:30 Gilboa Davara wrote:
> > As some of you may be aware, the current version of kdebluetooth has no
> > support for recent (>= 3.9) bluez DBUS interface.
>
> Thats correct - it's even quite unmaintained for a while...
> I started at the #1 BlueZ Meeting a kdebluetooth-dbus-integration branch:
>
> http://websvn.kde.org/branches/work/kdebluetooth-dbus-integration/
>
> The libkbluetooth got a full rewrite and wraps the full BlueZ DBus API (and
> the Input Service so far ...) - main goal: avoid any linking against
> bluez-libs.
>
> The kio_slaves (kio_bluetooth, kio_sdp) and kcm_btpaired got ported to the
> new libkbluetooth API. The kbluetoothd got rewrite and renamed to
> kbluetooth and is now a "simple" tray icon application like bluez-gnome.
> And acts as (Default) Passkey Agent and Authorization Agent. It also
> includes a (very experimental) bluetooth input device wizard which makes
> use of the BlueZ Input Service.
>
> Actually i planned to make the first release last week ... but i run out of
> time. Feel free to give the latest SVN revision a try...
>
> > As it stands I got two options:
> > A. Use this code as a stop-gate until qt-dbus + kdebluetooth is released
> > (KDE 4?) maintaining this code as a Fedora-only blob.
>
> KDE4, got already some progress in supporting the BlueZ DBus API. There is
> an experimental Solid Management backend for Bluetooth (trunk/kdebase)
> which includes also a DBus based BlueZ. There is still some work left - but
> it has also an initial support for the input service. The
> Passkey/Authorization Agent support is still missing in KDE4, but will be
> implementend hopefully quite soon. Last but not least:
>
> - Juan started porting the kio_slaves for KDE4 based on Solid. He will do
> more work on KDE4 Bluetooth implementation during his GSoC project.
> - Tom Patzig is taking care about the input wizard for KDE3 and most other
> missing UI implementation (services, trusted users, ...) - later also KDE4
> stuff.
>
> I guess one of them will do also the implementation of the
> Passkey/Authorization Agent in the UI - as soon the solid implementation is
> done.
>
> The kdebluetooth-dbus-integration also includes a rewrite of kio_obex
> (called kio_obex2) from the kmobiletools project. kio_obex2 isn't based
> anymore on some own libqobex/libkobex implementation ... just based on
> obexftp and supports finally OBEX transport via USB.
>
> Btw. if there is any issue/problem with the DBus-"SUSE patch" let me know -
> in most cases it's my fault. It's a simple (async) implementation of a
> Default Passkey Agent and seems to work quite well.
>
> best regards,
> Daniel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sunday 27 May 2007 15:52:30 Gilboa Davara wrote:
> As some of you may be aware, the current version of kdebluetooth has no
> support for recent (>= 3.9) bluez DBUS interface.
Thats correct - it's even quite unmaintained for a while...
I started at the #1 BlueZ Meeting a kdebluetooth-dbus-integration branch:
http://websvn.kde.org/branches/work/kdebluetooth-dbus-integration/
The libkbluetooth got a full rewrite and wraps the full BlueZ DBus API (and
the Input Service so far ...) - main goal: avoid any linking against
bluez-libs.
The kio_slaves (kio_bluetooth, kio_sdp) and kcm_btpaired got ported to the new
libkbluetooth API. The kbluetoothd got rewrite and renamed to kbluetooth and
is now a "simple" tray icon application like bluez-gnome. And acts as
(Default) Passkey Agent and Authorization Agent. It also includes a (very
experimental) bluetooth input device wizard which makes use of the BlueZ
Input Service.
Actually i planned to make the first release last week ... but i run out of
time. Feel free to give the latest SVN revision a try...
> As it stands I got two options:
> A. Use this code as a stop-gate until qt-dbus + kdebluetooth is released
> (KDE 4?) maintaining this code as a Fedora-only blob.
KDE4, got already some progress in supporting the BlueZ DBus API. There is an
experimental Solid Management backend for Bluetooth (trunk/kdebase) which
includes also a DBus based BlueZ. There is still some work left - but it has
also an initial support for the input service. The Passkey/Authorization
Agent support is still missing in KDE4, but will be implementend hopefully
quite soon. Last but not least:
- Juan started porting the kio_slaves for KDE4 based on Solid. He will do more
work on KDE4 Bluetooth implementation during his GSoC project.
- Tom Patzig is taking care about the input wizard for KDE3 and most other
missing UI implementation (services, trusted users, ...) - later also KDE4
stuff.
I guess one of them will do also the implementation of the
Passkey/Authorization Agent in the UI - as soon the solid implementation is
done.
The kdebluetooth-dbus-integration also includes a rewrite of kio_obex (called
kio_obex2) from the kmobiletools project. kio_obex2 isn't based anymore on
some own libqobex/libkobex implementation ... just based on obexftp and
supports finally OBEX transport via USB.
Btw. if there is any issue/problem with the DBus-"SUSE patch" let me know - in
most cases it's my fault. It's a simple (async) implementation of a Default
Passkey Agent and seems to work quite well.
best regards,
Daniel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 5/27/07, Petteri R=E4ty <[email protected]> wrote:
> Gilboa Davara kirjoitti:
> > AFAIK there are 3 possibles solutions to this problem.
> > A. Patch bluez-utils' passkey-agent (adding old-style passkey support)
> > B. Use the un-official (?) SUSE patch that adds DBUS support to
> > kdebluetooth.
> > C. Keep kdebluetooth and bluez-utils as they are and create an out-side
> > wrapper.
> >
> > Do you have any idea which course Gentoo used?
> >
> > - Gilboa
> >
>
> http://viewcvs.gentoo.org/viewcvs.py/gentoo-x86/net-wireless/kdebluetooth=
/kdebluetooth-1.0_beta2-r2.ebuild?rev=3D1.1&view=3Dlog
>
A short comment about the OpenSUSE patch.
Unless Gentoo's kdebluetooth maintainer is QT/KDE/CPP programmer, he's
taking an unreasonable risk.
If I'm using a wrapper and something breaks, it's either in the
wrapper code (and I'm the one to blame) or in kdebluetooth (which can
be reported upstream to kmobiletools).
... But if an unsupported patch is used, you're S.O.L.
You can't report the bug upstream (not their code) and you can't
report the bug to SUSE people. (Not their distro)
In short, you get to keep all the broken pieces....
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
On 5/27/07, Marcel Holtmann <[email protected]> wrote:
> Hi Gilboa,
>
> > > I am not
> > > really open for crazy hacks.
> >
> > Why crazy hack?
> >
> > kdebluetooth aside, If -I- (being, among others, the IceWM Fedora
> > maintainer) can use this wrapper (coupled with zenity and/or xdialog)
> > and create a workable out-of-the-box bluetooth experience on IceWM
> > (without the bluez-gnome dep-chain) and other low-end WM's - doesn't it
> > enhance the user experience?
>
> I agree that the bluez-gnome dependency chain is crazy, but that is a
> GNOME issue. However you can write a simple nice passkey agent for every
> windowing system that you wanna use. The scripting part is not a clean
> solution. We should have never used scripts for entering pin codes at
> all, but at that point of time any useful solution was not ready.
OK.
I can't say that I agree (IMHO having bash/scripting support for
right-about-everything is major feature in Linux/Unix - not a
drawback), but I accept the fact the being the upstream-man, you get
to choose what goes in and what doesn't - and this code doesn't.
> > ... And hopefully I took it, expanded it, and put it to good use.
> >
> > At best, I managed to enhance the bluetooth experience on
> > low-end/older/minimal distro/machines/configuration/etc. At worst,
> > (after some clean up) I created yet-another-how-to-do-passkey example.
> >
> > Having said all that, I'm far from forcing the issue down your throat...
> > I merely suggesting. If you don't like the idea, I'll keep it
> > Fedora-only, until a working DBUS patch is released... or until KDE4
> > comes out.
>
> I am fine with having something KDE specific since I don't really care
> about KDE, but this is not solution that is acceptable by Bluez
> upstream.
Just for the sake of the archives, this wrapper is completely generic - it has
nothing KDE (or kdebluetooth) specific in it.
... But as I said, you're the boss...
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Gilboa,
> > I am not
> > really open for crazy hacks.
>
> Why crazy hack?
>
> kdebluetooth aside, If -I- (being, among others, the IceWM Fedora
> maintainer) can use this wrapper (coupled with zenity and/or xdialog)
> and create a workable out-of-the-box bluetooth experience on IceWM
> (without the bluez-gnome dep-chain) and other low-end WM's - doesn't it
> enhance the user experience?
I agree that the bluez-gnome dependency chain is crazy, but that is a
GNOME issue. However you can write a simple nice passkey agent for every
windowing system that you wanna use. The scripting part is not a clean
solution. We should have never used scripts for entering pin codes at
all, but at that point of time any useful solution was not ready.
> > The passkey-agent.c source code is mainly
> > an example on how to write a passkey agent and was used for initial
> > testing.
>
> ... And hopefully I took it, expanded it, and put it to good use.
>
> At best, I managed to enhance the bluetooth experience on
> low-end/older/minimal distro/machines/configuration/etc. At worst,
> (after some clean up) I created yet-another-how-to-do-passkey example.
>
> Having said all that, I'm far from forcing the issue down your throat...
> I merely suggesting. If you don't like the idea, I'll keep it
> Fedora-only, until a working DBUS patch is released... or until KDE4
> comes out.
I am fine with having something KDE specific since I don't really care
about KDE, but this is not solution that is acceptable by Bluez
upstream.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Gilboa Davara kirjoitti:
> AFAIK there are 3 possibles solutions to this problem.
> A. Patch bluez-utils' passkey-agent (adding old-style passkey support)
> B. Use the un-official (?) SUSE patch that adds DBUS support to
> kdebluetooth.
> C. Keep kdebluetooth and bluez-utils as they are and create an out-side
> wrapper.
>
> Do you have any idea which course Gentoo used?
>
> - Gilboa
>
http://viewcvs.gentoo.org/viewcvs.py/gentoo-x86/net-wireless/kdebluetooth/kdebluetooth-1.0_beta2-r2.ebuild?rev=1.1&view=log
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sun, 2007-05-27 at 19:59 +0300, Petteri R=E4ty wrote:
> Gilboa Davara kirjoitti:
> > Hello all,
> > =
> > I'm currently trying to get kdebluetooth reviewed into Fedora Core (and
> > RHEL).
> > As some of you may be aware, the current version of kdebluetooth has no
> > support for recent (>=3D 3.9) bluez DBUS interface.
> =
> Works just fine here.
> http://dev.gentoo.org/~betelgeuse/kdebluetoothpin.png
> =
> betelgeuse@pena /mnt/checkouts/foobar/openjdk-trunk $ emerge --nodeps
> -pv bluez-utils kdebluetooth
> =
> These are the packages that would be merged, in order:
> =
> [ebuild R ] net-wireless/bluez-utils-3.11 USE=3D"cups hal usb -debug
> -examples -old-daemons* -test-programs" 0 kB
> [ebuild R ] net-wireless/kdebluetooth-1.0_beta2-r2 USE=3D"xinerama
> -arts -debug -irmc" LINGUAS=3D"fi -bg -br -ca -cs -cy -da -de -el -en_GB
> -es -et -fr -ga -gl -hu -is -it -ja -ka -lt -mt -nb -nl -nn -pa -pl -pt
> -pt_BR -ro -ru -rw -sk -sr -sr@Latn -sv -ta -tr -uk -zh_CN" 0 kB
> =
> Regards,
> Petteri
> --
> Gentoo Bluez maintainer
AFAIK there are 3 possibles solutions to this problem.
A. Patch bluez-utils' passkey-agent (adding old-style passkey support)
B. Use the un-official (?) SUSE patch that adds DBUS support to
kdebluetooth.
C. Keep kdebluetooth and bluez-utils as they are and create an out-side
wrapper.
Do you have any idea which course Gentoo used?
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
>
> take this up with the KDE Bluetooth guys since it the Bluetooth support
> for KDE 3.x got basically abandoned. It is their job to actually fix it
> and provide whatever they need to make Bluetooth working.
It's their prerogative to spend their efforts on their up-coming KDE4
port.
While I know that SUSE had created a semi-working (at least by my
experience) dbus support, I rather not p*ck around with it, as I have
little experience with QT (and I don't really like CPP) and I'll zero
ability to fix it, if-and-when-things break.
Once it's official, (or once the SUSE patch works for me...) I'll be the
first man to drop this hack.
> I am not
> really open for crazy hacks.
Why crazy hack?
kdebluetooth aside, If -I- (being, among others, the IceWM Fedora
maintainer) can use this wrapper (coupled with zenity and/or xdialog)
and create a workable out-of-the-box bluetooth experience on IceWM
(without the bluez-gnome dep-chain) and other low-end WM's - doesn't it
enhance the user experience?
> The passkey-agent.c source code is mainly
> an example on how to write a passkey agent and was used for initial
> testing.
... And hopefully I took it, expanded it, and put it to good use.
At best, I managed to enhance the bluetooth experience on
low-end/older/minimal distro/machines/configuration/etc. At worst,
(after some clean up) I created yet-another-how-to-do-passkey example.
Having said all that, I'm far from forcing the issue down your throat...
I merely suggesting. If you don't like the idea, I'll keep it
Fedora-only, until a working DBUS patch is released... or until KDE4
comes out.
- Gilboa
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Gilboa,
> I'm currently trying to get kdebluetooth reviewed into Fedora Core (and
> RHEL).
> As some of you may be aware, the current version of kdebluetooth has no
> support for recent (>= 3.9) bluez DBUS interface.
> As an interim solution I decided to write a small wrapper that can be
> used as a bridge between kdebluetooth's kbluepin and bluez-utils 3.9
> (running on the about to be released F7) - basing my work around
> bluez-utils' passkey-agent.
> While working on it I decided to further expand it - making it
> configurable and script-able which in turns, makes it entirely possible
> to create passkey dialog boxes in non-X modes (using 'dialog') or in
> low-end machines with minimal WM's (using 'zenity' in
> IceWM/Fluxbox/etc).
>
> As it stands I got two options:
> A. Use this code as a stop-gate until qt-dbus + kdebluetooth is released
> (KDE 4?) maintaining this code as a Fedora-only blob.
> B. If its of any use to anyone (read, you), get it submitted into
> bluez-utils while maintaining it (and expending it - if so required)
> upstream.
take this up with the KDE Bluetooth guys since it the Bluetooth support
for KDE 3.x got basically abandoned. It is their job to actually fix it
and provide whatever they need to make Bluetooth working. I am not
really open for crazy hacks. The passkey-agent.c source code is mainly
an example on how to write a passkey agent and was used for initial
testing.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Gilboa Davara kirjoitti:
> Hello all,
>
> I'm currently trying to get kdebluetooth reviewed into Fedora Core (and
> RHEL).
> As some of you may be aware, the current version of kdebluetooth has no
> support for recent (>= 3.9) bluez DBUS interface.
Works just fine here.
http://dev.gentoo.org/~betelgeuse/kdebluetoothpin.png
betelgeuse@pena /mnt/checkouts/foobar/openjdk-trunk $ emerge --nodeps
-pv bluez-utils kdebluetooth
These are the packages that would be merged, in order:
[ebuild R ] net-wireless/bluez-utils-3.11 USE="cups hal usb -debug
-examples -old-daemons* -test-programs" 0 kB
[ebuild R ] net-wireless/kdebluetooth-1.0_beta2-r2 USE="xinerama
-arts -debug -irmc" LINGUAS="fi -bg -br -ca -cs -cy -da -de -el -en_GB
-es -et -fr -ga -gl -hu -is -it -ja -ka -lt -mt -nb -nl -nn -pa -pl -pt
-pt_BR -ro -ru -rw -sk -sr -sr@Latn -sv -ta -tr -uk -zh_CN" 0 kB
Regards,
Petteri
--
Gentoo Bluez maintainer
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
