Hi Martin,
Folks - as a first order of business, please stop
hitting "reply all". It's getting annoying. Thanks.
> 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 01:27:46 2005
This archive was generated by hypermail 2.1.8 : Sat Jan 15 2005 - 01:27:46 CET