koffice/lib/kofficecore/THOUGHTS

------------------------------------------------------------------------------
-  Bugs and missing features in the KOffice Library                          -
-  some initial brainstroming... comments? flames?                           -
------------------------------------------------------------------------------

1) Accurate Coordinates:
IMHO it's a must for KOffice applications to store reasonably accurate
coordinates. If zooming is supported I think we should try to make it work
up to zoom factors of ten (1000%) or so. This means you need some kind
of "spare precision". Another related issue is getting KOffice applications
support 1:1 sizes on the screen (i.e. that an A4 paper is A4 also on the
screen). Here the problem is that in X we can have a wide range of
resolutions (from 75 or so up to 120 dpi). We also can have different
resolutions in X and Y direction, but as Qt only honors one of them (the
Y resolution) I think it's safe to ignore the X resolution (see
QPaintDevice::x11AppDpiY()).
In lib/kofficeui we have some classes replacing QPoint/QRect (they use double
precision floating point numbers to store coordinates).

2) Embedding:
2.1) "Plain" KOffice embedding (paintContent):
We finally added two double values for the X and Y zoom factor. This means
using these values and the QRect argument we can "ask" the part to draw
certain areas of itself. One problem I still see with this method is, that we
only have a QRect there. It's not that problematic there because we can
agree on some hacks if it's not accurate enough (e.g. values * 100.0), or we
just agree that this QRect represents screen pixels at the given zoom value(s)
and the app can calculate the requested area to be painted itself. This should
solve zooming and "scrolling" problems.
One ugly problem also is what we will do about performance problems on
tqrepainting a part. Some time ago we got a mail on KOffice where some guy
asked what to do about making that embedded painting faster. The reason is
that we *always* tqrepaint the whole area, no matter what. This can easily be
optimized to a WNorthWestGravity like behavior, because you can't edit those
embedded parts anyway, so even kchart and other non-WNG apps support that.
( we have to translate the painter, of course).

### Zooming Special (copy from DESIGN_zooming in kofficecore):
There are two kinds of zooming:
 
1) View Zooming:
This kind of zooming is only done by full KoViews, regardless
whether they are the root views (not embedded), or they are
*active* embedded views. There only has to be a KoView object.
 
There is *one* zoom factor for both axes (x/y) and the whole
content (text, objects, tqchildren,...) is zoomed accordingly.
 
This kind of zooming is like the zoom support you know from
other applications.
 
 
2) Child Zooming:
Imagine you'd like to show a certain part of an embedded
document, but you have to fill a specified area. At the
moment this is "impossible" (we know that it's kind of
possible, but it's not straightforward) because when you
resize the child's frame, the contents resize, too. Due
to that you see more of the child's content :)
 
The solution will be: If you simply resize a frame, the
child document will resize, too, and show more contents.
If you press Alt/Meta during resizing, the child's
content will stay the same, but it will be zoomed to
fit the rectangle you specify.
Pressing Shift gives you a constant width/height ratio
during resizing.
Pressing Alt+Shift is allowed, too, if you can do that :p
 
As you already know we'll support a zoom factor for
each axe here. (i.e. x/y zoom factors)

Related to that is child-panning. Indepenent of the zoom factor
the child shouldn't just show the left/top corner, but it should
"remember" the position inside the document when it's tqrepainted
as inactive child.
###

If a part doesn't support zooming natively we have to fall back to WMartix
hacks (don't know how we can "ask" a part about that, but I'm sure we tqfind
some BC way).

2.2) Widget embedding:
That's a tough topic... but let's see... There are a few different possibilities
we have to treat differently:
a) plain KParts:
We can only embed the widgets obviously. Printing will look horribly, but
I think we should support that nonetheless. Imagine a KPresenter (screen)
presentation with an embedded video player part on some page :))
I'd say when printing those files the parts aren't printed at all by default...
makes more sense to me than redirecting an ugly 96dpi printout to some
QPrinter... well. It should at least be possible to print that stuff and get
some crappy output (but at least some output, e.g. an empty frame with some
text information about the part in it). Of course the user should be warned
before embedding such parts :)
b) embedding special KOffice parts as widgets:
Here we can simply add one entry "X-KDE-EmbedAsWidget" or so to our
.desktop files for KOffice parts. This will guarantee then that this special
part wants to be embedded as a widget. This surely makes sense, but still
we have some problems on printing... no idea how to solve that one. Maybe
we should use the widget for viewing on the screen and fall back to a plain
paintContents when printing.

General embedding stuff:
Do we support the "transparent" flag in paintContent with all parts we have?
IMHO it's a nice feature and we sould keep it, but if no part supports it...
well :]
Maybe we'll have to add a X-KDE-DoNotEmbed flag to the .desktop files
at some point. These parts should be excluded in the part select dia, then.

3) Handling of embedded parts:
This is one of the most annoying things in KOffice. Every application
handles embedded parts different. Of course this makes sense for most
of the cases, but maybe we can make that a bit more consistent at least
among "object-based" applications like KPresenter, Kivio, and KIllustrator.

4) Printing:
Here the problem is that even Qt has enough problems with printing :(
We definitely need some magic here, because right now we don't take
any advantage of the better resolution of the printer. This will be a hard
job (and an ugly hack) even if we have accurate coordinates and so
on. Lars told me that QPainter will have some setResolution call for
printing in 3.0... let's see. As a temporary solution he suggested to scale
the painter by 0.1 and print 10 times as big... don't know if that works.

5) Shell menus:
The Help -> About entry should be the one for the active part.

6) Image handling:
We need one class (IMVHO a part is too much overhead) which properly
handles all kinds of images. Internal ones, external ones, maybe thumbnails,
proper rescaling w/o any quality loss on rescaling again and again (read:
keep the original around),... Fortunately Simon already implemented most of it.
He also suggested that we need a very tiny KOffice part which just can
display images. That way we can finally support images in KSpread and other
non-object based apps.

7) Colors:
What about RGB-CMYK-HSV-LAB-... should this be solved in the KOffice libs?
I see some code for this in krayon, and maybe Matthias Elter or gis can help
us with that one.

8) General configuration options:
Do we need a KOffice kcm? What to configure there?
e.g.:
- start default template (which one :) (start without any template dialog)
- default page size
- default unit
- ...

9) Make it possible for components to provide their own about dialog.
   What's currently needed to acomplish this is an awful addShell()
   hack, like in kivio_doc.cpp .
    
   Possible solution:
   Make a slot in KoMainWindow call a virtual method in KoDocument which
   calls back the real show-about method. That would give components the
   ability to re-implement that very method and be done.

   Disadvantage: breaks binary compatibility.
   Possible workaround for the BC breakage: Don't call a virtual method
   but call/connect-to a slot in the document only if it exists and
   call the default show-about method otherwise.