Heya,
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
- 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.)
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?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Bastien Nocera wrote:
> On Mon, 2008-02-25 at 13:08 +0100, Stefan Seyfried wrote =
>> bluez-gnome is still somewhat the "reference bt applet" IIUC correctly, =
and i
>> am happy not having to install gnome just to be able to look at it ;-)
> =
> And where does anyone say that those dependencies will be added to
> bluez-gnome?
This was probably a misconception of mine. Sorry for that.
-- =
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2008-02-25 at 13:08 +0100, Stefan Seyfried wrote:
> Bastien Nocera wrote:
>
> > Bloat what dependencies? We're not bloating the bluez-gnome
> > dependencies, and gnome-user-share is already a default installation on
> > many GNOME installations.
>
> bluez-gnome is still somewhat the "reference bt applet" IIUC correctly, and i
> am happy not having to install gnome just to be able to look at it ;-)
And where does anyone say that those dependencies will be added to
bluez-gnome?
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Bastien Nocera wrote:
> Bloat what dependencies? We're not bloating the bluez-gnome
> dependencies, and gnome-user-share is already a default installation on
> many GNOME installations.
bluez-gnome is still somewhat the "reference bt applet" IIUC correctly, and=
i
am happy not having to install gnome just to be able to look at it ;-)
-- =
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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.
> - 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.
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.
> 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.
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel