bluetooth: Create stub manager, adapter and device.

bluetooth: Create stub manager, adapter and device.

These stub classes are used when building Chrome on Linux with
chromeos=1. They allow sufficient UI to work to show a Bluetooth
adapter, enable and disable it, and show an unconnected fake device
associated with it.

This can be trivially extended to provide all manner of fake
Bluetooth information for UI development.

BUG=chromium-os:28555
TEST=out/Debug/chrome

Change-Id: I7af28be76355fad735389aaf2fa499d0a8dfd76b


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=151621

[keybuk, 2012-08-14 00:00:07]

satorux: please verify the dbus/ change
kevers: please verify the stubs

[kevers, 2012-08-14 12:59:37]

On 2012/08/14 00:00:07, keybuk wrote:
> satorux: please verify the dbus/ change
> kevers: please verify the stubs

Stubs LGTM.

[bryeung, 2012-08-14 13:10:29]

lgtm

just a couple of nits

https://chromiumcodereview.appspot.com/10823301/diff/1/chromeos/dbus/bluetoot...
File chromeos/dbus/bluetooth_adapter_client.cc (right):

https://chromiumcodereview.appspot.com/10823301/diff/1/chromeos/dbus/bluetoot...
chromeos/dbus/bluetooth_adapter_client.cc:743: VLOG(1) << "Get " <<
property->name();
Probably better as DVLOG?

https://chromiumcodereview.appspot.com/10823301/diff/1/chromeos/dbus/bluetoot...
chromeos/dbus/bluetooth_adapter_client.cc:893: // List of observers interested
in event notifications from us.
looks like this belongs with the variable below

https://chromiumcodereview.appspot.com/10823301/diff/1/chromeos/dbus/bluetoot...
File chromeos/dbus/bluetooth_device_client.cc (right):

https://chromiumcodereview.appspot.com/10823301/diff/1/chromeos/dbus/bluetoot...
chromeos/dbus/bluetooth_device_client.cc:508: // Clean up Properties structures
This could be done with STLDeleteContainerPairSecondPointers

[satorux1, 2012-08-14 16:54:18]

LGTM with nits. mostly VLOG->DVLOG.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
File chromeos/dbus/bluetooth_adapter_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:734: explicit
Properties(PropertyChangedCallback callback)
you can  make it const PropertyChangedCallback&

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:743: VLOG(1) << "Get " <<
property->name();
On 2012/08/14 13:10:29, bryeung wrote:
> Probably better as DVLOG?

agreed

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:748: VLOG(1) << "GetAll";
ditto. please fix other places too.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:896:
AdapterPropertyChanged(dbus::ObjectPath("/fake/hci0"),
I saw this before. you might want to define constants for the fake stuff.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
File chromeos/dbus/bluetooth_device_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:468: explicit
Properties(PropertyChangedCallback callback)
const PropertyChangedCallback&

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:508: // Clean up Properties structures
On 2012/08/14 13:10:30, bryeung wrote:
> This could be done with STLDeleteContainerPairSecondPointers

You meant STLDeleteValues?

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:576: // List of observers interested in
event notifications from us.
move this to |observers_|; below?

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_manage...
File chromeos/dbus/bluetooth_manager_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_manage...
chromeos/dbus/bluetooth_manager_client.cc:277: explicit
Properties(PropertyChangedCallback callback)
const &

[keybuk, 2012-08-14 17:40:31]

PTAL and see questions below

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
File chromeos/dbus/bluetooth_adapter_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:734: explicit
Properties(PropertyChangedCallback callback)
On 2012/08/14 16:54:19, satorux1 wrote:
> you can  make it const PropertyChangedCallback&

Done.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:743: VLOG(1) << "Get " <<
property->name();
we've argued about this before - these are used only in the chromeos=1 on Linux
case, which are often release builds which is why they're not DVLOG - so UI
designers can verify the buttons would do something when clicked

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:893: // List of observers interested
in event notifications from us.
On 2012/08/14 13:10:29, bryeung wrote:
> looks like this belongs with the variable below

Done.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:896:
AdapterPropertyChanged(dbus::ObjectPath("/fake/hci0"),
I couldn't find a useful place to put them, since they're spread across the
different files - thoughts?

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
File chromeos/dbus/bluetooth_device_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:468: explicit
Properties(PropertyChangedCallback callback)
On 2012/08/14 16:54:19, satorux1 wrote:
> const PropertyChangedCallback&

Done.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:508: // Clean up Properties structures
On 2012/08/14 16:54:19, satorux1 wrote:
> On 2012/08/14 13:10:30, bryeung wrote:
> > This could be done with STLDeleteContainerPairSecondPointers
> 
> You meant STLDeleteValues?

Done.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_device...
chromeos/dbus/bluetooth_device_client.cc:576: // List of observers interested in
event notifications from us.
On 2012/08/14 16:54:19, satorux1 wrote:
> move this to |observers_|; below?

Done.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_manage...
File chromeos/dbus/bluetooth_manager_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_manage...
chromeos/dbus/bluetooth_manager_client.cc:277: explicit
Properties(PropertyChangedCallback callback)
On 2012/08/14 16:54:19, satorux1 wrote:
> const &

Done.

[bryeung, 2012-08-14 17:44:39]

Thanks for the context about the logs: makes sense to me.  lgtm

[satorux1, 2012-08-14 17:52:04]

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
File chromeos/dbus/bluetooth_adapter_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:743: VLOG(1) << "Get " <<
property->name();
On 2012/08/14 17:40:32, keybuk wrote:
> we've argued about this before - these are used only in the chromeos=1 on
Linux
> case, which are often release builds which is why they're not DVLOG - so UI
> designers can verify the buttons would do something when clicked

IIRC, the reason why DVLOG(1) is preferred was that every VLOG line adds non
negligible bytes to the shipping binary (the number of bytes used in the string
literal + some code generated for the log macro).

I guess that the UI designers (maybe UI engineers?) can build a Debug binary
instead of a Release binary.

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:896:
AdapterPropertyChanged(dbus::ObjectPath("/fake/hci0"),
On 2012/08/14 17:40:32, keybuk wrote:
> I couldn't find a useful place to put them, since they're spread across the
> different files - thoughts?

You could add a new file like bluetooth_stub_constants.h, but I guess it's
overkill.

[keybuk, 2012-08-14 17:58:46]

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
File chromeos/dbus/bluetooth_adapter_client.cc (right):

http://codereview.chromium.org/10823301/diff/1/chromeos/dbus/bluetooth_adapte...
chromeos/dbus/bluetooth_adapter_client.cc:743: VLOG(1) << "Get " <<
property->name();
UI designers don't build anything

[commit-bot: I haz the power, 2012-08-14 18:10:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/keybuk@chromium.org/10823301/8001

[commit-bot: I haz the power, 2012-08-14 18:23:28]

Try job failure for 10823301-8001 (retry) on win for step "runhooks".
It's a second try, previously, step "runhooks" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...

[commit-bot: I haz the power, 2012-08-14 18:29:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/keybuk@chromium.org/10823301/8001

[commit-bot: I haz the power, 2012-08-14 20:00:20]

Try job failure for 10823301-8001 (retry) on mac_rel for step
"interactive_ui_tests".
It's a second try, previously, step "interactive_ui_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2012-08-14 20:28:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/keybuk@chromium.org/10823301/8001

[commit-bot: I haz the power, 2012-08-15 01:03:31]

Change committed as 151621