Another bluez-gnome patch

Heya,

Here's an updated patch for the bluez-gnome applet and
properties:
- Use HAL to determine the device class, if HAL is
available
- Fix translation of scanning mode changes (modes weren't
translated at
all, and the string used could only be used in English)
- Don't show the notification bubble when switching the
bluetooth device
on/off, and we're only showing the icon if a device is
present. The icon
appearing/disappearing should be enough
- Fix excessive markup in the properties labels

Marcel, could you merge those patches?

Once you've accepted this patch, my next step is to
implement the
software enable/disable for laptops in the applet (that
would use HAL as
well).

Cheers

-- 
Bastien Nocera <hadesshadess.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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

> Here's an updated patch for the bluez-gnome applet and
properties:
> - Use HAL to determine the device class, if HAL is
available

I added this part to the CVS now. However we need another
GConf setting
that allows the user to control if HAL should be used or
not.

The properties dialog needs a setting to control the HAL
usage and show
or hide the class of device box according to it.

> - Fix translation of scanning mode changes (modes
weren't translated at
> all, and the string used could only be used in
English)

Fixed that and did a little rewording.

> - Don't show the notification bubble when switching the
bluetooth device
> on/off, and we're only showing the icon if a device is
present. The icon
> appearing/disappearing should be enough

We need to show when it goes back into connectable mode,
because that
happens if you use the discoverable timeout.

> - Fix excessive markup in the properties labels

Done a little bit different, but with the same result.

> Once you've accepted this patch, my next step is to
implement the
> software enable/disable for laptops in the applet (that
would use HAL as
> well).

I really like to see that. We need that feature.

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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

On Sat, 2007-02-24 at 16:43 +0100, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > Here's an updated patch for the bluez-gnome applet
and properties:
> > - Use HAL to determine the device class, if HAL is
available
> 
> I added this part to the CVS now. However we need
another GConf setting
> that allows the user to control if HAL should be used
or not.
> 
> The properties dialog needs a setting to control the
HAL usage and show
> or hide the class of device box according to it.

That sounds like over-engineering to me. What is the use
case of the
applet? If it's only going to be used on desktops, what's
the matter
with leaving the HAL support on? If the applet is to be used
in embedded
systems, surely those systems would make mofidications to
the applet to
fit their usage, and could turn off HAL support.

> > - Fix translation of scanning mode changes (modes
weren't translated at
> > all, and the string used could only be used in
English)
> 
> Fixed that and did a little rewording.

Cool.

> > - Don't show the notification bubble when
switching the bluetooth device
> > on/off, and we're only showing the icon if a
device is present. The icon
> > appearing/disappearing should be enough
> 
> We need to show when it goes back into connectable
mode, because that
> happens if you use the discoverable timeout.

Then we should save the mode before the change of
mode_changed signal,
and only popup the notification if the previous mode was
discoverable.

> > - Fix excessive markup in the properties labels
> 
> Done a little bit different, but with the same result.

OK.

> > Once you've accepted this patch, my next step is
to implement the
> > software enable/disable for laptops in the applet
(that would use HAL as
> > well).
> 
> I really like to see that. We need that feature.

Cool, I'll get onto that in the near future, hopefully.

-- 
Bastien Nocera <hadesshadess.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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

> > > Here's an updated patch for the bluez-gnome
applet and properties:
> > > - Use HAL to determine the device class, if
HAL is available
> > 
> > I added this part to the CVS now. However we need
another GConf setting
> > that allows the user to control if HAL should be
used or not.
> > 
> > The properties dialog needs a setting to control
the HAL usage and show
> > or hide the class of device box according to it.
> 
> That sounds like over-engineering to me. What is the
use case of the
> applet? If it's only going to be used on desktops,
what's the matter
> with leaving the HAL support on? If the applet is to be
used in embedded
> systems, surely those systems would make mofidications
to the applet to
> fit their usage, and could turn off HAL support.

it is not over-engineered for people that don't have the HAL
formfactor
setting to be used as base for the Bluetooth class of
device. It also
makes the properties application simpler since it doesn't
have to check
for HAL at all. It simply only sets a GConf value and applet
acts
depending on this value.

> > > - Don't show the notification bubble when
switching the bluetooth device
> > > on/off, and we're only showing the icon if a
device is present. The icon
> > > appearing/disappearing should be enough
> > 
> > We need to show when it goes back into connectable
mode, because that
> > happens if you use the discoverable timeout.
> 
> Then we should save the mode before the change of
mode_changed signal,
> and only popup the notification if the previous mode
was discoverable.

Good idea. Was actually to lazy to do it by myself. Then we
can also
change the wording to discoverable/non-discoverable.

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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hey Marcel,

On Sat, 2007-02-24 at 18:25 +0100, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > > Here's an updated patch for the
bluez-gnome applet and properties:
> > > > - Use HAL to determine the device class,
if HAL is available
> > > 
> > > I added this part to the CVS now. However we
need another GConf setting
> > > that allows the user to control if HAL should
be used or not.
> > > 
> > > The properties dialog needs a setting to
control the HAL usage and show
> > > or hide the class of device box according to
it.
> > 
> > That sounds like over-engineering to me. What is
the use case of the
> > applet? If it's only going to be used on desktops,
what's the matter
> > with leaving the HAL support on? If the applet is
to be used in embedded
> > systems, surely those systems would make
mofidications to the applet to
> > fit their usage, and could turn off HAL support.
> 
> it is not over-engineered for people that don't have
the HAL formfactor
> setting to be used as base for the Bluetooth class of
device. It also
> makes the properties application simpler since it
doesn't have to check
> for HAL at all. It simply only sets a GConf value and
applet acts
> depending on this value.

I still don't understand why you would want to give the user
the choice
of using HAL or not. If it's there, use it! The information
is always
available (it's given out by the BIOS/firmware), and if it's
not
accurate, it can be overridden using an .fdi file.

What does the user gain from being able to enable/disable
HAL support
themselves?

> > > > - Don't show the notification bubble
when switching the bluetooth device
> > > > on/off, and we're only showing the icon
if a device is present. The icon
> > > > appearing/disappearing should be enough
> > > 
> > > We need to show when it goes back into
connectable mode, because that
> > > happens if you use the discoverable timeout.
> > 
> > Then we should save the mode before the change of
mode_changed signal,
> > and only popup the notification if the previous
mode was discoverable.
> 
> Good idea. Was actually to lazy to do it by myself.
Then we can also
> change the wording to discoverable/non-discoverable.

I'll try and fix that then.

Cheers

-- 
Bastien Nocera <hadesshadess.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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

On Mon, 2007-02-26 at 10:24 +0100, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > > > > Here's an updated patch for
the bluez-gnome applet and properties:
> > > > > > - Use HAL to determine the
device class, if HAL is available
> > > > > 
> > > > > I added this part to the CVS now.
However we need another GConf setting
> > > > > that allows the user to control if
HAL should be used or not.
> > > > > 
> > > > > The properties dialog needs a
setting to control the HAL usage and show
> > > > > or hide the class of device box
according to it.
> > > > 
> > > > That sounds like over-engineering to me.
What is the use case of the
> > > > applet? If it's only going to be used on
desktops, what's the matter
> > > > with leaving the HAL support on? If the
applet is to be used in embedded
> > > > systems, surely those systems would make
mofidications to the applet to
> > > > fit their usage, and could turn off HAL
support.
> > > 
> > > it is not over-engineered for people that
don't have the HAL formfactor
> > > setting to be used as base for the Bluetooth
class of device. It also
> > > makes the properties application simpler
since it doesn't have to check
> > > for HAL at all. It simply only sets a GConf
value and applet acts
> > > depending on this value.
> > 
> > I still don't understand why you would want to
give the user the choice
> > of using HAL or not. If it's there, use it! The
information is always
> > available (it's given out by the BIOS/firmware),
and if it's not
> > accurate, it can be overridden using an .fdi
file.
> > 
> > What does the user gain from being able to
enable/disable HAL support
> > themselves?
> 
> for example if they wanna modify the class of device
with a specific
> value (as access point or something else) and still log
into the system.
> It is a special case, but there are still some systems
that use the
> class of device value for filtering the inquiry list.
In general this
> value is only good for choosing the correct icon in the
UI. By default
> however HAL will be used.

OK. Do you mind me changing the "use HAL" checkbox
with something like:
Class of device
[ ]  automatic
[X] [drop-down menu]

Then?


------------------------------------------------------------
-------------
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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

> > > > > > > Here's an updated patch
for the bluez-gnome applet and properties:
> > > > > > > - Use HAL to determine
the device class, if HAL is available
> > > > > > 
> > > > > > I added this part to the CVS
now. However we need another GConf setting
> > > > > > that allows the user to
control if HAL should be used or not.
> > > > > > 
> > > > > > The properties dialog needs a
setting to control the HAL usage and show
> > > > > > or hide the class of device
box according to it.
> > > > > 
> > > > > That sounds like over-engineering
to me. What is the use case of the
> > > > > applet? If it's only going to be
used on desktops, what's the matter
> > > > > with leaving the HAL support on? If
the applet is to be used in embedded
> > > > > systems, surely those systems would
make mofidications to the applet to
> > > > > fit their usage, and could turn off
HAL support.
> > > > 
> > > > it is not over-engineered for people
that don't have the HAL formfactor
> > > > setting to be used as base for the
Bluetooth class of device. It also
> > > > makes the properties application simpler
since it doesn't have to check
> > > > for HAL at all. It simply only sets a
GConf value and applet acts
> > > > depending on this value.
> > > 
> > > I still don't understand why you would want
to give the user the choice
> > > of using HAL or not. If it's there, use it!
The information is always
> > > available (it's given out by the
BIOS/firmware), and if it's not
> > > accurate, it can be overridden using an .fdi
file.
> > > 
> > > What does the user gain from being able to
enable/disable HAL support
> > > themselves?
> > 
> > for example if they wanna modify the class of
device with a specific
> > value (as access point or something else) and
still log into the system.
> > It is a special case, but there are still some
systems that use the
> > class of device value for filtering the inquiry
list. In general this
> > value is only good for choosing the correct icon
in the UI. By default
> > however HAL will be used.
> 
> OK. Do you mind me changing the "use HAL"
checkbox with something like:
> Class of device
> [ ]  automatic
> [X] [drop-down menu]
> 
> Then?

actually use, because the HAL usage is a user wide setting
while the
class of device is per adapter. Remember that Linux supports
for than
one adapter. When HAL usage is on, I need to make the class
of device
setting disappear, but I haven't had time for that so far.

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-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel