Most people will have seen my blog entry on embedding kparts in Krita already,
but I always intended to discuss the topic here in a little more detail.
Basically, working through the embedding code for K parts, and trying as
many possible combinations of embedding documents in documents I came across
the following problems:
* Scaling. Not many K apps seem to agree about scaling -- this means
that a KWord document in KSpread looks silly, and a Krita document in KWord
ridiculous. The only things that look reasonable are kchart or kformula
documents in KWord. I'm quite sure there has been a lot of discussion about
this issue already because the code is littered with comments I'd really
like a solution here, preferably a good one, but any solution that's at least
consistent would be a win (And I think the solution should be based on
real measures, as in "paint me you 2" wide document as it would look if blown
up to 12", but I only need a 3" viewport on it" -- that should be doable if
we decide to trust X dpi settings, and it doesn't matter much what internal
resolution an application like KWord uses. But I have probably missed
something essential here.)
* Pages vs Frames. Some K apps see their documents laid out on pages,
like KWord, Kivio or Karbon, others have a more freeform idea -- not really
frames, but just a vast expanse of possibility: KSpread and Krita. I think
that when embedding documents, the embedder should do the pages, and the
embedded document should confine itself to painting inside a rectangle,
without pagination.
* Framing vs stacking. I have this strong suspicion that K was designed
with KWord at its center The basic K 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.
* Transparency. That's another problem: I've found that most, if not all,
K parts don't honour the transparent flag (or perhaps the transparent
flag wasn't designed for this). I'd want any embedded part to paint only
the non-transparent bits. Like the glyphs of a KWord document or a KSpread
document. Is this something that can only be implemented with Qt4?
* QDockWindows & their ilk. Karbon and Krita use QDockWindows a lot, Kivio its
own style of dockers. I'm working on a library to unify them and to make sure
docker positions get saved and all that. But perhaps that wasn't wise, and
perhaps I should have extended KXMLGui with dock windows instead. At the
moment, embedding a Karbon document leaves Karbons dockers displayed even if
the embedded document is not activated, and that's messy.
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).

Tuesday 19 July 2005 19:06, Boudewijn Rempt wrote:
* Scaling. Not many K apps seem to agree about scaling -- this means
that a KWord document in KSpread looks silly, and a Krita document in KWord
ridiculous. The only things that look reasonable are kchart or kformula
documents in KWord. I'm quite sure there has been a lot of discussion about
this issue already because the code is littered with comments I'd really
like a solution here, preferably a good one, but any solution that's at least
consistent would be a win

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.

(And I think the solution should be based on
real measures, as in "paint me you 2" wide document as it would look if blown
up to 12", but I only need a 3" viewport on it" -- that should be doable if
we decide to trust X dpi settings, and it doesn't matter much what internal
resolution an application like KWord uses. But I have probably missed
something essential here.)

I don't see how dpi matters there (btw KWord uses the X dpi settings too, except
when using the -dpi command-line argument).
In your example you could call paintContent with zoomX==zoomY==6.0
and the appropriate rect for the wanted size.
What we can't do yet is let the user choose the "panning", i.e. the topleft coordinates
of the rect to paint. This is still TD somehow (in the GUI; the rect in the API allows
for it). But someone should also double-check if that rect is supposed to be
in zoomed or unzoomed coordinates. KWord uses zoomed, but that was a guess.

* Pages vs Frames. Some K apps see their documents laid out on pages,
like KWord, Kivio or Karbon, others have a more freeform idea -- not really
frames, but just a vast expanse of possibility: KSpread and Krita. I think
that when embedding documents, the embedder should do the pages, and the
embedded document should confine itself to painting inside a rectangle,
without pagination.

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

* Framing vs stacking. I have this strong suspicion that K was designed
with KWord at its center
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

The basic K 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.

* Transparency. That's another problem: I've found that most, if not all,
K parts don't honour the transparent flag (or perhaps the transparent
flag wasn't designed for this). I'd want any embedded part to paint only
the non-transparent bits. Like the glyphs of a KWord document or a KSpread
document. Is this something that can only be implemented with Qt4?
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
I think all components should honour the transparent bool (another TD 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.

* QDockWindows & their ilk. Karbon and Krita use QDockWindows a lot, Kivio its
own style of dockers. I'm working on a library to unify them and to make sure
docker positions get saved and all that. But perhaps that wasn't wise, and
perhaps I should have extended KXMLGui with dock windows instead. At the
moment, embedding a Karbon document leaves Karbons dockers displayed even if
the embedded document is not activated, and that's messy.

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

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-SC proposal

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 K 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 K 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 TD
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.

K, 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

<!DCTYPE 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-SC proposal

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

Wednesday 20 July 2005 08:48, dirk.schoenberger (AT) sz-online (DOT) de wrote:

Sounds cool, technically. Could you use WidgetActions, where the actual
action is just a wrapper around a generic widget?

I didn't know that those existed

Sounds less cool. Why do you have to invent yet another custom composer
when an API for this already exists? Think of the hardware acceleration
possibilities ;)

Because the place where it exists is Krita! Krita cannot use out-of-the box
graphics libs for pixel composition because we require composition ops for
many different color models. This is way before we even start rendering on
screen. A K part embedded in Krita is rendered onto a cached Krita
paint device. Then we can apply adjustment layers to that paint device, like
filters. The resulting pixels are composited using any of the composition ops
and options of Krita, possible again being filtered in between. And only then
do we render the result onto a QImage and paint that on screen.

You can have, for example, and image with the following layer stack:

16bit/channel rgba background
sharpen filter adjustment
8/bit channel single color spot layer
K part layer
oilpaint filter adjustment
sharpen filter adjustment
8/bit channel rgba layer

All that is rendered onto a single 8-bit/channel rgba QImage and painted
into the view, using a QPainter with appropriate scaling and transformation.

Wednesday 20 July 2005 09:06, dirk.schoenberger (AT) sz-online (DOT) de wrote:

In theory you could use a Qt4 QImage as paint device. This would give you
the possibility to direct pixel access (limited to 32 bit RGBA), while
still being able to use hig-level rendering functions as offered by
QPainter.

For the final rendering, yes. For Krita internal use it wouldn't be
sufficient.

Quoting Boudewijn Rempt <boud (AT) valdyas (DOT) org>:

Although not related to Krita, there's one thing related to embedding
in K
I would be very pleased to be able to do: embedding a database in KPresenter.

If you could tell KPresenter to get data from a remote database (mysql, for
instance) it would be possible to have a slideshow always running and simply
change de data in the database (this would usually be done by an external
application). It may be implemented by embedding a Kexi KPart in KPresenter, I
think.

Most people will have seen my blog entry on embedding kparts in Krita
already,
but I always intended to discuss the topic here in a little more detail.

Basically, working through the embedding code for K parts, and
trying as
many possible combinations of embedding documents in documents I came across
the following problems:
--
* Scaling. Not many K apps seem to agree about scaling -- this means
that a KWord document in KSpread looks silly, and a Krita document in KWord
ridiculous. The only things that look reasonable are kchart or kformula
documents in KWord. I'm quite sure there has been a lot of discussion about
this issue already because the code is littered with comments I'd really
like a solution here, preferably a good one, but any solution that's at least
consistent would be a win (And I think the solution should be based on
real measures, as in "paint me you 2" wide document as it would look if blown
up to 12", but I only need a 3" viewport on it" -- that should be doable if
we decide to trust X dpi settings, and it doesn't matter much what internal
resolution an application like KWord uses. But I have probably missed
something essential here.)

* Pages vs Frames. Some K apps see their documents laid out on pages,
like KWord, Kivio or Karbon, others have a more freeform idea -- not really
frames, but just a vast expanse of possibility: KSpread and Krita. I think
that when embedding documents, the embedder should do the pages, and the
embedded document should confine itself to painting inside a rectangle,
without pagination.

* Framing vs stacking. I have this strong suspicion that K was designed
with KWord at its center The basic K 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.

* Transparency. That's another problem: I've found that most, if not all,
K parts don't honour the transparent flag (or perhaps the transparent
flag wasn't designed for this). I'd want any embedded part to paint only
the non-transparent bits. Like the glyphs of a KWord document or a KSpread
document. Is this something that can only be implemented with Qt4?

* QDockWindows & their ilk. Karbon and Krita use QDockWindows a lot,
Kivio its
own style of dockers. I'm working on a library to unify them and to make sure
docker positions get saved and all that. But perhaps that wasn't wise, and
perhaps I should have extended KXMLGui with dock windows instead. At the
moment, embedding a Karbon document leaves Karbons dockers displayed even if
the embedded document is not activated, and that's messy.

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).
--

Thomas Zander said the following, 2005-07-20 11:44:

PGP SIGNED MESSAGE
Hash: SHA1

Tuesday 19 July 2005 19:51, Pau Garcia i Quiles wrote:

>>Although not related to Krita, there's one thing related to embedding
>>in K
>>I would be very pleased to be able to do: embedding a database in
>>KPresenter.

IM we should have kspread cells that embed SQL Queries, or other links to
kexi to allow kspead cells to contain data from that database.

I said this a couple of times before over the last years, but nobody has
done it yet :-)
Maybe this is something our kexi friends could do to make their app more
connected to the rest of koffice?

It's not something like "we dont want to do that". It's more because there's
no enough workforce, even if we're releasing the stuff so frequently (every 3
months or so).

Thinks like this are on the TD list with priority #2.
#1 prior have only features that make Kexi feature-complete.
Also, integration of Kexi and other apps is mostly a matter of asking us what
and how to do, and thinking, thinking, thinking, -- it's far easier thing to
implement than (even if usability studies are here needed) missing Kexi's core
features. Thus, anybody who can contribute is welcome.

dirk.schoenberger (AT) sz-online (DOT) de said the following, 2005-07-20 09:58:

>>Quoting Boudewijn Rempt <boud (AT) valdyas (DOT) org>:
>>
>>Although not related to Krita, there's one thing related to embedding
>>in K
>>I would be very pleased to be able to do: embedding a database in
>>KPresenter.
>>
>>If you could tell KPresenter to get data from a remote database (mysql,
>>for
>>instance) it would be possible to have a slideshow always running and
>>simply
>>change de data in the database (this would usually be done by an external
>>application). It may be implemented by embedding a Kexi KPart in
>>KPresenter, I
>>think.

I think this isnot really about embedding (which mostly handles the visual
aspect) but more about something like "data sources", where the data to
visualize can be taken from several, even not static, sources.
Similar to the serial letter functionality in a word processing application.

Yes, this is not about embedding at all. What is mainly neded is universal
data source, completely not related to data presentation layer.

This said, it can be possible to embed some visual parts of Kexi, but these
most probably need to be prepared _especially_ for embedding within external
(mostly document-driven) apps, ie. using KoPart/KPart, not database-driven
KexiPart.

Pau Garcia i Quiles said the following, 2005-07-19 19:51:

Quoting Boudewijn Rempt <boud (AT) valdyas (DOT) org>:

Although not related to Krita, there's one thing related to embedding
in K
I would be very pleased to be able to do: embedding a database in KPresenter.

Let's avoid this term
s/embedding a database in KPresenter/linking to data sources in any koffice app/

I'd also like to rise one problem for further discussions related to linking
with db sources: compatibility with ASIS format (no, ASIS defines nothing
for databases for now).

If you could tell KPresenter to get data from a remote database (mysql, for
instance) it would be possible to have a slideshow always running and simply
change de data in the database (this would usually be done by an external
application). It may be implemented by embedding a Kexi KPart in KPresenter, I
think.

no, read
's
from 2003, but most of these statements are still valid.

Also note that the idea you mentioned here is rather an idea for "database
filesystem", and thus can be utilized at K or entire KDE level,
providing KI slaves (or something similar) on top of KexiDB db connectivity
library. Anybody interested with supporting that?

Wednesday 20 July 2005 11:03, Thomas Zander wrote:
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.

Some questions;

instead of the rect parameter; why is the cliprect of the painter not
used?

This wouldn't give you the translation, when painting something else than
the toplevel corner of the document. This info isn't in the cliprect of the painter.

When would zoomX be different from zoomY?

Due to DPI settings (where x != y).

Since the QRect parameter is based on integers, I think it should be made
clear that these are unzoomed values. it should be doubles,
right?

Yes, well, that's how things are nowadays, but they weren't that way initially.
I'm the one who introduced doubles for unzoomed values
Stuff from before used ints (like KoDocumentChild).

which is implemented in kodocument.cc to do the pixmap allocation and
erasing based on the transparant bool in the options class.
The class extending kodocument can override this method to disable the
double buffering if it does not support transparancy anyway. It just
will call paintContent directly after doing an unconditional erase.

Doesn't make sense to me. Painting opaque is the easy case, not the hard case

Wednesday 20 July 2005 09:23, Boudewijn Rempt wrote:
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.

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 K 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.

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.

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

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

</DockWindow>

K, Simon and I were thinking about a possible simpler concept than XMLGUI
for KDE4, so let's postpone that part of the discussion :)

Wednesday 20 July 2005 18:40, Thomas Zander wrote:
Wednesday 20 July 2005 17:55, David Faure wrote:
instead of the rect parameter; why is the cliprect of the painter not
used?

This wouldn't give you the translation, when painting something else
than the toplevel corner of the document. This info isn't in the
cliprect of the painter.

That sounds weird; are you sure?
What if only the bottom halve of a widget is uncovered and needs repaint;
will Qt require the widget to paint the whole anyway?

No, only the bottom half. I see what you mean: provided that we have positioning
and panning information already (in the embedded object), we don't need
to pass a rect to paintContent(), the painter's cliprect can be used for that.
Good point.

Tuesday 06 September 2005 11:25, David Faure wrote:
Wednesday 20 July 2005 09:23, Boudewijn Rempt wrote:
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 %K 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 K 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.

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

</DockWindow>

K, Simon and I were thinking about a possible simpler concept than XMLGUI
for KDE4, so let's postpone that part of the discussion :)

-- 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.