[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: werner's koffice.kwd
From:       Simon Hausmann <sh () caldera ! de>
Date:       2000-09-05 8:14:56
[Download RAW message or body]

(some days ago Werner posted some very interesting thoughts)

>Some thoughts about design flaws in the KOffice Libraries and some other
>glitches. Maybe we can fix or at least discuss them in Erlangen! This
>is nowhere near complete, it's not sorted, and not even "spel cekd" ;)

;-)

>Storage Right now we can only handle "internal" storage. This means all
>the pictures, parts, and so on have to be inside the tag.gz structure. At
>the first glance this makes sense to maintain a valid document state even
>if it's moved around. The problem is that it's not very flexible. I think
>we should let the user decide what the best is, but it should default to
>"internal" storage. We can also add a small programm/script which creates
>a real tarball with all the external files and so on that the user can
>easily carry the document to another machine.

I really like that idea.

>Image Handling IMHO we need a unified way to handle pictures (in the
>libs). Insert a jpg in a KWord document and resize it a few times. It
>will look really bad. This picture stuff should be responsible for
>loading/saving (internal and external), return a "clean" picture even
>if the user resized it a few times and so on. You can find some good
>ideas in a proposal in koffice/kword/TODO (by Thomas Zander). This is
>not perfect, but it's at least a start.

I wonder about this if we can't use the component approach for images?

I mean... IMHO it's completely logical not to hack up extra image support
classes into the libraries but instead hack a koimage component (like Torben
originally did with the very first versions of koffice :) which is loaded
dynamically. Now that our component architecture is lightweight enough
(no more extra koimage process ;-) I think we can implement this in a 
performant/lightweight way.

>Coordinates Now that most of the apps support zooming (at least a little
>bit) we'll have to store the coorinates more accurately. I did some
>tests and benchmarks and it seems that plain double numbers are fine
>(performance and accuracy). I replaced nearly all the coordinates in
>the libs already, in the apps there are some inaccurate ints left, though.
>
>Hooks For some applications it would be necessary to have a little bit
>more "hooks" in the libraries. KWord, e.g., overrides setRootDocument()
>just to get a possibility to do something on activation. (Yes, I know
>that this doesn't work when it's embedded ;)

Yes fully agree that we need those hooks. I believe a good way to implement/
provide those is to use events (KParts::Events in fact) . This provides
a very high level of flexibility while still being easy to use (it's just
a matter of providing a convenience virtual method, like guiActivateEvent,
called from KoView's event handler) .

Example: KHTML used to have hardcoded hooks for mouse and keyboard events, 
for kafka. We replaced those hardcoded hooks (which make it impossible to
add more hooks without breaking binary compatibility!) with events. 
More flexible and easier to extend (doesn't break BC) .

>Filters This is mainly a KIllustrator issue. KIllustrator still has its
>own filter architecture which is a Bad Thing(tm).
>
>Embedding Why can I embed KWord? Is this useful? If it's useful, why
>is the paintContents() method not implemented? IMO we need another
>flag in the .desktop files which signals whether a part wants to be
>embedded or not. I still hope that KLyX will embed KOffice parts one
>day, but I don't think it's useful to embedd KLyX. You get the idea.

I like that idea. I think in the beginning the idea was that all
koffice components are supposed to support the embedding
100% . But it turned out that this is well, not possible (or
we simply lack time to implement it) . Therefore I like Werners idea
of having different levels of embedding support. Besides the
full-paintContent support I could think of a widget-embed level
(like we used to have with the old CORBA based framework) . This
second level (for which we can add container-support in the libs, I 
believe) would also make it a lot easier to add support for embedding
plain Readonly Parts into koffice containers! (which is something
I still dream of :-)

>Another issue is part activation and child document handling. Right now
>every app implements its own way of handling that. This is no problem as
>long as it "feels" the same for users, but unfortunately this is not the
>case. Apart from that we even face another huge problem: The way the
>"frame" around the child responds depends on the state of the child
>(activated/not activated).  KWord has another problem with that frame
>handling. As long as the part is not activated KWord ensures that it
>stays within the page borders. When I activate the part I can freely
>move it around on the parent widget. This leads to crashes in KWord
>at least.  There are also a few other problems we didn't yet decide
>on what to do. One example is whether child documents are allowed to
>have a document information file or if I may save the child document

Yes, these are important points we have to discuss at the LK.

>"standalone."  Communication The KParts technology is great, easy to use,
>fast, ... simply amazing. I have one problem with it, though. Why do I
>have to link KChart against KSpread when I want to "talk" to it? I don't
>know if in-process DCOP is a performance hit (server roundtrip?) or not,
>but we have to make use of that stuff in some way. To explain what I mean
>I'll give you a simple example: The user has got some data, enters/imports
>it in KSpread and wants to create a chart from it. Let's say my own toy
>application has matured and he uses graphite to create it. There are
>two possibilities which come to my mind: a) the user starts graphite
>as a separate process and "connects" to KSpread (plain DCOP) or b)
>the user embeds the chart and manipulates it either in embedded state
>or in a separate view (still as embedded child, i.e. in-process). How
>do we exchange data (in both directions)? Who saves the data and the
>graph? One of the programs? Both? This is something I really don't know -
>please enlighten me ;)

I think the kspread-kchart bundling can be solved by simply putting
the relevant interfaces into an intermediate library. Especially for
KChart I could really think of a general chart interface (like we used
to have with the old CORBA framework) . Technically no problem, I would say,
but mostly a matter of someone finding time for doing it :-}

>Utilities We have several unmaintained utility plug in's like the KCalc
>hack, the spell checker and the two formula editors (libkformula and
>the part).

I agree with David here: Let's keep them for now and clean them up after
2.0 (i.e. merge KCalc) . (that was that David said, no? :)


Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]