Re: Generic Embeddable plugins.

Le vendredi 14 janvier 2005 à 06:11 -0800, Dom Lachowicz a écrit :
> 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

Aside the problem of writing the interfaces, there is another concern. I
do not know of any Netscape plugin or bonobo control that will both be
able to save its contents and print them. Both are very important in the
context of a word processor. To display on screen, we should use
XEMBED/ActiveX, IMHO. I feel printing is by far the most difficult
thing.

UI integration is another concern of course. Editing embedded objects in
place is nice but not so easy. The size of the object can change at any
moment and we might have to recalculate the page layout very often. It
is also possible to edit in a separate window and only negotiate size
when editing is over.

The most easy thing might be on windows, ActiveX integration. But I do
not use windows anymore. (May be I'm once more wrong).

Regards,

Jean
Received on Fri Jan 14 18:53:25 2005