gconf question

David Zeuthen david at fubar.dk
Wed Jul 12 12:55:25 PDT 2006


On Wed, 2006-07-12 at 12:38 -0700, John Galloway wrote:
> > Btw, I'm curious what the problem with pulling in gconf, gnome-keyring
> > etc. here is?
>
> We're not a gnome desktop.  Its palmsource, so we're making a handheld
> system (all announced now, but I never bothered to re-subscribe under
> my palmsource account) based on linux but providing a palmOS-ish user
> experience and apps.

Interesting, sounds very cool.

>   Gconf did not provide the security we needed to
> use it for everything (i.e. including device management stuff pushed out
> by the carrier) and user application stuff, so we wrote our own settings
> system.  Likewise gnome does not offer what we need for the tiny screen
> type usage, so its not in play either.  HAL does offer good stuff and we
> are using it and would like to continue to do so, maybe increasing such
> (i.e. now its just pluggable media, but we've been looking at other hw
> mgt issues where we could leverage HAL).  But the more a desktop env
> is required, the less likely this will become.  Its also a very memory
> constrained environment so pulling in anything we don't actually use is
> very undesirable.

Oh, OK, that provides much needed perspective. Thanks.

So I think you're in good shape here and what you should do for mounting
is just write your own mount program that 

 a. reads settings (such as mount point, mount options, etc.) from your
    own preferences source

 b. calls into HAL to actually do the mounting

much like gnome-mount does. Depending on your needs, this could even be
in the same codebase as your file manager and it could invoke these
methods on HAL in response to events from HAL saying there's a new
volume available etc. (much like gnome-volume-manageR). This approach
would be pretty lean and also, I think, easy to implement.

It's a bit more complex if you want to handle passworded media using
LUKS but still entirely doable (gnome-mount does this already).

Oh, and if you (or anyone else such as Nokia, GPE, OLPC etc.) have any
requests about HAL being too slow / too memory consuming for embedded
use please come forward with them. Or if you have feature requests such
as FormatVolume(), PartitionDisk() (we already want to add these) come
forward as well. I really want HAL to work on embedded systems and if it
doesn't do that too well now I want to fix it.

    David




More information about the hal mailing list