Re: [Bluez-devel] [gbluezconf] D-Bus client prototype

[Marcel Holtmann <marcel@holtmann.org>]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

Hi Claudio,

> The first prototype is available at:
> http://www.cin.ufpe.br/~ckt/gbluezconf/gbluezconf-00.01.tar.gz

it needed some love to make it compile, but I got it somehow. It also
depends on stuff that I haven't committed to the CVS so far. Especially
the missing/uninstalled <bluetooth/dbus.h> header file is a little bit
tricky.

> Main features:
> 1. D-Bus PIN client

I was able to test the PIN dialog and I really like that feature,
because the bluez-pin with D-Bus is basically unmaintained and I would
be happy if it disappears and every desktop or window manager comes with
its own PIN helper client.

> 2. Search Dialog

Wasn't able to get this working.

> Read to RELEASE_NOTES file to see the TODO list.

Let me give some comments on your TODO list.

We should definitiv use libnotify and only display the PIN dialog when
somebody clicked on the bubble. A flashing icon is nice, but I haven't
seen any other Gnome application using flashing icons for that. Might be
also against the HIG.

For the device icons you should contact the Tango team or the Gnome Art
team. Maybe they will come up with some.

The program should start even if no Bluetooth adapter would be found. In
this case only "About" and "Quit" should be visible.

For the configuration dialog and multiple adapters we should maybe use
the proposal from the bluetool screenshot (attached). I think it should
include a page for default/common settings for all devices. And then
some device specific parts that should have an extra check-box to
activate their settings or use the common ones.

Don't forget to make the device name and class of device configurable.

I am also a big fan of Okay/Cancel/Apply style dialogs, but the Gnome
standard is basically only Close (plus a help button) and we should
follow that style. The settings will become immediately active.

The search dialog shouldn't always start with zero devices if a previous
inquiry has already taken place. However I think for this we need to
implement a device cache inside hcid that could be requested up-front.

Besides the inactivity of the icon if no adapter is attached or if no
adapter is up, we maybe should change the icon if we have an active ACL
link. We can also use a different icon or animation if the device is
running an inquiry.

Anyhow, good work, I really like it and keep on coding.

What do you think about creating an own CVS repository for it.

Regards

Marcel


[-- Attachment #2: bluetools.png --]
[-- Type: image/png, Size: 238753 bytes --]