All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Removing features
Date: Sun, 24 Dec 2006 14:12:16 +0000	[thread overview]
Message-ID: <1166969536.3223.4.camel@randel.hadess.net> (raw)
In-Reply-To: <1166968557.15485.14.camel@violet>

On Sun, 2006-12-24 at 14:55 +0100, Marcel Holtmann wrote:
> 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.

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

Cheers

-- 
Bastien Nocera <hadess@hadess.net>


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

  reply	other threads:[~2006-12-24 14:12 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 [this message]
2006-12-24 14:32     ` Marcel Holtmann
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=1166969536.3223.4.camel@randel.hadess.net \
    --to=hadess@hadess.net \
    --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.