programmatically adding panel plugins

Brian J. Tarricone bjt23 at cornell.edu
Fri Aug 3 19:36:04 CEST 2007


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 :-( .
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
> 



More information about the Xfce4-dev mailing list