TODO-List
=========

Bugs:
-----
- textformatter: need to check for line-level breaking during the formatting of each line
Currently we do it afterwards, so if the margins differ, where the line ends up, we can't notice.
- solve problem with a change in the available width right in the middle of the
character we're trying to place (e.g. and it needs to move down to where the width is bigger)
Possible solution: let getMargins return a "valid for a height of ... only",
and then kotextformatter needs to move down by that height if .... hmm done.
- footnotes: check move to next page, endnotes
- anything else that http://bugs.kde.org mentions ;)

Differences with OO that ought to be fixed:
-------------------------------------------
- space above and below paragraphs is QMAX()ed indeed, like QRichText originally did.
- offsetFromBaseline should be a % (of the font size) instead of an absolute pt value,
  even in the GUI (which currently limits to +/- 9pt).

Missing or incomplete stuff:
----------------------------
- Draw frame internal margin in some gray color so that one can see why there's no
text there, or worse, then the margins are so big that no text can be drawn.
- Even/odd pages
 - Add SheetSide config in framedia 
- Tables should get a title (with positioning posibility)
  This will basicly be a new frame placed on top or at bottom of table.
  And it shouldn't be limited to tables - any frame could get that.

Other missing features:

Sideheads (for text)
Split frames needs to be implemented.
Styles have to be saved external (and/or an import/export facility).
Books (collection of documents) should be implemented
Implement complete DCOP interface
Make everything scriptable
Add "TopOfFrame"-TopOfPage" etc to styles.
add "Keep this parag with the next/prev" options to styles.


External files:
--------------
Included files (pictures/parts/formula's)
- It should be possible to keep files external. Kword should also notice a changed file
  (preferably at runtime) and reload it.

-> Proposal:

On placing a picture or part we get an insert dialog. This dialog could be changed 
to include a checkbox "keep file external". If changing the file-dia is a problem 
we could show a dialog just after the file-dia.

On placing the picture in the document we should create a thumbnail on screen at the 
screensize. This counts for both internal and external pictures. With todays computers 
I am not really concerned with filesizes anymore, besides; it would probably be about 30k max. 
They will be saved as:
 tar:pictures/

The internal pictures should be read into memory and saved to the tar in a dir like
  tar:raw-pictures/ 
and
  tar:raw-parts/


When another instance of the same picture/part is placed we should just use
the same object we allready use. We could consider creating a newly
scaled thumb if the sizes differ a lot. The raw file will stay untouched.
 
[ TODO: evaluate how the API suggested below integrates with the (more recent) KoImage stuff ]
 
kofficecore/ImageContainer.cc
 manages a picture. You can ask it for thumbs, location, the raw file
 and it has a save function.
 - ImageContainer(QString filename, bool external);
    constructor.
    if filename starts with tar or external is set: store filename.
    otherwise read raw file in mem.
 - int refCount()
    keep internal usage count
 - koImage* thumb(QSize);
    look in tar if there was a thumb. Otherwise create one of selected size.
    note that koImage also does referece checking.
 - void incCount();
    for usage count
 - void decCount();
    for usage count
 - koRawImage* image();
    Return the rawimage (in a stream??) either from mem or from disk.
 - save();
    well, it saves.
 
kofficecore/PartContainer.cc
 manages a part. You can as it for location (key), the part and it
 has a save function
 - PartContainer
    constructor
 - refCount()
 - void incCount()
 - void decCount();
 - koSomething* part();
 - save();
 
kofficeCore/ImageCollection.cc
 - ImageCollection();
 - ImageContainer* image(filename);
    return imageContainer, if one doesnt exist create it first.
 - int count();
    return number of images in the collection
 - void removeImage(filename);
    remove image from collection
 - void load();
    load all imageContainers
 - void save();
    save all imageContainers
 
Note that you can not resize an image, just the thumbs.
Note also that the 'key' is its filename. With full path that makes it http://
or file:// or tar:// for remote, local, internal storage respectively.
 
Last note: this proposal does not propose any gui/printing issues at all.

Thanx to: Reginald Stadlbauer <reggie@kde.org>
Author: Thomas Zander <zander@kde.org>
New maintainer: David Faure <faure@kde.org>


OK-ing the stylist seems to apply style change to all styles, not just the changed ones...

Add a RMB option on a copy-frame to update position of all copies in that FS.
Add RMB option on text to copy current format to a (new) style. Including tab positions..

- picture insertion point when pasting should be as an inline frame. Using default placing methods.
- cut/paste of images do not work across documents (also in bugs.kde.org)
- auto-update TOC before printing, so no doc is printed with an out-of-date TOC. It might alter the layout, ok, but an out-of-date TOC is just a waste of paper (besides being misleading...)
- interaction with frame breaks are a bit strange. How do you remove it? You cannot select it, nor can you use backspace or del..
- the stylist has a poor use of pixel space. Huge preview areas, for sometimes just 4 radio buttons. Too many tabs too...
My suggestion would be to combine "Indent and Spacing", "Aligns" and
"Borders". The Preview would be very similar to the preview for the two
first. Also, for alignement, you can use the icons readily available in
the actions of KDE, providing the text as tooltips. Use icons whereever
you can, providing help with tooltips. People will get used to them, and
if they forget, there are tooltips about 2.5 seconds away.
This way, you can save a lot of screen space, and maybe even the
tabulators would fit in that single tab.
Generally, I like interfaces which display all the info you need, maybe
a bit dense, but also knowing there's an easy way to know what they
mean. Toolbars are the greatest example of this.

- one should be able to introduce dependencies between styles, so if I want to change the general font of the text, I do not have to modify all the styles.
- If I specify a "document title" in the preferences, I would still like to see the filepath in the window titlebar.
- when writing bulks of text, when the cursor gets to the border of the window, it should not only scroll 1 line (to make sure the cursor stays in the visible portion of the document) but should be moved to the center of the window (like in emacs:-). So the average position of the cursor is the center of the window, rather than the bollom line.

- interaction with KoParts is somehow strange. Especially positioning them in the document, as the size when using the handles is not the same as the end product. But I am not used to it in the Windows world either...
  This is due to the problemsn that we don't zoom and dont allow easy moving in the parts. A square which representst the whole placed document when moving just the little screen would be nice.
- rotating pictures. Is that possible ?
