FYI: 4.7 panel and plugins

[Nick Schermer]

2009/5/27 Brian J. Tarricone <brian at tarricone.org>:
> Nick Schermer wrote:
>>
>> 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?
>
> Don't put words in my mouth.  It only makes you sound like you're trying to
> pick a fight for no reason.
>
>> There is over 900 lines of code in the wrapper.
>
> How am I supposed to know that?  After 5 minutes of clicking through panel
> trunk, I don't see it anywhere.

Trunk? Try git. o_O

>> 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.
>
> Sure, I'll buy that, that makes sense.
>
>> All possible, 1 problem: I decided (on my own) not to do that.
>
> Problem?  Not sure I understand what you're saying here.

I decided to use a wrapper application, not a huge macro.

> That would be great.  Would also be an interesting performance experiment.
>  You should have done this anyway, while investigating alternatives, instead
> of just deciding your new way was better.

Alternatives what do you mean? I've rewritten the code at least 3
times in the last year and did a lot of benchmarking, running only
external plugins for weeks and some for internal. The default of
plugins is external, unless set otherwise in the desktop file. The
problem right now is that you can only switch between
internal/external by recompiling the plugin, so it's not really
encouraging to make your plugin internal after some time, now it is,
but i doubt maybe people with do this anyways. Also easier to debug a
plugin (ask user to make the plugin internal, start xfce4-panel in
gdb).

>>>> 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,
>
> Startup *will* be slower due to linking in libpthread.  Many standard
> library calls *will* be slower due to extra (unneeded) locking and running
> slower threadsafe versions.  This is fact.  Go read the NPTL/libpthread
> source code if you don't believe me (or the old LinuxThreads source code, if
> you really want a headache).

But a fact is that the plugin (and plugin developer) has no clue
whether the plugin is running in-process or in a wrapper. So both need
to provide the same behavior. Panel calls g_thread_init, wrapper calls
it. I cannot call preinit for internal plugins before gtk_init, so why
provide it in the wrapper?

Nick