Re: Generic Embeddable plugins.

Hi Dom and Jean,
                I've thought about most of your points for sometime.

Dom, the one thing I don't have a solution for is scroll-bars in the
embedded object. However in the case of Word Processing document, I think
scroll bars are not wanted. I would rather increase the size of the object
and relayout.

> 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 UI I'm suggesting for this round is extremely simple. The external
program is fork/exec'd with the data used by AbiWord to draw the component.
Like our AbiGimp plugin. So I imagine Gnumeric firing up with the contents
loaded. On every save from Gnumeric the image displayed in AbiWord is
updated.

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

I don't think this is hard to solve. Here is one solution...

We have two XP methods in our graphics we can use for this.

           virtual GR_Image* GR_Graphics::createNewImage(const char* pszName,
                                                                         const UT_ByteBuf* pBB,
                                                                         UT_sint32 iWidth,
                                                                         UT_sint32 iHeight,
                                                                         GR_Image::GRType iType = GR_Image::GRT_Raster);
GR_Graphics::drawImage(GR_Image *pImg, UT_sint32 xDest, UT_sint32 yDest);

We just need to acquire the bytebuf and we're home.

Another is realize that our graphics class is just a wrapper around the
platform equivalent of a gdkdrawable.

We can invent an abstract interface that provides the access we need to
draw directly to it or we can make "draw here method" platform specific.
In any case we can draw directly to the graphics class with a little extra
work.

I'm happy to help out Jean Brefort if he wants to work on this.

>> 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 printing is solved (not perfectly) by simplying using the PNG preview
if the plugin is only capable of drawing to a raster target.

We can easily make PNG preview's using XP code.

We can do PNG previews of the embedded content via..

         virtual GR_Image * GR_Graphics::genImageFromRectangle(const UT_Rect & r);

Where r is rectangle on the screen that has been drawn into.

Once we have GR_Image * we can convert it to a PNG via..
libPNG or gdk-pixbuf.

Actually the Unix build already has a method to this.

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

This framework does not address UI merging at all. This is a whole new
problem would need to be solved for each target.

The AbiWord menus and toolbars are all dynamically generated and be
directly altered within the program. So in principle this could be done by
writing glue code to interface to the target.

In practice I'm unconviced that that altering Abi's toolbars and menus to
match the target program's adds a lot to the usability of the program.

Nautilus has decided to abandon it's Views and to concentrate on just
being a file browser.

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

We can do this on the AbiWord side once the contents are rendered into our
graphics class.

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

My vision is to relayout every time the user presses "save" in the
external application. We simply stat the filename we pass to the program
and relayout
every time the file changes.

Cheers

Martin

> 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 23:46:33 2005