programmatically adding panel plugins

[Jasper Huijsmans]

Heya Brian,

I just want to say, keep that train of thought going, you're doing
really well :-)

I'm all for adding a feature like this to the panel, and I guess the
best way to develop it is to create a plugin that uses the API. So be
my guest and try out a few things, I'm quite sure no-one else is
working on a feature like this.

Ideally the panel would need to know as little as possible about the
special characteristics of the plugin and normal plugin API could be
used for normal operation.

If you don't get around to working on this I'm certainly interested in
looking at this myself, but I'm not sure when I will get to it.

        Jasper

2007/8/3, Brian J. Tarricone <bjt23 at cornell.edu>:
> Thinking about configuration...  I feel like these new types of plugins
> don't have to be persistent: that is, they aren't saved in the panel's
> configuration, and the panel itself does not re-add them on a panel
> restart.  The _add_external() plugins probably could be added to the
> config, but then that raises other problems for the app[1].  The
> _add_foreign() plugins can't be saved, because the panel has no idea how
> to instantiate them.
>
> So, the controlling app will need to maintain some panel-related
> configuration, so I'd also need:
>
> guint xfce_panel_plugin_get_panel_number(XfcePanelPlugin *plugin);
> guint xfce_panel_plugin_get_position(XfcePanelPlugin *plugin);
>
> Anything else...?
>
> And also signals for if/when the panel number or position changes.  This
> way the user can move the plugin around, and the plugin itself can
> remember where it goes so it can be placed correctly the next time the
> app is started.
>
>         -brian
>
> [1] Presumably an _add_external() type plugin would need to have some
> IPC set up to talk to its 'parent' app.  If the panel saves the plugin
> in panels.xml, on a session restart, the panel might add the plugin to
> the panel before the parent app is running, and it'll fail to set up its
> IPC mechanism.  Of course, there are ways around this, but I'd rather
> avoid complexity.  I suppose saving/not saving could be optional based
> on a 'persistent' parameter to the _add_external() call, or perhaps
> through a separate API call if being persistent seems useful.
>
> If having _add_external() plugins be persistent (optionally?) does seem
> like a good idea, there should be a way to associate the plugin with a
> normal plugin .desktop file.  In this case, _add_external() could be
> used in the case of a setup app that wants to ease adding the plugin to
> the panel, or a parent app that doesn't really need to be running for
> the plugin to work.
>
>
> Brian J. Tarricone wrote:
> > Hey Jasper & Nick,
> >
> > I'm working on something where I'm thinking about the possibility of
> > wanting to be able to add a plugin to the panel from inside the app,
> > without the user having to use the 'Add New Item' dialog. The app is
> > running all the time, and say perhaps in its preferences there's a
> > checkbox like "Show status in Xfce Panel".  If the user checks the
> > checkbox, I want to go ahead and add some nifty status display plugin
> > to a panel.  Let's assume for the moment that this plugin is too
> > complicated to just be a simple systray icon.
> >
> > Obviously this isn't possible right now, but does it sound like
> > something that might be useful and one of you might want to work on?
> >
> > I figure the easiest way would be to have something in libxfce4panel
> > like:
> >
> > XfcePanelPlugin *
> > xfce_panel_plugin_add_external(const char *plugin_command,
> >                                gint panel_num,
> >                                gint position);
> >
> > where 'plugin_command' is what would usually be in the X-XFCE-Exec line
> > in a normally-registered plugin's .desktop file.  The panel_num and
> > position parameters aren't really crucial (and I imagine one could pass
> > -1 for them to say "I don't care").  The idea here is that I'd want to
> > not have to install it like a regular plugin (so the user couldn't add
> > it manually.  The nice thing about this from the panel's perspective, I
> > guess, is that it's just returning an XfceExternalPanelPlugin and isn't
> > really doing anything special.  It's just getting its info on how to
> > load the plugin from the API call rather than the .desktop file.
> >
> > There's another option that I think I like better; I imagine it's
> > probably more work to implement in the panel, though. Something like:
> >
> > XfcePanelPlugin *xfce_panel_plugin_add_foreign(gint panel_num,
> >                                                gint position);
> >
> > Again, panel_num and position aren't critical.  In this case, When an
> > app calls this function, the panel would create a plugin GtkSocket, and
> > pass back the window id to the calling app, where libxfce4panel would
> > create a new 'XfceForeignPanelPlugin' object that knows how to create
> > the required GtkPlug.  Actually, yes, I like this option way better;
> > this way I wouldn't have to use some IPC mechanism to let the panel
> > plugin talk to the main app.
> >
> > Also, for this to be maximally useful, I'd probably need some more API,
> > such as:
> >
> > guint xfce_panel_get_n_panels();
> > guint xfce_panel_get_n_items(gint panel_num);  [1]
> > void xfce_panel_plugin_remove_external(XfcePanelPlugin *plugin);
> > void xfce_panel_plugin_remove_foreign(XfcePanelPlugin *plugin);
> >
> > ... and maybe other stuff I haven't thought about.
> >
> > [1] I guess this is the same as xfce_itembar_get_n_items(), but makes
> > it so the caller doesn't have to know anything about XfceItembar
> >
> > This functionality isn't a critical part of my app, otherwise I'd look
> > into implementing this in the panel myself.  If nobody cares or gets
> > around to it for a while, though, I might give it a go after the
> > important parts of my app are done.
> >
> > Anyway... sorry for the long email.  Thoughts?
> >
> >       -brian
> >
> > P.S.  I'd say what the app is, but I don't want people to be
> > disappointed in the slightly-likely event that I get busy and never
> > actually write it :-( .

-- 
        Jasper