Added old abandoned KDE3 version of koffice

git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/koffice@1077364 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

1 files changed, 164 insertions, 0 deletions

diff --git a/lib/kofficecore/THOUGHTS b/lib/kofficecore/THOUGHTS
new file mode 100644
index 00000000..f0121aa9
--- /dev/null
+++ b/lib/kofficecore/THOUGHTS
@@ -0,0 +1,164 @@
+------------------------------------------------------------------------------
+-  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
+repainting 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* repaint 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, children,...) 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 repainted
+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 find
+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.
+