Re: [Bluez-devel] Making library out of bluez-gnome

Antti Kaijanmäki
2008-06-27T06:34:08Z

[-- Attachment #1.1: Type: text/plain, Size: 4541 bytes --]

pe, 2008-06-27 kello 01:42 +0100, Bastien Nocera kirjoitti:
> On Tue, 2008-06-24 at 15:21 +0300, Antti Kaijanmäki wrote:
> > Hello list!
> >
> > I'm developing a project[1] that needs to provide the user a way to
> > select﻿[2] a Bluetooth device from a list of discovered devices.
> >
> > I noticed that gnome-bluez applet has a very nice device selector and
> > that got me browsing though the code. Unfortunately I discovered that
> > bluez-gnome creates only a static library libcommon.a that contains the
> > device selector (common/bluetooth-device-selection.c) for private use.
> >
> > Now there is two options the way I see it. Either I have a private copy
> > of bluez-gnome package or bluez-gnome is made to be a shared library.
> <snip>
>
> The whole problem is making sure the API is good enough for applications
> to use. For example, Marcel wants to allow searching of devices by UUID.
>
> And I'd like to fix up the API to allow adding filters that encompass
> more than a single type of device (eg. input devices would be keyboards,
> mice, joysticks, and other input devices).

I understand all this and as I said the shared library approach is not
the easiest, but it would be the right thing to do. You have done a very
good job and I just wanted to let you know what I'm up to. For now I
will use a private copy of the files and someday when a shared library
is released I will switch to that.

> > Here are some wishes from top of my head regarding the device selector:
> > 1. remove the caption of the list
> > - let the developer provide a caption best suited for
> > his application
>
> That's already possible, you set it when calling
> bluetooth_device_selection_new().

I'm now talking about the "Select a device from the following list:"
caption. And calling bluetooth_device_selection_new(""); will only set
the boldface title to be an empty string that is still getting widget
space allocated to it.

> > 2. put the filter in GtkExpander
> > - Filters are not used for by the most of the users, thus it's
> > convenient to have them hidden by default.
>
> Why?

It was just a thought. GtkExpander lets you hide these "Advanced"
options so that Aunt Tillie does not get confused by them, but it's
clearly visible where they can be found when someone needs them. At
least I got the idea from your blog post[1] that this is truly needed
for a marginal use case.

> > 3. make the filter completely hidden
> > - this combined with the 1. would make the widget appear just
> > like GtkTreeView
> > - this is already achievable, but there seems to be a bug. If both of
> > the filter fields are hidden the caption is still shown.
> > See an attached patch.
>
> I don't see what the problem is here.

﻿You don't see why the widget should appear just like GtkTreeView or you
don't see what's the problem that my patch addresses?

If the widget can be made to look just like an ordinary GtkTreeView then
the application developer could embed it where ever he wants and make it
fit to his GUI design better. Those additional captions and titles can
brake the integrity of the GUI if there is no option to remove them.

By caption I mean the "Show Only Bluetooth Devices With..."
Without my patch this caption is still visible even though there are no
filters visible.

> > 4. have alternative filters in right-click pop-up menu
> > - very handy for tight places
>
> I'm not sure that's useful.

I mean this would be for situations where there is no room for filters
below the treeview, but the pop-up menu would provide the user an access
to them.

> > 5. add property for selected device name. It's always nice to be able
> > to show the user a nice name instead of bluetooth address.
> > - see an attached patch.
>
> That's useful, as it allows us to avoid another lookup, although it's
> close to free as hcid would have cached it.

True, but then yet another API must be used to make the lookup.

> FYI, you're leaking a copy of the name though, as gtk_tree_model_get()
> will make a copy of the value, as well as g_value_set_string(). Use
> g_value_take_string().

Yes, true. thanks! I thought that g_value_set_string() would not make a
copy of the string. I just adapted the "device-selected" property so I
suppose it's also leaking memory.

Br,
Antti

[1] http://www.hadess.net/2007/11/gnome-bluetooth-kill-kill.html

[-- Attachment #1.2: Digitaalisesti allekirjoitettu viestin osa --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 247 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]