FYI: 4.7 panel and plugins

Nick Schermer nickschermer at gmail.com
Tue May 26 22:08:16 CEST 2009


2009/5/26 Brian J. Tarricone <bjt23 at cornell.edu>:
>> making external plugins
>> a binary is crap, simply because it can never provide all the
>> functionality a wrapper can provide.
>
> Such as?

A lot, some on man, you think i'm stupid? There is over 900 lines of
code in the wrapper. Of course you can all stuff this in a macro and
dump it in the external plugin. Then each time a new panel is release
all external plugins have to be recompiled to get the fixes. All
possible, 1 problem: I decided (on my own) not to do that.

>> Internal plugins are a lot faster.
>
> Do you have benchmarking results to verify this?  Are they faster in ways
> that actually matter (e.g., is response to user input noticeably faster as
> internal plugins)?

Changes to the panel (dbus delay), startup is slower (can only start
the wrappers if the panel is realized).

>> If a plugin is stable and does
>> nothing that might lock the main thread for a long time (no http stuff
>> for example), I prefer a plugin to be internal.
>
> That's kinda hilarious.  Show me a stable plugin, and I'm sure you can find
> crash bugs if you look hard enough.  Encouraging plugins to be internal is a
> huge step backward for stability.

And then what, if a plugin crashes the panel, it will be simply
restarted by the session manager. At least you _can_ make it internal,
you don't have to. And if it's stable, why not. I can even add a
"i-am-a-wimp" boolean property that forces all plugins to run in a
wrapper if you want?

>> Internal == in-process, use less memory, faster communication with the
>> panel.
>
> Probably not.  Processes are pretty lightweight these days.

Pretty yeah. You make a big deal of (possibly) slower plugins because
of a call to g_thread_init, but the extra mb's of memory usage and
dbus delay: no big deal. I doubt you have a strong opinion about all
this. I on the other hand have: easy to maintain code base, which (as
a side affect) resulted in transparency between internal and external
plugins (which is nice i think, it means plugins are stupid and don't
contain any code that is handled by the panel). Unfortunately in this
world you cannot only have good things and you have to life with some
side-affects, if this case a preinit call and new Makefiles (if i
can't get the old external plugins running).

Nick



More information about the Xfce4-dev mailing list