Re: [Utopia] app event sharing

["John (J5) Palmieri" <johnp redhat com>]

On Tue, 2005-10-18 at 16:00 -0400, Jeffrey Stedfast wrote:
> On Tue, 2005-10-18 at 15:48 -0400, John (J5) Palmieri wrote:
> > On Tue, 2005-10-18 at 15:40 -0400, Jeffrey Stedfast wrote:
> > > Mr. Love and I just duiscussed this a little here in our spacious Novell
> > > Cubicles and the most plausable diea we came up with was to have
> > > applications register with dbus saying "I can handle cd burning". G-V-M
> > > would then query to see if any apps were running/registered as being
> > > able to handle burning cds, if so - do nothing and let the app handle
> > > the event itself, else give the prompt.
> > > 
> > > It's not perfect in that the user could be running Banshee but want to
> > > burn a data cd using nautilus-cd-burning (which isn't yet running), but
> > > at least it eliminates some confusion.
> > 
> > We already have a lock in HAL to do this for cd burners.
> > 
> 
> that isn't the point. cd burning is being used as an example. the
> problem is that apps might request a user to insert a blank cd, data cd
> 2-of-3, plug in a camera to import the photos, etc etc and there needs
> to be a way of informing g-v-m that something else is going to habndle
> the event so that g-v-m doesn't try to handle it in addition to another
> app that has requested the user add the hardware device.

So why not use the locking framework for this?  Just expand it to other
devices.  For instance, if Banche doesn't want to handle cd-burning
unless the user has selected "burn a cd" it can obtain the lock only
when the user has first requested it.  Alternatively we could also
expand it so running apps can register with HAL (much like obtaining the
lock) that they can handle a certain function (like cd burning) and gvm
will pop that up as the default action.  With notifications this can all
be done unobtrusively and avoids the problem of wanting to burn a data
cd when Banshee is running.  

-- 
John (J5) Palmieri <johnp redhat com>