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