Re: Generic Embeddable plugins.

Hi Martin,

> Well think of it this way. Sooner or later the
> plugin has to draw into our
> graphics class. It also has to write a preview of
> itself into our
> piecetable. We also have to tell the plugin that
> something about the
> embedded object has changed. Maybe the user has
> changed it's size, or the
> font has been changed to bold or the colour is now
> blue, or the thing has
> been selected.

Not all of those statements are true. No UI embedding
architecture that I'm aware of does what you suggest.

The most common way to get things to embed is via a
window-sharing mechanism, such as XEMBED (Bonobo,
KParts, and Netscape use this) or ActiveX (Win32).
With XEMBED, you say to the plugin: "Here is a
Drawable ID that I created for you, separate from
(though embedded in) my main content widget's
Drawable. It's all yours. Draw into it to your heart's
content." With ActiveX, it's much the same.

By wishing to share the FV_View's underlying
Drawable/HWND, I believe your design necessarily
*precludes* us from integrating with XEMBED and
ActiveX. Which defeats the bridging argument
altogether.

This problem becomes even more interesting when one
starts talking about printing, especially on Unix.
Take a look at the hoops the Netscape folk jump
through to accomplish this.

The problem becomes even more interesting when one
considers UI merging, such as toolbar and menu
integration.

I'm still unconvinced that we need previews, so much
as they are a potential nicety.

I do agree with your general concern that we need
robust way of communicating with plugins. Again, there
are a lot of well-developed protocols such as COM,
DBUS/DCOP, UNO, XPCOM, ... that solve this problem. I
fear that whatever we home-brew will be underpowered,
incompatible with existing solutions, or both.

I also am pondering if we will need some sort of
interface discovery mechanism, or whether we can get
away with designing a very strict interface capable of
being fulfilled by some bridge, such as:

canPrint(), canSave(), canSavePreview(), ...
doPrint(), doSave(), doPreview(), ...

On some points I'll freely admit that I might be
over-architecting, and that an organic solution has a
geniune appeal. We can probably get away without
interface discovery. I'm slightly less inclined to
think that we can get away without UI merging, simply
because presenting a uniform UI could be essential for
user adoption. I'm not inclined to think that my views
on XEMBED/ActiveX and Printing are wrong.

> More-over we actually have a volenteer, Jean, who is
> familiar with both
> the netscape plugin API and bonobo interface who is
> keen to write such
> interfacing code.

I'll believe it when I see it. We've said these things
before. They've never panned out.

Even if what you say is true, I say with some large
degree of certainty that given the currently proposed
architecture, the above would be an impossible task.

But I'm happy to be proven wrong.

Martin, what you've proposed is an *excellent*
solution for a particular type of problem. I don't
know whether I'm being foolish for thinking that such
a solution should attempt to solve other problems.

Cheers,
Dom

                
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Received on Fri Jan 14 15:13:53 2005