Re: Generic Embeddable plugins.

>
> Hi Martin,
>
> Folks - as a first order of business, please stop
> hitting "reply all". It's getting annoying. Thanks.
>

Alright you make a convincing case that my ideas won't pan out.

However I *still* want to get MathML into the mainline AbiWord build.

The approach I want to take is along the lines of the Generic Embeddable
plugins API that started this thread.

I intend to commit this code to the ABI-MATH branch Real Soon Now even
though it's not complete.

I will be away from internet contact (I'm going down to the beach) for a
few days so I won't be able to continue this discussion.

If people tell me what the generic API *SHOULD* be including what the
Header files look like so code can be written, I will seriously consider
your suggestions.

I'll consider everything people say anyway, but it really helps for me to
see concrete code.

Thanks,

Martin

>> 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.
>
> The component itself would be responsible for any such
> scrolling mechanism. It'd be folly to take a
> "resize/relayout" approach to a 3000 row embedded
> spreadsheet, for example.
>
>> 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.
>
> That's a bit primitive for my liking, and supposes a
> yet-to-be-defined manner of IPC between Gnumeric and
> the plugin. But I suppose it accomplishes something
> and goes with your "organic" approach.
>
>> I don't think this is hard to solve. Here is one
>> solution...
>
> [snip]
>
> Your solution presupposes that all you want to see in
> Abi is a rasterized version of the doc, instead of any
> interactivity. I wouldn't call that "embedding".
>
> It also plays poorly with printing, and I'm afraid
> will be too clunky/cumbersome/unintuitive for users
> used to "real" embedding, ala Word and OOo.
>
>> Another is realize that our graphics class is just a
>> wrapper around the
>> platform equivalent of a gdkdrawable.
>
> Indeed. The problem here is that solutions such as
> XEMBED (used by Bonobo, KParts, Netscape, and
> other...) require their *own* gdkdrawable to draw
> into. This means that you can't just pass around the
> gdkdrawable that's behind our FV_View's graphics
> class.
>
> Plus, this doesn't address printing.
>
>> 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.
>
> This involves even more cumbersome message-passing
> between Abi and its embedded children.
>
>> The printing is solved (not perfectly) by simplying
>> using the PNG preview
>> if the plugin is only capable of drawing to a raster
>> target.
>
> s/not perfectly/absolutely dreadfully/g
>
>> We can easily make PNG preview's using XP code.
>>
>> We can do PNG previews of the embedded content via..
>
> This all presupposes that the embedded content can or
> will want to draw into one of our GR_Graphics objects.
> I'm telling you, straight up, that that isn't going to
> happen for any plugin that you don't personally write.
> And even then, I fear that those sorts of plugins will
> have such a dreadful user experience that they won't
> be worth using.
>
>> 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.
>
> Nor am I, though I thought it prudent to raise this
> common-enough aspect of embedding that the
> conversation had thus-far overlooked.
>
>> Nautilus has decided to abandon it's Views and to
>> concentrate on just
>> being a file browser.
>
> That's fine, of course, except that we're moving in
> the exact *opposite* direction at your behest.
>
> The contents will *not* be rendered into our graphics
> class. They simply can't be if we want to integrate
> with any existing solutions. Or if we want a
> realistically seamless user exerpeience. Once you get
> over that hurdle, the rest becomes apparent.
>
> Best,
> Dom
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
>
Received on Sat Jan 15 03:02:12 2005