Hello, all!
I have attached a patch against 0.27 (it applies cleanly against CVS) to
complete the wizard in the bluez-gnome source tree.
Here's what my patch does in summary, details below:
Wizard dialog shows list of device types we know how to handle (only
mouse/keyboard/headset right now). Then, it tries to connect to the
appropriate bluetooth dbus service and trust the device. Basically the
same code steps the Properties -> Services tab does, but more
wizardy. :)
I made changes to cleanup the wizard interface (removed a couple of
pages that had low signal/noise ratio) and made several of the
bluetooth_client capable of giving feedback about the operation via a
callback.
Details of changes:
applet/main.c:
Uncomments code to add a menu item for the wizard.
common/bluetooth-device-selection.c:
Fixes broken code to set current filter programmatically.
common/client.[ch]:
setup_services():
Note presence of audio and input services on startup
bluetooth_client_get_name():
Gets user-visible device name for a path
bluetooth_client_available_services():
Returns a mask of the device types supported by services the client
knows about. Not actually used by the rest of my code, but it seemed
possibly useful to one day not show unsupported device types in the
wizard if we wanted to.
bluetooth_client_cancel_call():
Cancels an async call for a particular adapter/address combo. This is
slightly janky because it only allows for one call at a time per pair,
but that's all that we ever need right now.
connect_to_service():
Handles service-specific calls to initiate a device connection. Stuff
like CreateSecureDevice or CreateHeadset.
bluetooth_client_connect():
Kicks off a call to connect_to_service
bluetooth_client_create_bonding():
bluetooth_client_remove_bonding():
bluetooth_client_set_trusted():
bluetooth_client_remove_trust():
Modified to allow callbacks
common/dbus.xml:
Add input.CreateSecureDevice and audio.CreateHeadset
properties/adapter.c:
Update a few calls to client functions do to above prototype changes
wizard/agent.[ch]:
Mostly a copy of applet/agent.c, except:
it only holds passkey code (no auth code)
it shows dialogs immediately wrt a parent window
wizard/main.c:
Comment out intro and info pages -- I think the intro page just gets in
the user's way and there was no content in info page, and even if there
was, it would probably also just get in user's way.
I added a pulsing progress bar to the pairing page to give some
feedback.
I changed wording from 'setup' and 'pair' to 'connect'. I figure that
is more user-friendly (since no real setting up is done by user and they
probably think in terms of connecting to devices not pairing with them).
Pairing process is two-step: bluetooth_client_connect followed by
bluetooth_client_set_trusted.
Show an error if either step fails.
Connect to agent code to display a password prompt immediately in front
of user instead of via bluetooth applet.
wizard/Makefile.am:
Install bluetooth-wizard and add agent.[ch]
Thanks!
-mt
Michael:
If you decide to move away from evolution, here's for t-bird:
https://addons.mozilla.org/en-US/thunderbird/addon/5759
Regards
Michael Terry wrote:
> On Mon, 2008-06-30 at 15:58 -0400, Michael Terry wrote:
>
>> Here's an updated services patch, to go along with the changes in callback2.diff. I'll wait to provide an updated wizard-ui.diff until I get feedback.
>>
>
> Guh, I need that plugin that warns me about not attaching files. :)
>
> Actually attached now.
>
> -mt
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Mario Limonciello
*Dell | Linux Engineering*
[email protected]
On Mon, 2008-06-30 at 16:01 -0400, Michael Terry wrote:
> On Mon, 2008-06-30 at 15:58 -0400, Michael Terry wrote:
> > Here's an updated services patch, to go along with the changes in
> callback2.diff. I'll wait to provide an updated wizard-ui.diff until
> I get feedback.
>
> Guh, I need that plugin that warns me about not attaching files. :)
Edit->Plugins->Attachment Reminder in Evo.
> Actually attached now.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2008-06-30 at 15:58 -0400, Michael Terry wrote:
> Here's an updated services patch, to go along with the changes in callback2.diff. I'll wait to provide an updated wizard-ui.diff until I get feedback.
Guh, I need that plugin that warns me about not attaching files. :)
Actually attached now.
-mt
On Mon, 2008-06-30 at 09:51 -0400, Michael Terry wrote:
> On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> > looks nice. However you have to break this up into pieces for. Sent
> > small patches and I can quickly review and commit them.
>
> Here's a patch to add support for connecting to devices via the client code. This patch depends on the callback patch.
Here's an updated services patch, to go along with the changes in callback2.diff. I'll wait to provide an updated wizard-ui.diff until I get feedback.
-mt
On Mon, 2008-06-30 at 18:03 +0200, Marcel Holtmann wrote:
> > Except that one of my other patches adds a new cancelable function
> > _connect(). So we would need maybe specific cancel_bonding and
> > cancel_connect functions.
>
> sounds good to me. The bonding case is special since it can only do one
> at a time.
OK, attached is callback2.diff, which only allows canceling a create_bonding call. Updated other patches to follow.
-mt
Hi Michael,
> > > It also adds a new function: bluetooth_client_cancel_call(). This
> > > cancels the last client call made for the given adapter/address.
> [snip]
> > it only makes sense for the create bonding call, because the others
> > can't really be canceled. So my proposal is to leave the others out of
> > this change and implement create_bonding and cancel_bonding.
>
> Except that one of my other patches adds a new cancelable function
> _connect(). So we would need maybe specific cancel_bonding and
> cancel_connect functions.
sounds good to me. The bonding case is special since it can only do one
at a time.
> But why can't the others be canceled? Just on the assumption that the
> DBus communication will be so fast as to not really allow time for
> canceling? Or that by the time you send the message, it's all said and
> done anyway? I don't understand the nitty gritty details of dbus async
> communication.
>
> I figured that as a matter of principle, if you have an async API like
> this, it ought to allow for canceling because the very nature of async
> suggests a period of time in which your program is doing other things,
> one of which could conceivably trigger a cancel.
It will give you no advantage whatsoever. So not worth it.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2008-06-30 at 16:06 +0200, Marcel Holtmann wrote:
> > It also adds a new function: bluetooth_client_cancel_call(). This
> > cancels the last client call made for the given adapter/address.
[snip]
> it only makes sense for the create bonding call, because the others
> can't really be canceled. So my proposal is to leave the others out of
> this change and implement create_bonding and cancel_bonding.
Except that one of my other patches adds a new cancelable function
_connect(). So we would need maybe specific cancel_bonding and
cancel_connect functions.
But why can't the others be canceled? Just on the assumption that the
DBus communication will be so fast as to not really allow time for
canceling? Or that by the time you send the message, it's all said and
done anyway? I don't understand the nitty gritty details of dbus async
communication.
I figured that as a matter of principle, if you have an async API like
this, it ought to allow for canceling because the very nature of async
suggests a period of time in which your program is doing other things,
one of which could conceivably trigger a cancel.
But I agree it's largely a moot case for something like _remove_trust().
I just figured it would be cleaner to do the set of them.
-mt
On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> looks nice. However you have to break this up into pieces for. Sent
> small patches and I can quickly review and commit them.
And here's the actual wizard UI patch. It's a bit large, but not
terribly break-down-able.
It adds the passkey code for the UI and modifies the UI a bit, as I
mentioned in previous emails.
It also adds a call to the client code to get an address's user-visible
name from its path.
Bastien suggested that the applet label to launch the wizard should
continue to be "Setup" and not "Connect" because we may want to do more
setup for certain device types in the future. That may be true, but
some of that would be automatic (like the SyncML example he cited) and
so wouldn't be visible from the user's perspective.
Even if we did add a page for some sort of device configuration, I
maintain that the overriding user metaphor will be connecting not
configuring.
-mt
On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> looks nice. However you have to break this up into pieces for. Sent
> small patches and I can quickly review and commit them.
Here's a patch to add support for connecting to devices via the client code. This patch depends on the callback patch.
It finds known services on startup (in setup_services()). Bastien
suggested that we don't need to call setup_services() since those
services are enabled by default, but I'm not quite sure what he meant.
We need to call it to get the service bus IDs so that we can then get
DBusGProxies for them.
It adds the function bluetooth_client_available_services() which gives
back a type mask for services that were detected. Basically which
devices are likely to succeed from a bluetooth_client_connect() call.
bluetooth_client_connect() does device-specific connection handling.
It only handles a few types right now (input and headset).
-mt
Hi Michael,
> > please use the coding style that is present in the file you are
> > working
> > on. This includes whitespaces and indentation.
>
> Sure. I thought I did, but I missed a tab, which is what I assume you
> were referring to?
>
> Tab-complete patch attached.
there was one SOMETHING-1 where you should have done SOMETHING - 1. I
fixed that and the patch has been committed.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Michael,
> > looks nice. However you have to break this up into pieces for. Sent
> > small patches and I can quickly review and commit them.
>
> Here's a patch to add callback support to many of the common/client
> calls.
>
> It also adds a new function: bluetooth_client_cancel_call(). This
> cancels the last client call made for the given adapter/address.
>
> Admittedly, it would be fancier if, for example,
> bluetooth_client_create_bonding() gave back a handle which could be used
> to cancel its call, rather than just keeping track of the last one.
it only makes sense for the create bonding call, because the others
can't really be canceled. So my proposal is to leave the others out of
this change and implement create_bonding and cancel_bonding.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2008-06-30 at 14:57 +0200, Marcel Holtmann wrote:
> please use the coding style that is present in the file you are
> working
> on. This includes whitespaces and indentation.
Sure. I thought I did, but I missed a tab, which is what I assume you
were referring to?
Tab-complete patch attached.
-mt
On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> looks nice. However you have to break this up into pieces for. Sent
> small patches and I can quickly review and commit them.
Here's a patch to add callback support to many of the common/client
calls.
It also adds a new function: bluetooth_client_cancel_call(). This
cancels the last client call made for the given adapter/address.
Admittedly, it would be fancier if, for example,
bluetooth_client_create_bonding() gave back a handle which could be used
to cancel its call, rather than just keeping track of the last one.
But the cancel-last-call style was simpler and sufficient for the
wizard's purposes and presumably sufficient for others' purposes (by
virtue of the lack of canceling before).
-mt
Hi Michael,
> On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> > looks nice. However you have to break this up into pieces for. Sent
> > small patches and I can quickly review and commit them.
>
> Here's one such piece of my wizard patch. It simply fixes the "device-type-filter" property to do something reasonable when set (namely, you give it a BLUETOOTH_TYPE and it sets the right index in the combo).
please use the coding style that is present in the file you are working
on. This includes whitespaces and indentation.
> More patches coming.
Send them over.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi, Marcel!
On Sat, 2008-06-28 at 00:23 +0200, Marcel Holtmann wrote:
> looks nice. However you have to break this up into pieces for. Sent
> small patches and I can quickly review and commit them.
Here's one such piece of my wizard patch. It simply fixes the "device-type-filter" property to do something reasonable when set (namely, you give it a BLUETOOTH_TYPE and it sets the right index in the combo).
More patches coming.
-mt
On Fri, 2008-06-27 at 15:05 -0400, Michael Terry wrote:
> Hello, all!
>
> I have attached a patch against 0.27 (it applies cleanly against CVS) to
> complete the wizard in the bluez-gnome source tree.
- item = gtk_menu_item_new_with_label(_("Setup New Device"));
+ item = gtk_menu_item_new_with_label(_("Connect New Device..."));
This is wrong, as we'll probably want to plug in more setup for future
device types. For example, when adding a phone, we'll want to check
whether it supports SyncML, and automatically set it up in the sync
program.
The setup_services() service call shouldn't be needed, as all the
services are enabled by default.
In bluetooth_client_available_services(), you also need to add joypads,
and every other input devices to that list.
+ // If caller didn't specify a forced type, determine it from device
info
Don't use C++-style comments.
I personally don't really like adding setup calls in client.c, which
should really only be used for discovery.
The rest looks alright to me, looking over it quickly.
Cheers
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Michael,
> I have attached a patch against 0.27 (it applies cleanly against CVS) to
> complete the wizard in the bluez-gnome source tree.
>
> Here's what my patch does in summary, details below:
> Wizard dialog shows list of device types we know how to handle (only
> mouse/keyboard/headset right now). Then, it tries to connect to the
> appropriate bluetooth dbus service and trust the device. Basically the
> same code steps the Properties -> Services tab does, but more
> wizardy. :)
>
> I made changes to cleanup the wizard interface (removed a couple of
> pages that had low signal/noise ratio) and made several of the
> bluetooth_client capable of giving feedback about the operation via a
> callback.
looks nice. However you have to break this up into pieces for. Sent
small patches and I can quickly review and commit them.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Whoops, here's a fixed patch that actually installs the binary.
-mt
Hello, Marcel.
On Tue, 2008-07-01 at 03:10 +0200, Marcel Holtmann wrote:
> please only change create_bonding and leave the others alone. Also you
> cast a little bit too much for my taste. For example void pointers
> need
> to extra cast.
Attached is callback3.diff which only modifies create_bonding.
I'm not sure which casts you felt were unnecessary. I don't think I
cast any void pointers.
-mt
Hello David,
>>Hello Luis
> I read the docs and when the code works as expected it is good enough.
> However, I have had a number of problems making the code work =
> (partially
> implemented "experimental" 4.x features in release 3.33 and before).
You should first understand that the documentation in doc/ are dbus
specifications, they are not normal method calls or gobject signals.
You seems to be confused by using dbus-glib and not really knowing
what dbus is doing, we don't document how to use the API in terms of
language bindings, because it is open to the application developer to
choose between the bindings and the binding itself should document how
it map the different signatures.
>> REPLY (sorry, but Outlook SUX)
>> I appreciate that fact. I also recognize that Python does an awful =
>> lot for the user, and that perhaps I could develop all of this in =
>> Python...but at this point, I am choosing to use C/C++ and hence, =
>> must use the GLib binding.
>> Really, my comment was about the fact that some of the features =
>> documented in the /doc directory are not quite working, and in fact =
>> are still coming into existance. As a result, when I run into a =
>> problem I cannot figure out what is really going on (is it my code, =
>> or is it something missing in Bluez) without digging through the =
>> Bluez source. Which has very little documentation (even at the file =
>> level). Again, when everything is working, the doc files will be =
>> fine. Just, for now, they are not quite enough.
>> The question you may be asking is why I do not just develop to the =
>> 3.x API? Why would I do that when in just a few months I would have =
>> to throw all of that away? (See: bluez-gnome).
> Also, figuring out how to handle some of the formats (e.g., the "dict"
> with variant) are a bit hard to figure out without a code example. =
> SO,
> I often have to dig into the actual code and figure out just what is
> going on.
See my point here, just because dbus-glib maps the signature a{sv}
(that is the real "dict") to a GHashTable using a GValue doesn't mean
any other binding will do the same. It's up to the binding to provides
this kind of documentation not the dbus API which should not be tied
to a single binding.
>> Got it, frankly the Glib binding docs are not very complete. As with =
>> most programs, the documentation handles the most simplistic cases, =
>> and ignores the fact that someone might Actually Want To Use It. I =
>> did find the DBUS Test directory and got a lot of help from seeing =
>> how the validation tests were coded.
This tutorial should cover what you want:
http://dbus.freedesktop.org/doc/dbus-tutorial.html
>> I have read this tutorial in detail and understood it. However, the =
>> coverage was still inadequate for a{sv} (dict) and array{string} =
>> ({as}). At one point, I also had problems with object paths, but =
>> again, with Marcel giving me a hint as to the proper incantation, I =
>> was able to work that out.
>> That said, after finding a few more-complex code examples (especially =
>> the validation code), I have now figured the structures out. =
>> Everything I need to do for now is (apparently) working, and now I am =
>> moving on to getting SSP going between Bluez and my device =
>> (programmed with the CSR BT stack).
>> Thanks again for your response.
-- =
Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Michael,
> > looks nice. However you have to break this up into pieces for. Sent
> > small patches and I can quickly review and commit them.
>
> And here's the actual wizard UI patch. It's a bit large, but not
> terribly break-down-able.
first of all the bluetooth_client_get_name part should be a separate
patch.
Then the modification to the applet code to show the extra entry can be
a separate patch, too.
Same goes for the part where you actually enable the installation of the
bluetooth-wizard program.
Leave these all out, because I don't bother and we will apply them once
the UI change is committed.
> It adds the passkey code for the UI and modifies the UI a bit, as I
> mentioned in previous emails.
Lets do the UI changes without the passkey stuff. We should get the
wizard working. If no device specific passkey is provided, it will fall
back to the applet anyway and that is fine for the first step.
I also don't like that you copy the agent.[ch] files. This needs some
extra thinking and hence first the UI and then the agent part.
> Bastien suggested that the applet label to launch the wizard should
> continue to be "Setup" and not "Connect" because we may want to do more
> setup for certain device types in the future. That may be true, but
> some of that would be automatic (like the SyncML example he cited) and
> so wouldn't be visible from the user's perspective.
I am for "Setup. Using "Connect" is wrong here. If you wanna connect to
a previously setup device, then we have to add shortcuts to the applet
menu to do so.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
SGkgTWljaGFlbCwKCj4gPiBsb29rcyBuaWNlLiBIb3dldmVyIHlvdSBoYXZlIHRvIGJyZWFrIHRo
aXMgdXAgaW50byBwaWVjZXMgZm9yLiBTZW50Cj4gPiBzbWFsbCBwYXRjaGVzIGFuZCBJIGNhbiBx
dWlja2x5IHJldmlldyBhbmQgY29tbWl0IHRoZW0uCj4gCj4gSGVyZSdzIGEgcGF0Y2ggdG8gYWRk
IHN1cHBvcnQgZm9yIGNvbm5lY3RpbmcgdG8gZGV2aWNlcyB2aWEgdGhlIGNsaWVudCBjb2RlLiAg
VGhpcyBwYXRjaCBkZXBlbmRzIG9uIHRoZSBjYWxsYmFjayBwYXRjaC4KPiAKPiBJdCBmaW5kcyBr
bm93biBzZXJ2aWNlcyBvbiBzdGFydHVwIChpbiBzZXR1cF9zZXJ2aWNlcygpKS4gIEJhc3RpZW4K
PiBzdWdnZXN0ZWQgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIGNhbGwgc2V0dXBfc2VydmljZXMoKSBz
aW5jZSB0aG9zZQo+IHNlcnZpY2VzIGFyZSBlbmFibGVkIGJ5IGRlZmF1bHQsIGJ1dCBJJ20gbm90
IHF1aXRlIHN1cmUgd2hhdCBoZSBtZWFudC4KPiBXZSBuZWVkIHRvIGNhbGwgaXQgdG8gZ2V0IHRo
ZSBzZXJ2aWNlIGJ1cyBJRHMgc28gdGhhdCB3ZSBjYW4gdGhlbiBnZXQKPiBEQnVzR1Byb3hpZXMg
Zm9yIHRoZW0uCgpzbyBzdGFydGluZyB3aXRoIGJsdWV6LXV0aWxzLTMuMzMgZXZlcnl0aGluZyBp
cyBhIHBsdWdpbiBhbmQgd2lsbCBiZQphdmFpbGFibGUgdW5kZXIgdGhlIG9yZy5ibHVleiBzZXJ2
aWNlIG5hbWUuIFNvIHdlIGNvdWxkIHNpbXBseSBpZ25vcmUKdGhpcyBhbmQgZmFpbCB0aGUgb3Ro
ZXIgY2FzZXMuCgpJZiB5b3Ugd2FubmEgY2hlY2sgYXZhaWxhYmxlIHNlcnZpY2VzIHRoZW4geW91
IHNob3VsZCB1c2UgTGlzdFNlcnZpY2VzCmFuZCByZXRyaWV2ZSB0aGUgc2VydmljZSBvYmplY3Rz
LiBPbiB0aGVzZSBvYmplY3RzIHlvdSBjYW4gYWxzbyBjYWxsCkdldEJ1c05hbWUgdG8gZ2V0IHRo
ZSBidXMgbmFtZSBvZiB0aGUgc2VydmljZS4gVGhpcyB3aWxsIHRoZW4gb25seSB3b3JrCmZvciBh
Y3RpdmF0ZWQgc2VydmljZXMsIGJ1dCB0aGF0IGlzIGFjdHVhbGx5IGZpbmUuIFRoZSBkaXN0cm9z
IGVuYWJsZQp0aGVtIGJ5IGRlZmF1bHQgYW55d2F5IG9yIHRoZXkgYXJlIHBsdWdpbnMgYW5kIGxv
YWRlZCBhbGwgdGhlbS4KCj4gSXQgYWRkcyB0aGUgZnVuY3Rpb24gYmx1ZXRvb3RoX2NsaWVudF9h
dmFpbGFibGVfc2VydmljZXMoKSB3aGljaCBnaXZlcwo+IGJhY2sgYSB0eXBlIG1hc2sgZm9yIHNl
cnZpY2VzIHRoYXQgd2VyZSBkZXRlY3RlZC4gIEJhc2ljYWxseSB3aGljaAo+IGRldmljZXMgYXJl
IGxpa2VseSB0byBzdWNjZWVkIGZyb20gYSBibHVldG9vdGhfY2xpZW50X2Nvbm5lY3QoKSBjYWxs
Lgo+IAo+IO+7v2JsdWV0b290aF9jbGllbnRfY29ubmVjdCgpIGRvZXMgZGV2aWNlLXNwZWNpZmlj
IGNvbm5lY3Rpb24gaGFuZGxpbmcuCj4gSXQgb25seSBoYW5kbGVzIGEgZmV3IHR5cGVzIHJpZ2h0
IG5vdyAoaW5wdXQgYW5kIGhlYWRzZXQpLgoKUGxlYXNlIHN0b3AgdXNpbmcgdGhlIHZhcmlhYmxl
IG5hbWUgcnYgZm9yIHJldHVybiB2YWx1ZS4gRWl0aGVyIHVzZSBlcnIKb3IgY2FsbCBpdCByZXN1
bHQgb3Igc29tZXRoaW5nLgoKUmVnYXJkcwoKTWFyY2VsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ2hl
Y2sgb3V0IHRoZSBuZXcgU291cmNlRm9yZ2UubmV0IE1hcmtldHBsYWNlLgpJdCdzIHRoZSBiZXN0
IHBsYWNlIHRvIGJ1eSBvciBzZWxsIHNlcnZpY2VzIGZvcgpqdXN0IGFib3V0IGFueXRoaW5nIE9w
ZW4gU291cmNlLgpodHRwOi8vc291cmNlZm9yZ2UubmV0L3NlcnZpY2VzL2J1eS9pbmRleC5waHAK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQmx1ZXotZGV2
ZWwgbWFpbGluZyBsaXN0CkJsdWV6LWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRwczov
L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9ibHVlei1kZXZlbAo=
Hi Michael,
> > > Except that one of my other patches adds a new cancelable function
> > > _connect(). So we would need maybe specific cancel_bonding and
> > > cancel_connect functions.
> >
> > sounds good to me. The bonding case is special since it can only do one
> > at a time.
>
> OK, attached is callback2.diff, which only allows canceling a create_bonding call. Updated other patches to follow.
please only change create_bonding and leave the others alone. Also you
cast a little bit too much for my taste. For example void pointers need
to extra cast.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Poke!
This has been languishing here for a over a month. Could it please get reviewed, so I can post the rest of the wizard patches?
-mt
On Wed, 2008-07-09 at 10:28 -0400, Michael Terry wrote:
> Hello, Marcel.
>
> On Tue, 2008-07-01 at 03:10 +0200, Marcel Holtmann wrote:
> > please only change create_bonding and leave the others alone. Also you
> > cast a little bit too much for my taste. For example void pointers
> > need
> > to extra cast.
>
> Attached is callback3.diff which only modifies create_bonding.
>
> I'm not sure which casts you felt were unnecessary. I don't think I
> cast any void pointers.
>
> -mt
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________ Bluez-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bluez-devel