New panel framework

Brian J. Tarricone bjt23 at cornell.edu
Sat Sep 3 17:16:41 CEST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jasper Huijsmans wrote:
> 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.

Nah, I don't think so either... I'm just saying it's possible.

>>>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)

I think I'm missing something here.  How does the panel know about these
external plugins?  Unless I'm misunderstanding, the external plugins
don't talk to the panel at all until their binary is run.  But how does
the panel find out about external plugins so it can list them in the
"Add Item" dialog?  Assuming there's a separate mechanism for this,
letting language bindings write plugins shouldn't be a problem at all.

	-b

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDGb5Z6XyW6VEeAnsRAnZfAJ9ZJEDVDnpzPCND2jB5JcuzmdGxwACfRZTd
cVRvOYVHviZl9ojtgQ4IvKQ=
=MD7G
-----END PGP SIGNATURE-----



More information about the Xfce4-dev mailing list