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