public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Option for more-"gnomey" settings
Date: Mon, 25 Feb 2008 21:31:02 +0100	[thread overview]
Message-ID: <1203971462.28528.82.camel@californication> (raw)
In-Reply-To: <1203936194.2754.193.camel@cookie.hadess.net>

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.

if you wanna set a GConf value to make this go away. I am fine with it.
However with BlueZ 4.x I might seriously consider moving this into
bluez-utils anyway. Doing this within the UI is wrong. There is no need
for doing it there. Seemed like a good idea to have the class of device
configurable when we create BlueZ 3.x, but now I don't think that it
should be configured from the UI at all.

> > > - 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 there is no reason that gnome-user-share is running. You do need
support for pairing and that is handled within bluetooth-applet. Not
having the applet running won't allow you to successfully connect and
authenticate new devices.

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

Of course there are other bad dependencies, but why do have to install
Apache when you want to share files over Bluetooth. I simply don't get
it. We depend on obex-data-server and then bluez-gnome and that's it.

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

But not on all. See my point above.

> > 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? :)

No. Simply define a GConf value and let me confirm it and then we can
disable these elements.

Regards

Marcel



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

      parent reply	other threads:[~2008-02-25 20:31 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
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 [this message]

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=1203971462.28528.82.camel@californication \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox