New panel framework

[Jasper Huijsmans]

Brian J. Tarricone schreef:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Erik Harrison wrote:
> 
>>Replying using my @xfce address, since I've gotten it working, I think
>>
>>On 9/1/05, Jasper Huijsmans <jasper at xfce.org> wrote:
>><Lots of good stuff>
>>
>>>* Does the panel plugin system look like it will be able to support all
>>>  current functionality?
>>
>>Since plugins can now be external processes communicating over a
>>GtkSocket, what's the chances that the (Three!) xfce language bindings
>>will support writing panel plugins.
> 
> 
> Yep, certainly possible, and not even all that difficult.
> 
> 
>>Technically I imagine it was possible to do before, but you'd have a
>>perl or python interpreter running in the panels process space.
> 
> 
> Yeah, for perl at least I know this isn't trivial (see the gaim Summer
> of Code blogs), but it shouldn't be terrible if we wanted to support
> in-process perl plugins (or python).
> 

'We' don't ;-) In-process plugins are in C. I don't think that's too 
much of a restriction.

> 
>>Of course, external plugins won't be possible, but is there a way you
>>are launching panels that would prevent plugins for being written with
>>the bindings?
>>
>>And bindings guys (Jeff, Danny, Brian) would you be willing to write
>>the support for the panel if it is possible?
> 
> 
> Probably the cleanest way to do it would be for the panel itself to
> support the notion of "loader plugins" - in-process plugins whose job is
> solely to load other plugins.
> 

I was hoping that it wouldn't be too hard for bindings to support the 
external plugin widget.

It's basically a GtkPlug with a few extra properties, a protocol for 
communicating with the panel item GtkSocket and a _new() function and a 
macro to parse command-line arguments. Suggestions to make this easier 
to bind to are of course welcome.

I have no idea how the bindings are implemented, so I don't know at what 
level they can interact with the C implementation. We have this:

- a GObject, XfceExternalPanelPlugin (derived from GtkPlug)

- XfcePanelPluginInfo vtable with a number of function pointers

- xfce_panel_plugin_new (int argc, char **argv,
                          XfcePanelPluginInfo *info);

This function parses the command line and sets the initial properties, 
creates the GtkPlugin and embeds it into the appropriate GtkSocket. It 
would be nice if binding authors wouldn't have to reimplement this, but 
I'm not sure that's possible.

- #define XFCE_PANEL_PLUGIN_REGISTER_EXTERNAL(info) \
     int \
     main (int argc, char **argv) \
     { \
         GtkWidget *plugin; \
         gtk_init (&argc, &argv); \
         plugin = xfce_external_panel_plugin_new (argc, argv, &(info)); \
         if (!plugin) return 1; \
         g_signal_connect (plugin, "destroy", \
                           G_CALLBACK (gtk_main_quit), NULL); \
         gtk_widget_show (plugin); \
         gtk_main (); \
         return 0; \
     }

The macro creates a main() function that intializes gtk, creates a 
plugin, connects to the destroy signal to quit the main loop, and runs 
the program. A binding should probably provide their own convenience 
function for this.

I'm not 100% convinced this is the best solution, but it does allow me 
to have the same interface for internal and external plugins, which is 
kinda nice:

XFCE_PANEL_REGISTER_INTERNAL(info) vs.
XFCE_PANEL_REGISTER_EXTERNAL(info)

	Jasper