Re: the future of GNOME Applets



El mar, 21-09-2004 a las 23:19 +0800, Davyd Madeley escribió:
> On Tue, 2004-09-21 at 10:58 -0400, Sean Middleditch wrote:
> > On Tue, 2004-09-21 at 16:52 +0200, Carlos Garcia Campos wrote:
> > > > On Maw, 2004-09-21 at 14:12, Davyd Madeley wrote:
> > 
> > > > You want more than monitor - a lot of the systems can set policies so
> > > > you want policy selector. These tend to include "performance", "maximum
> > > > battery life" and the like. Sometimes you need to switch at runtime (eg
> > > > when playing bzflag) to avoid the CPU speed change messing with your
> > > > game.
> > > 
> > > For to set a policy is necessary to be root and in a common case an
> > > applet is not running as root. I think it can be solved by using an
> > > external program as a policy selector. It will prompt for root password,
> > > like the clock applet does calling to gst to set the time. The problem
> > > is that it could be an annoying process for a so simple task.
> > 
> > A laptop system will likely be configured for this to not be the case.
> > If I handed out a laptop running Linux to employees here, I'd definitely
> > do that.  Laptops are usually single-user systems and it's not like
> > adjusting the policy is going to severely damage anything.  (Assuming
> > the available policies _are_ locked down.)
> > 
> > The applet could provide a menu of the policy options.  When one is
> > clicked, an external tool is run to do the actual change.  This tool
> > can, on systems that are designed that actually care about ease-of-use,
> > use something like console-helper - it'll either just do its job without
> > any complaint (and the applet will be updated to reflect the new
> > policy), or it'll popup the authentication dialog to pester users about
> > the root password.  (or the user password, or whatever policy the admin
> > has configured.)
> 
> Someone has written a CPU Freq applet thing to do this called Emifreq.
> 
> http://zzrough.free.fr/emifreq.php
> 
> I haven't had time to have a look at it besides what the screenshots
> show. Or pit it against the applet that Carlos wrote (which has always
> been quite sturdy). However, I think it covers what you're talking
> about.

I don't know if using a daemon running as root is the best solution.
IMHO a better solution could be to use a command line tool to set the
policy. In a single user system the user could choice to set the SUID
bit for the command line tool or not. If the applet haven't got
permission to exec the command line tool, it could prompt for root
password (for example by using gksu or writing its own authentication
system). I think it's not necessary to have a process running all the
time. 
If you like the idea I can write the command line tool.  

> --d

Greetings, 
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Carlos Garcia Campos a.k.a. KaL
   elkalmail yahoo es
   carlosgc gnome org
   http://carlosgc.linups.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=             
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]