Setting short cut key for plugin

Erik Harrison erikharrison at gmail.com
Tue Jan 8 04:25:41 CET 2008


On Jan 7, 2008 9:03 PM, Diego Ongaro <ongardie at gmail.com> wrote:
> On Jan 7, 2008 6:39 PM, Erik Harrison <erikharrison at gmail.com> wrote:
> >
> > On Jan 7, 2008 4:04 PM, Enrico Tröger <enrico.troeger at uvena.de> wrote:
> > > Wouldn't it be now really time to think about a solution to get a
> > > xfce4-popup in the panel which can generally popup any plugin which
> > > register to a new popup-signal or something like this (as we told
> > > about before in the thread about the popup-command for the dict
> > > plugin)? I really dislike the idea that some plugins have their own
> > > code for the same purpose. Furthermore, I extended the code for the
> > > popup command in the dict plugin which I got from the windowlist plguin
> > > a little bit to add a usage message available with the -h/--help
> > > option. Other popu commands doesn't have this, a unique command line
> > > tool would be better, IMO.
> > >
> > > Nick, Jasper could you comment on this?
> >
> > I'm neither, but. . .
> >
> > $ xfce4-panel-msg plugin message
> >
> > Then we add a 'message' signal for plugins to listen for, which passes
> > in the string above. The panel provides a trivial dbus api for sending
> > messages which xfce4-panel-msg uses.
> >
> > Hmmm. Trouble is managing to send the signal to the right plugin. We
> > could use the plugin instance ID, but that isn't readily key bindable.
> > We could use the plugin name, but that's potentially problematic with
> > multple instances.
> >
> > How do plugins which handroll this sort of thing handle it? Are they
> > all Xfce X-XFCE-Unique? Or do they have some internal logic?
> >
> > Or maybe "command" is better than message.
> >
>
> Erik, I think you're complicating this too much. If the plugin is
> trying to do something fancy, then it should create its own dbus api
> for whatever it wants to do.
>

If you think that's complicated, I'll warn you away from panel internals. ;-)

Enrico asked if the solution was generalizable. It is.

> However, the standard usage is to pop up the plugin's menu. In that
> case, a simple popup-signal will do the trick. Use "Returns : TRUE to
> stop other handlers from being invoked for the event. FALSE to
> propagate the event further." for callbacks to figure out which
> instance of the plugin is handling it, or picking an arbitrary one
> should be fine. Any reason why this wouldn't be sufficient for most
> plugins?

Well, that's essentially the solution I outlined above. Only if every
plugin rolls it's own, it gets really messy.

4.6 panel will likely depend on DBus anyway, through the new config
daemon. Having the panel act as a lightweight dbus proxy makes it
trivially easy to add this kind of functionality to panel plugins.

>
> Just my 2 cents,
> Diego
>
> _______________________________________________
> Xfce mailing list
> Xfce at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce
> http://www.xfce.org
>



-- 
Erik
"Look at me still talking when there is Science to do"



More information about the Xfce mailing list