programmatically adding panel plugins

Daryl Van Humbeck dvanhumb at sfu.ca
Sat Aug 4 08:29:08 CEST 2007


Sounds like an interesting idea, though I have one question:
How are you suggesting the plug-in's location be decided?

After all, you can't have the plug-in change location every time its 
loaded...

Daryl Van Humbeck.

Brian J. Tarricone wrote:
> 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
>>
>>     
> _______________________________________________
> 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