[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Embedding in KOffice
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2005-07-20 7:23:45
Message-ID: 200507200923.49148.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 19 July 2005 20:06, David Faure wrote:

> KoDocument::paintContent, the virtual method that embedded parts must
> reimplement, has zoomX and zoomY parameters. This is supposed to be the
> solution for this, it's just that not all parts implement zooming, and
> those that do don't necessarily implement paintContent correctly.

I guessed something like this. Maybe we can hammer out a specification for the 
implementation of paintContent -- or is there one already and have I missed 
it?

> Yes. The paintContent() API is exactly that. What's missing is disabling
> quite some page stuff in the components, when they are embedded.

Ah, it's the specification again :-). Shall I try to make a summary 
specification from the results of this discussion, if there isn't one 
already?

> Not really. All the embedding stuff was designed by Torben with KSpread at
> its center. This is why KoDocumentChild stores the coordinates of the
> embedded objects, using integers (ouch, bad for a doc object, should be
> doubles to allow zooming). For KWord and KPresenter, this storage there is
> redundant (since all objects already have document coordinates), so it's a
> pain to keep in sync. A Ko*Child rewrite in the back of my head would
> include removing the coord storage in KoDocumentChild, to let it be done by
> the application. But this needs more thinking...

Yes, I don't think I am grasping this, really. What I have noticed is that, in 
Krita, the viewport should always be the same size that the image is, for 
embedded objects, and that I can implement panning in Krita.

> > The basic KOffice part is a frame that gets
> > activated on a double click. For applications with layers, like Kivio,
> > Karbon and Krita this is inappropriate: we have a stack of layers, and
> > the contents of a layer can be positioned anywhere in that layer. The
> > layer gets activated whenever the layer is selected in the layerbox or
> > through keys, not by clicking inside a rect.
>
> Hmm, well, the activate-on-dbl-click code is in the apps, you don't have to
> use it, so I see no problem there.

I must have missed something here: isn't it necessary to use koFrame for 
embedding KOffice parts? And that seems to send a partActivateEvent to the 
view.

> No, we can do transparency already, kword does it for its own text frames.
> The problem is that the painting in the hosting app is a bit more involved,
> it must paint the stuff below the frame first (into a double-buffer
> pixmap), and then paint the transparent embedded object on top. But then it
> needs to know if the embedded object supports transparency, otherwise this
> is such a waste of time...

Besides, this would make it hard to work with layers, where you want each 
layer to render itself with transparency, because the composition will be 
done by the host application. Maybe the problem is that going through a 
QPainter is a pain; I just need a QImage with transparency. The compositing I 
must do myself.

> I think all components should honour the transparent bool (another TODO
> there...) but we certainly need that bool: if you embed a kword box into
> kspread I think you don't want to see the grid of the cells through the
> text, the result would be unreadable.

That's true... I hadn't thought of that.

> OK, no idea on any of that.
> Except that if you want xmlgui-merging, just use a KXMLGuiClient, no need
> to "extend kxmlgui" afaics.

Well, what I thought I wanted was a way to define QDockWindows in the same way 
as toolbars, something like

<!DOCTYPE kpartgui SYSTEM "kpartgui.dtd" ><kpartgui name="Krita" version="9">
<DockWindow name="controldocker" type="slider|tab|toolbox">
	<DockWidget name="blabla"/>
	...
</DockWindow>

But that falls down because palettes in dock windows aren't actions, of 
course. But I found some very old mail in the koffice-devel archives where 
you mentioned that Kivio and Karbon were unusable because of all the dock 
windows; but that was before QDockWindow appeared, actually. I'll just need 
to find a way to avoid keeping the dock windows around after a part gets 
deactived, and a way to avoid duplicating the dock windows whenever a view 
gets split.

>
> > I'm quite willing to start hacking on this; but it's perhaps an idea to
> > spend some coordinated thinking & hacking effort on this during the
> > Akademy hacking days? I'm in Malaga from Friday to Friday (when my plane
> > leaves some ridiculously early time in the monring).
>
> Yes. I think Raphael has things to say on this topic since it was his
> Google-SOC proposal...

Good -- I have to leave Friday morning very early, so we should schedule this 
for Wednesday or Thursday, I think.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]