From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Bastien Nocera To: BlueZ development In-Reply-To: <1172481882.27370.4.camel@violet> References: <1172187093.10673.17.camel@cookie.hadess.net> <1172331829.11537.14.camel@violet> <1172337118.31852.10.camel@cookie.hadess.net> <1172337927.11537.19.camel@violet> <1172451821.31852.28.camel@cookie.hadess.net> <1172481882.27370.4.camel@violet> Date: Mon, 26 Feb 2007 10:28:49 +0000 Message-Id: <1172485729.4742.1.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 Subject: Re: [Bluez-devel] Another bluez-gnome patch Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel