Subject: RE: Embedding AbiWord
From: Emswiler, Mike (mikee@protrader.com)
Date: Fri Aug 03 2001 - 17:44:20 CDT
Are there any examples out there of the AbiWord renderer/editor running in
anything other than the AbiWord Word Processor Application?
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:44:22 CDT