programmatically adding panel plugins

[Brian J. Tarricone]

On Sat, 4 Aug 2007 10:04:07 +0200 Nick Schermer wrote:

> 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...?
> 
> Maybe it's better to let the panel decide where to put the plugin,

I disagree.  It's actually essential that the application gets to
decide where to put it, because the app will be adding and removing the
plugin every time the app is started or exited.  Since the plugin truly
is 'foreign' and the panel doesn't really know anything about it, it
can't easily remember where the plugin used to be -- or rather, it can't
really know that a particular request to add a foreign plugin is from
the same app and for the same plugin that was requested last time.  Or
at least, my design idea constrains it so it doesn't.  Anything more
just adds extra complexity to the panel and reduces the flexibility the
application has.

> based on whether the panel is hidden, on the current monitor, next to
> the system tray if there is one (<-- I'd exspect that).

Why would you expect the plugin to be near the system tray?  I'm
talking about the display of any kind of arbitrary data in the panel.
It could be a "## new messages" type thing displayed by a mail client,
or some kind of countdown displayed by an app that is timing something,
or a charging display for a battery, or... basically anything you can
do with current panel plugins.

> Based on the last point, it might be better to extend the system tray
> plugin to support this, because that's what you want: more advanced
> 'tray icons'.

Ugh, please no.  The systray protocol is very non-extensible and, IMHO,
pretty shitty.  And, again, why would I necessarily want these foreign
plugins grouped with the systray?

> GtkContainer *xfce_panel_status_container_new (void);

Well, that's essentially what I'm asking for, except it should return a
fully-fledged XfcePanelPlugin so I can do things like add items to the
panel's context menu, set a focus widget, block/unblock the context
menu, etc.

> gboolean xfce_panel_has_system_tray ();

Not needed...

> and some xfce_panel_status_container_{get,set}_{size,visible}
> functions like Gtk has for the GtkStatusIcon.

This just seems too limiting and not really worth it.  Why design a
separate API and interface for what should look and behave exactly like
current panel plugins?  There are only two differences between a normal
panel plugin and my foreign plugin idea:

1.  Foreign plugins don't show up in the 'Add New Item' dialog.
2.  Foreign plugins are added to and removed from the panel by an
application without user interaction.

That's it.  Otherwise, they're exactly like the panel plugins we have
today.

> Maybe all this is already possible with the system tray protocol, but
> just not user-friendly, because status icons are in fact small windows
> IIRC. If so, we can create an object to handle this type of system
> tray icons and rewrite the system tray code (which needs some time
> anyway) to support this.

No, status icons just use the same GtkSocket/GtkPlug model that the
panel uses (which, FYI, are indeed small windows implementing the XEmbed
protocol).  (Of course, Qt and other toolkits use XEmbed as well; they
just wrap it in something other than GtkPlug/GtkSocket.)

	-brian