[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-09-07 6:58:58
Message-ID: 200509070858.58259.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 06 September 2005 11:25, David Faure wrote:
> On Wednesday 20 July 2005 09:23, Boudewijn Rempt wrote:
> > 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?
>
> I don't know of more than the API docs.

Ah... That's a little insufficient:


*  Paints the data itself. Normally called by paintEverthing(). It does not
*  paint the children.
*  It's this method that %KOffice Parts have to implement.
*
*  @param painter     The painter object into that should be drawn.
*  @param rect        The rect that should be used in the painter object.
*  @param transparent If true then the entire rectangle is erased before 
painting.
*  @param zoomX       The zoom value to be applied to X coordinates when 
painting.
*  @param zoomY       The zoom value to be applied to Y coordinates when 
painting.
*
*  @see #paintEverything

And the reference to paintEverything can just ass well be deleted, because it 
doesn't tell us much more.

> > 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, it catches the one sent by the view.
> KWChild::hitTest in kword/kwpartframeset.cc shows how the app has full
> control over when a part gets activated.

I will investigate that.

> Well, Qt4 allows to use QPainter to draw onto a QImage, this might be a
> solution?

Yes, I think so. The pass-a-painter model is cute, but I'd prefer to compose 
the view myself of several QImages. So passing a painter onto a temporary 
QImage would do the trick for Krita. Something to remember for the Qt4 
version.

>
> > <!DOCTYPE kpartgui SYSTEM "kpartgui.dtd" ><kpartgui name="Krita"
> > version="9"> <DockWindow name="controldocker" type="slider|tab|toolbox">
> > 	<DockWidget name="blabla"/>
> > 	...
> > </DockWindow>
>
> OK, Simon and I were thinking about a possible simpler concept than XMLGUI
> for KDE4, so let's postpone that part of the discussion :)

Ok -- but I've already done most of the work to make it easy to compose docker 
windows and palette tabs. I just need to fix drag & drop of tabs between 
dockers and thin air, and saving and loading of docker and tab positions in 
sessions. Works without any XML.
-- 
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]