FYI: 4.7 panel and plugins

[Jannis Pohlmann]

On Tue, 26 May 2009 18:51:23 -0700
"Brian J. Tarricone" <brian at tarricone.org> wrote:

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

Guys, please. 

> > 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.
> 
> > 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.
> 
> >>> 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),
> 
> Is this noticeable to users?  What kind of communication needs to
> happen on a regular basis in critical paths where the user will
> notice the difference in a negative way?  I'd think a user would
> expect adding a plugin wouldn't be instantaneous, so, say, a 15%
> increase in the time it takes to add a plugin internal vs. external
> wouldn't be a big deal. Other things, like saving config, etc.,
> should happen in the background, so it doesn't really matter if
> they're slow or not since UI shouldn't get blocked.
> 
> > startup is slower (can only start
> > the wrappers if the panel is realized).
> 
> Again: how much slower?  Is it a huge increase?

I can imagine that starting, configuring and resizing 10-20 plugins
involving D-Bus at the panel startup takes a noticable amount of
additional time compared to doing all that in-process. 

Personally, I don't think having both internal and external plugins is
necessarily a bad thing, although I'd never enourage in-process plugins
myself. But it's not that this is like the situation with the new panel
is any worse than with the old one where we had these two concepts as
well.

We should probably run some tests with complex panel setups and see how
external plugins affect the overall performance.

> 
> > 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).
> 
> True, you certainly can't always have everything perfect and elegant. 
> But hiding the distinctions between an internal and external plugin 
> sounds quite similar to the folly of trying to make in-process 
> communication look exactly like IPC from an API standpoint[1].

If I understand correctly, the code of internal and external plugins is
the same. There's no abstraction of the communication in there at all.
Internal plugins communicate with the panel in-process, external
plugins communicate with the wrapper in-process and the *wrapper* takes
care of talking to the panel. I don't think there's any problem with
that and I quite like that.

I've test-run the panel recently and I'm glad Nick is doing this. I'm
expecting it to be a major boost in the user-friendliness and
maintainability. Brian, you may not agree with all of Nick's design
decisions and I agree that in-process plugins are a bad thing. But Nick
is not questioning the design of xfdesktop either, so IMHO there should
be a certain amount of trust in that Nick does his best in creating a
good panel that everyone will love to use.

Laters,
Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20090527/62c57f26/attachment.pgp>