[gnome-bluetooth] What stuff in gnome-bluetooth does, and ideas for its future

[Edd Dumbill]

On Mon, 2003-11-03 at 18:07, Bastien Nocera wrote:
> Hello Edd, and list,
> 
> I thought I'd answer to that mail directly, explains what we have right
> now, and where we should be heading (that's my ideas, and opinion,
> nothing to do with what Edd has planned).
> 
> For mucho screenies and ideas (the Ericsson GUI is what *not* to do ;)
> http://www.oreillynet.com/pub/a/wireless/2002/08/13/bluetooth_osx.html

I actually think we can do better than OS X.  I'm quite proud of the
fact that I originally conceived some of this stuff before OS X had
Bluetooth support.  Of course, they're ahead now, but that's how it goes
:-)

OS X does raise one interesting issue, however, which is pairing.  We
really want to be able to indicate to the user which devices are paired,
as non-paired devices are a common source of otherwise inexplicable
failure.  At the moment the BlueZ hcid has control of this.  We need a
way of finding out for which bdaddrs it has a key.  Currently this
information is stored in /etc/bluetooth/link_key and readable only by
root, so we've some progress to make there.  I might bring this up on
the bluez list.

> >  - daemon that listens for OBEX PUSH requests and receives the files.
> >    future: could support OBEX FTP and offer file-sharing via Bluetooth
> >            on a directory the user chooses.
> 
> Maybe integrate that in the file sharing in gnome-network?
> It should really be integrated into something bigger. That's either
> that, or integration in a bigger bluetooth control center.

It's starting to seem like a bigger bluetooth control center is going to
be required.  There'll be a few more prefs on the way, such as what
policy to adopt for file transfers (always accept/ask/never accept) and
so on.

I think we need a few more iterations to see properly where we might fit
into gnome-network.  For a start, we'd need to get proposed at least
into fifth toe :)  (And I think it's just a tad too early for that yet.)

> > obex/gnome-obex-send
> > 
> >  - a GUIified OBEX PUSH client.
> 
> We probably need this to be independant from the rest. Should it be the
> same as the nautilus thing?

Yes, I meant the nautilus thing by this.

> 
> > python/gnome-bluetooth-admin
> > 
> >  - the new admin tool, early stage.  
> >    future: will allow exploration of remote Bluetooth devices and their
> >    capabilities.  Its closest analog in GNOME already is the printman
> >    stuff.
> 
> That's what we need to grow.

Starting to work on this a bit more now I've done some of the lower
level aspects.  The main display is an iconlist, I figure a properties
dialog with two sheets for each device: one showing the user prefs for
that device (paired, access control, hidden) and one showing what
services are supported.  I reckon nautilus-like emblems could be used on
the iconlist to indicate these properties quickly, especially pairing.

> > nautilus/*
> > 
> >  - this makes a "Send via Bluetooth" context menu option appear in
> > Nautilus.
> 
> Shows up the chooser, and sends the stuff to the selected phone?

Yep, that's exactly what it does.

> > 
> > WISHLIST
> > 
> - Serial port / GPRS access via Bluetooth (gnome-system-tools,
> redhat-config-network, etc.)

Aye.  There's a bunch of stuff that will require root privileges to
configure.  A GUI for administering rfcomm.conf is one such thing, and
also one for hcid.conf would be good too.  Getting this sorted out is
admittedly quite low on my list of things to do as I don't currently use
any GUI tools to configure system wide stuff.  Maybe this is something
you can help with?

Note that where possible in future it is advised by the BlueZ folk that
we don't use the tty emulation for supporting serial access and instead
create an rfcomm socket directly.  This means patching/plugins for pppd
and friends of course.

> - integration in multisync (although the multisync UI sucks buttloads,
> they seem to get the work done).

It should be relatively simple to slot in our chooser widget with
multisync.  I'm not sure that we yet support everything they need, it'd
be good to use it as a use-case.  Bo from Multisync indicated some time
ago he'd be interested in integrating with gnome-bluetooth once it
matured.

> - Integration of bluez-pin?

It would certainly make sense as part of this package.  What's the
status of its upstream?  I saw you'd done some work on it recently.

My immmediate plans are to steadily improve the manager application, and
to rewrite the OBEX component some.  Hopefully then the gnome-vfs
component will emerge from this too: being able to explore your phone's
filesystem from Nautilus is definitely a key requirement.

Also a goal is to re-attack phonemgr and turn it into something written
as much as possible in Python.

-- Edd