This file describes the tasks at hand for making KSpread a better product.

Legend
======

Status field

----	No work has been done on this (sub)task yet.
DONE    Task is all done
done    This subtask is done
****	This (sub)task cannot be fixed with the current technology.
        It has to wait until something in the internals is fixed.

Prio field

S	Involves string changes.  Must be done before the freeze.
1	Important task.  Should definitely be fixed.
2	Semi-important task.  Should be fixed if possible, but can be
	moved to the next release if necessary.
3	Nice to have.  Should be fixed if there is time. (yeah, right)



BUGS
====
 ---    AutoFormatCommand does not redo() properly.




Things to do after the release of KOffice 2.0
=============================================

Item										Prio	Status
----------------------------------------------------------------------------------------------

* User Interface                                                                1       ----
  - Add a 'Go' ('Navigation') menu to select the active sheet. Reuse the actions
    from the 'Navigation' toolbar and add a sheet list (use KSelectAction?).
    'View' -> 'Goto Cell' should be moved there, too.
  - 'Rename sheet', 'Duplicate sheet' are also missing in the menu. Move
    them into 'Edit' -> 'Sheet'?
  - Improve conformance to the standard menu layout:
    `kde4-config --install config`/ui/ui_standards.rc

* Commands                                                                      3       ----
  CellStorage: Replace CellStorageUndoData* by a QStack<CellStorageUndoData>,
  so that cascaded undo recordings become possible.

* Thread support                                                                3       ----
  Move the dependency calculation and cell recalculation into a separate
  thread. In a first step the data manipulating actions should be disabled
  while running the cell recalculation. These actions could also become
  threaded later on. And as a final step, only actions acting on the
  affected cell ranges should be disabled, so the user can continue his/her
  work in other parts of the document.

* Databases									3	----
  Currently Database is used solely for the autofilter functionality.
  Generalize it: Rewrite the filter code, so that Database carries a data
  model. Such a generic data providing class will allow to add data imports of
  any textual kind.
  The OpenDocument spec urges to implement database queries, sorting and
  subtotal implementation this way.

* Page View Mode								3	----
  Add a page view mode. This would be a more intuitive way to see the printing
  layout. The pages should be based on KoShapeContainer, so that the TableShape
  becomes a child of it and can rely on its dimension to layout the table
  pages.

* Source-/TargetRange concept							3	----
  Currently, cell ranges, which data is exported, are called Binding. The
  opposite, cell ranges, that contain imported data, are called Database.

  Binding's only tasks are to track the movement of the range and to inform
  about value changes. To achieve this it contains a data model, which is used
  by those who want to work with the range's data. Nothing more; very
  minimalistic, very generic. The term SourceRange fits well here.

  Database, on the other hand, is more specialised, even if the filter code
  gets rewritten, so that Database contains a data model. That's because it
  was developed according to the database range in the OpenDocument spec and
  this consists of more than just a target range. For the case of filters or
  sorting, such a database always has got a source and optionally a target
  range, where the filtered or sorted output gets written to. Because of that
  the stored range should be separated from Database and named TargetRange.

  TargetRange will contain a data model, like SourceRange fka. Binding does,
  but retrieves data from it instead of feeding data to it. Additionally,
  both, SourceRange and TargetRange need a method delivering the current cell
  region name, because the range can be moved due to column/row/cell range
  insertions/removals.

  External apps or shapes or internal objects should work with an abstract
  interface, that provides the model and the cell region name, instead of
  directly working with the data model. E.g. KChart needs the correct cell
  region names in the dialogs even after the source ranges have moved.

  Same should be true for the Database's target range, even though the
  OpenDocument spec does not distinguish between absolute and relative
  addresses. My interpretation is that this means the cell ranges are fixed.
  (e.g. OpenDocument v1.1, 8.7.1 Table Filters, Table Range Address: "A differ-
  entiation between absolute and relative addresses is not possible. Therefore,
  a table name has to exist in the address and dollar signs are ignored.")
  OpenOffice does allow their movement though; an autofilter moves there.
  KSpread should go the most generic way: allow range movements and allow
  to fix the ranges by dollar signs, even if these are ignored in the ODF in
  this case.

  Summary:
  1. Binding* becomes SourceRange*.
  2. Refactor Database, so that it refers to a TargetRangeModel.
  3. DatabaseStorage becomes TargetRangeStorage.



Things to do before the release of KOffice 2.0
==============================================

Item                                                               Prio Status
------------------------------------------------------------------------------

Regressions
-----------

General bugs
------------
* Autofill							      3 ----
  Fix the 'May'-may-be-a-short-or-long-month issue.

Filter bugs
-----------

Things not in bugzilla
----------------------

* Printing
  + Repeated rows and columns don't work if they don't start from     2 ----
    row/column 1.   Also it is not possible to enter just one
    row/column into the dialog, it always has to be a range (2:3).
  + Insert manual page break					      2 done
  + If the used increases(/decreases) and the print settings are      2 ----
    configured to have page limits, trigger an update. The
    calculation of the zoom factor for page limits is an expensive
    operation. Better move it into an own thread first.
  + Expand selection to page                                          3 ----
  + Fit selection to page                                             3 done
    Use page limits of one page in each direction and print just the
    selection.
  + Multiline headers/footers                                         3 ----

* OpenDocument file format
  - see TODO.opendocument					      1 ----

* OpenFormula compliance (Medium group)
  - implement all functions of the Small and Medium group	      1 ----
    see koffice/kspread/functions/TODO
  - implement the calculation settings				      1 ----
    see section 8.5.2 in [1] and section 3.3 in [2]

* Flake integration.
  + Cell anchoring						      1 ----
    - Saving								----
      Query the shape container of the sheet before iterating over
      the cells. Store the shapes anchored in cells in a QHash. Put
      that into a saving context and pass it to the cell saving
      methods. Write out the shape at the appropriate place.
    - Interaction							----
      Shapes anchored cells should be moved, if the cell itself
      got moved; either by column/row/cell range insertions/deletions
      or by column/row dimension changes.

* Internals (See also DESIGN.html)
  + Cell Storage						      1 ----
    - (Re-)Adjust the saving algos to use the new (old) iteration	----
      functionality.
    - Rewrite the MergeManipulator to work directly on the CellStorage.	----
    - PointStorage: Implement setLoadingEnabled(bool) that switches	----
      the insertion method to a mode in which the value, column and
      row are just appended to the vectors.
    - Point-/RectStorage: All yet stored data is implicitly shared.	----
      Make use of this fact: Implement book-keeping with a hash and
      reuse the already stored values. This is already done in
      StyleStorage.

  + Style Storage						      1 ----
    This would dramatically reduce memory consumption and allows
    styles for empty cells.
    - Improve the saving.						----
      Only StyleStorage::Private::usedArea should track the occupied
      cells only - not those of columns or rows. Adjust the saving algo
      appropriately.
    - Add configure option to choose wether the style of the current	----
      or of the previous (default) column/row is used on insertion.
    - Launch the garbage collection in a separate thread.		----

  + Rich text in cells.						      1 ----
    - Use KoText.    							----
      Add a RichTextStorage containing one(!) QTextDocument consisting
      of a sole table. This obsoletes LinkStorage. Plain text can still
      be stored in ValueStorage, but does not have to: unsure what's
      best in this case.
    - Background spell check (necessary to have rich text)		----

  + Evaluation of how best to increase floating point precision.      3 ----
	Suggestion:  GnuMP.    (Tomas)
	This will work by converting all functions to compute using
	ValueCalc, and nothing else, then modifying Value* to
	support GnuMP.  The conversion step shall be done as a part
	of converting to the new parser.

* GUI
  + Indent and multiline doesn't work together			      2 ----
  + RegionSelector						      2 ----
    - add syntax highlighting
    - intialize choice on focus in events, if necessary
    - fix the line edit height
    - implement single cell restriction (maybe in Selection)
    - jump back to parent dialog on closing the mini dialog
  + Scrollbar that supports jumping one row/column forward or back    2 ----
  + New dialog for conditional cell styles                            3 ----
    The dialog should allow to define a variable amount of
    conditional styles - not just three.

* Formula/Value engine
  + DependencyManager / RecalcManager				      3 ----
    - Port to a threaded approach.                               	----

  + Matrix operations						      2 ----
    - Determinant							done
    - Dimension								----
    - Inverse								done
    - Minima/Maxima elements						----
    - Multiply								done
    - Norm								----
    - Rank								----
    - Transpose								done

  + References to cells in other files				      2 ----

  + Tools->Auditing:						      2 ----
    - Trace Precedents						        ----
    - Trace Dependants						        ----
    - Trace Error						        ----
    - Remove all arrows						        ----


* General features
  + Split view							      1 ----
  + "Freeze/Unfreeze Panes"					      2 ----
  + Function optimizer ('Solver')				      2 ----
    - evaluate, if we're able to use linear methods (derivatives!)	----
    - evaluate, how to include side conditions				----
    - check wether the formula cell carries a valid formulas		----
      and further checks of used cell contents


* Major features (big effort)
  + Pivot tables						      3 ----
  + Scenarios							      3 ----
    See [1], section 8.3.3 for details.


Other things: (please add the things you are working on!)


Not yet sorted (will be entered into categories above)

- Multiple Operations (in Excel: "Data"->"Table")
- Insert widgets like buttons, drop down lists,... + having the possibily to
  define action if pressed, or selection changes,...
- Button + Drop-Down-List support (within cells)
- interface for mail merge
- for formulas: fit precision so the result fits in the cell or resize the cell

- changing text angle should resize the cell height automatically
- support for format strings (dd/mm/yyyy)
- more font attributes (outline, shadow,...) + attributes for parts of the text
- double borders
- better AutoFormat dialog + better templates

- more "Related Functions" in function help/desc text
- improve function compatibility with MS Excel
- more information functions (Excel compatible)

- enhance the Gnumeric import filter
- sync the Gnumeric export filter
- StarCalc/OpenCalc import filter
- StarCalc/OpenCalc filter for embedding/embedded objects
- StarCalc/OpenCalc export filter
- dBASE export filter



References:
===========
[1]	Open Document Format for Office Applications (OpenDocument) v1.0,
	http://docs.oasis-open.org/office/v1.0
[2]	Open Document Format for Office Applications (OpenDocument),
	Recalculated Formula (OpenFormula)
	http://www.oasis-open.org/committees/office
