From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Removing features
Date: Sun, 24 Dec 2006 15:32:50 +0100 [thread overview]
Message-ID: <1166970770.15485.17.camel@violet> (raw)
In-Reply-To: <1166969536.3223.4.camel@randel.hadess.net>
Hi Bastien,
> > > I was taking a look at the properties and applet in the bluez-gnome
> > > tree, and thought that some things could be changed to make it more
> > > GNOME-ish.
> > >
> > > I've attached an obviously unfinished patch that would remove the
> > > "Adapter class" combobox from the properties capplet, and have the
> > > applet setup the class depending on the "system.formfactor" property
> > > given out by HAL[1].
> > >
> > > If this sort of thing would accepted into the tree, I have some more
> > > patches lined up (including finishing up this one).
> >
> > actually I am a little bit against a compile time option against HAL.
> > This should be a runtime check if HAL is available.
>
> I can certainly make it both a compile-time and run-time check. Ie. if
> HAL is available at compile-time, but not at run-time, show the
> combobox.
>
> Did you want to make HAL a hard dependency, or should it be optional as
> now?
>
> I'll finish that up now.
do we need something? I thought they are D-Bus calls only.
> > The other thing is that this doesn't really belong into bluetooth-applet
> > and should be moved directly into hcid. However this might give some
> > crazy dependency chain.
>
> I don't think such a policy should be in hcid, but rather in the desktop
> bits. (Currently, the bluetooth daemons are started a long time before
> HAL is, at least in Fedora, and Matthew Garrett's HAL bits need the
> bluetooth daemon running, so, yeah, crazy deps).
In general you are right, but tell that to the Bluetooth specification.
The class of device is really a per adapter thing and not a per user
thing unless we can assign specific hardware only to one particular
user.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-12-24 14:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-23 22:16 [Bluez-devel] Removing features Bastien Nocera
2006-12-24 13:55 ` Marcel Holtmann
2006-12-24 14:12 ` Bastien Nocera
2006-12-24 14:32 ` Marcel Holtmann [this message]
2006-12-24 15:15 ` Bastien Nocera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1166970770.15485.17.camel@violet \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.