Subject: RE: Embedding AbiWord
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri Aug 03 2001 - 17:54:44 CDT
On Fri, 3 Aug 2001, Emswiler, Mike wrote:
> Are there any examples out there of the AbiWord renderer/editor running in
> anything other than the AbiWord Word Processor Application?
>
Not outside of the AbiWord. Inside AbiWord look at
src/wp/ap/xp/ap_Preview_Abi.cpp
to see how the full Word Processing canvas is embedded in a preview. We
use this for our styles dialog.
Cheers
Martin
> I too work with wxWindows and am looking for a similar cross-platform (I
> stopped using XP after MS hijacked it, anyone have another abbreviation?)
> embeddable editor
>
> Thanks,
> MikeE
>
> -----Original Message-----
> From: Paul Rohr [mailto:paul@abisource.com]
> Sent: Friday, August 03, 2001 5:18 PM
> To: Hubert Figuiere; David Mandelin
> Cc: abiword-dev@abisource.com
> Subject: Re: Embedding AbiWord
>
> David,
>
> Thanks for offering to take a whack at making AbiWord embeddable in an XP
> fashion. We've seen that problem looming on the horizon, but it's great to
> have someone interested in tackling the problem sooner.
>
> At 11:24 PM 8/2/01 +0200, Hubert Figuiere wrote:
> >What I see is a need for an embedding architecture that will allow:
> >1/ Abiword to be server for anything else. That means embedding AbiWord
> >within another application, using OLE on Win32, Bonobo and/or DCOP on
> >UN*X, etc.
>
> Agreed. For AbiWord to be embeddable within other apps, we'll need
> platform-specific stub code so we can be invoked by the "surrounding"
> application using whatever mechanism is typical for that environment.
>
> As you skim through the abi/src/af/xap classes, you'll note that we've
> already abstracted out all of the app and window management classes into XP
> code. The class hierarchies to get in and out of platform code are funkier
> than some would like, but they're not hard to figure out. For pretty
> pictures, see:
>
> http://www.abisource.com/talks/lwce2000ny/index.phtml
> http://www.abisource.com/talks/lwce2000ny/sld027.phtml
>
> I suspect you're right that the ideal solution here would be to reparent our
> existing app / frame / window logic to a new intermediate XP class that
> manages the interaction with the calling app.
>
> As Hub mentions below, hiding all of the necessary platform details in an
> appropriate subclass would be a Very Good Thing.
>
> >2/ Abiword to be client of anything else, to be able to embed any
> >other component. Again using the same object model.
>
> As a policy decision, I *think* I agree with Hub here. It seems plausible
> that we'll want to invoke those same native OS services to embed content
> managed by other apps inside our documents.
>
> However, as a practical matter, I think this is a whole 'nother ball of wax
> entirely. (David, you can probably meet your needs without ever getting
> bogged down in this part.) Unlike #1 above, this functionality for #2 will
> need to happen in totally different spots in the codebase, because we'll
> need to deal with issues like:
>
> - recognizing which app to invoke for embedded content,
> - delegating screen space (and possibly events) to the embedded app,
> - delegating menus and other UI while editing the embedded content, and
> - deciding how to store that embedded content in our file format.
>
> The last gets especially tricky for an XP application, because document
> interchange will get a lot more difficult if our file format embeds
> Bonobo-encoded content on one platform, OLE2 streams on a second, etc.
>
> http://www.abisource.com/mailinglists/abiword-dev/00/March/0297.html
> http://www.abisource.com/mailinglists/abiword-dev/00/March/0322.html
>
> I've been pretty adamant on this list in the past that we try to avoid
> interop problems like this (due to platform-specific opaque data) wherever
> feasible. [1]
>
> Ideally, then, we'd have XP mechanisms here to:
>
> 1. Identify embedded content in our file format.
> 2. Do some detective work to determine whether there's an available
> handler for that content type.
> 3. If not, deal with it ourselves.
> 4. Otherwise,
>
> 4a. Hand off the blob (and some screen real estate) to the "contained"
> app for display.
> 4b. If needed, do all the UI changes to "activate" it for editing.
> 4c. Get the updated blob back to save in our file format.
> 4d. Also get a copy of however that blob was rendered on-screen so we
> can save an XP-friendly preview in PNG or SVG as appropriate.
>
> Note that many of these XP interfaces (especially 2 and 4*) would be backed
> by platform-specific implementations. Also, it might well be worth starting
> out by implementing a smaller subset of these APIs so we can skip all the
> problems added by allowing in-place editing of the embedded content.
>
> But I digress. We're getting *way* ahead of ourselves here. :-)
>
> >Currently we have an XP support for scripting. This is a good start.
> >Also Dom started some work on Bonobo, so there definitely are things
> >started.
> >This embedding architecture should be in the XP land with a mapping
> >to the platform native enbedding. As Bonobo is largely inspired by OLE
> >and OLE itself is a subset of what could be done in OpenDoc (a CORBA
> >implementation), I think there are definitely common issue that can
> >stick to the XP land.
>
> That's my hope as well.
>
> >BTW, Mozilla's XPCOM is a good example :-)
>
> Wow. Have they really managed to abstract out the differences between
> Bonobo and OLE, so that Mozilla is equally embeddable on both platforms?
> Have the Bezilla folks done something similar to map the Be embedding model
> into the same APIs?
>
> If so, that'd be an *excellent* design model to study. However, I'm not
> sure it'll be anywhere near that easy.
>
> I was under the impression that XPCOM and Bonobo need translation layers to
> talk to each other, and that Mozilla currently doesn't work that way:
>
> http://oss.software.ibm.com/developerworks/projects/buxom/
>
> Ditto for OpenOffice's UNO (vs. Bonobo):
>
> http://whiteboard.openoffice.org/bonobo/
>
> Thus, while I hate reinventing the wheel, we may want something simpler that
> does "just enough" of the relevant Bonobo/OLE/etc. stuff out in platform
> stubs. Oh well -- we'll cross that bridge when we come to it.
>
> bottom line
> -----------
> Yes, we want to use native mechanisms behind XP interfaces, but there's
> still plenty of meaty work do decide where and how that should be done. I
> hope that by focusing on just one side of the problem -- getting Abi to work
> properly "inside" some other app -- we can keep from getting too bogged down
> in the morass.
>
> Enjoy!
>
> Paul,
> rusty old-timer
>
> 1. No, I don't want to reopen the image format flamewar again. Not until
> someone's ready to write more code for a post-1.0 branch. ;-)
>
>
This archive was generated by hypermail 2b25 : Fri Aug 03 2001 - 17:54:50 CDT