From: Bastien Nocera <hadess@hadess.net>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Option for more-"gnomey" settings
Date: Mon, 25 Feb 2008 10:43:14 +0000 [thread overview]
Message-ID: <1203936194.2754.193.camel@cookie.hadess.net> (raw)
In-Reply-To: <BDDF9433-7A32-4CAB-B9C8-2A67635C8578@holtmann.org>
On Mon, 2008-02-25 at 03:08 +0100, Marcel Holtmann wrote:
> Hi Bastien,
>
> > As you know, I have a problem with a few settings in bluez-gnome not
> > matching up with the philosophy/target for GNOME.
> >
> > Right now it's:
> > - "Use HAL" settings, and associated device selection
>
> you know that the class of device selection will disappear when
> enabling the HAL setting. I did that a few releases ago.
Which is something that the HIG says shouldn't be done. The button
should be visible, but disabled.
I'm actually asking for the "Use HAL" checkbox to not even be there.
> > - Sharing properties, which conflict with gnome-user-share (where we
> > want to have most of the sharing preferences for GNOME, including
> > sharing the screen using vino, etc.)
>
> You can easily add an option to gnome-user-share for setting the GConf
> value that bluez-gnome is using. The whole incoming connection/accept
> thing should be handled inside bluetooth-applet.
Any particular reasons that should be the case? There's no telling that
the bluetooth-applet will be running when that happens.
> And as I mentioned the gnome-user-share dependency chain of the
> distros is crazy. As long as it drags Apache + WebDAV into my desktop,
> I am against it.
Why is that so bad? It's a pretty small compared to say, docbook
stylesheets (weighs in at 2.7 megs on an x86-64), and it means that all
the sharing UI are in one place.
> > Would you accept a patch to add a --enable-gnome to configure to hide
> > those settings away when bluez-gnome is compiled for use in the GNOME
> > desktop? Or would you prefer a run-time option?
>
> I prefer if you use the GConf values that bluez-gnome uses and move
> all Bluetooth related interaction into bluetooth-applet instead of
> hacking it into some other applications and bloat the dependencies.
Bloat what dependencies? We're not bloating the bluez-gnome
dependencies, and gnome-user-share is already a default installation on
many GNOME installations.
> If you really wanna shrink the settings of bluetooth-properties, we
> can do that at runtime with a GConf setting. I have no problem with
> that. I am against compile time options.
Ok. I'll prepare a patch for that. I guess this shouldn't have a UI
though, right? :)
Cheers
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2008-02-25 10:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 18:37 [Bluez-devel] Option for more-"gnomey" settings Bastien Nocera
2008-02-25 2:08 ` Marcel Holtmann
2008-02-25 10:43 ` Bastien Nocera [this message]
2008-02-25 12:08 ` Stefan Seyfried
2008-02-25 12:26 ` Bastien Nocera
2008-02-25 12:28 ` Stefan Seyfried
2008-02-25 20:31 ` Marcel Holtmann
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=1203936194.2754.193.camel@cookie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox