1 files changed, 94 insertions, 0 deletions
diff --git a/kviewshell/TODO b/kviewshell/TODO
new file mode 100644
index 00000000..840653c7
--- /dev/null
+++ b/kviewshell/TODO
@@ -0,0 +1,94 @@
+API
+===
+
+If we want developers of other applications to move over to
+kviewshell, we definitvely need a stable and mature API. Here are some
+things that I feel need to be implemented, at least in API (it is
+probably ok if we don't implement all of them right now).
+
+* documentRenderer. This class needs documentation. We need to specify
+what the documentRenderer actually does at what time, and what signals
+it emits at what time and what they mean. Things that come to my mind:
+
+- specify what drawPage actually does. In kdvi, drawPage is a highly
+asynchronous method, that either does nothing (e.g. if font are still
+being generated), or really draws a page. The behaviour must be
+specified, and I believe that for printing (see below) we would also
+need to provide for a synchronous way of rendering pages.
+
+- some document formats include ready-made thumbnails. We should have
+have a virtual function that makes thumbnails out of fully rendered
+pages, which can be overloaden if the author of a specific file format
+supports 'embedded thumbnails'
+
+- in the future we probably want to use threading to render pages in
+memory to improve the perceived speed of applications. Thus, we will
+have to specify what methods need to be implemented in a reentrant or
+thread-save manner. Probably we should provide infrastructure for
+that.
+
+- support for reading and writing hirachical bookmarks for document
+that support that
+
+- some document formats, such as dvi, allow to READ the position of
+characters, which allows for full-text search, copying of text,
+etc. Other formats, such djvu allow also WRITING of such
+information. The idea is that you produce a djvu file by scanning a
+certain document, and than later add the position and
+character-information by using e.g. OCR software. We should at least
+have support for that in the API, even if we don't implement an OCR
+interface right now.
+
+- dvi has the special feature that it supports source information and
+uses that to implement inverse and forward search functionality. We
+must somehow make sure that even these unusual features fit well into
+our framework without too much of an effort.
+
+* kmultipage
+
+- kviewshell should provide a print dialog (with the extra option that
+certain document formats can insert their own configuration pages). I
+find the print dialog of Acroread 6.0 in OSX very well done. Then we
+should have a default printing implementation that uses KPrinter, etc,
+to print the pages (this will be used e.g. by kfax), and we would need
+infrastructure for implementation which have their own way of
+producing PS file (such as dvi, where dvips is the preferred method to
+print). 
+
+This may rise some important questions in documentRenderer API. For
+printing we would need a SYNCHRONOUS way of rendering pages to a
+qpainter object.
+
+
+
+DOCUMENTATION
+=============
+
+If we want developers of other applications to move over to
+kviewshell, we definitvely need a well-documented API, and some
+applications that demonstrate how everything works. In particular, we
+should have
+
+* lots of documentation, including API documentation and a tutorial on
+"How to implement a kmultipage"
+
+* an exteremely well-defined reference implementation for a trivial
+file format, either one that is actually useful (kfax, perhaps), or
+one that serves only demonstration purposes and that goes into the
+kdesdk module
+
+
+
+
+
+KVIEWSHELL APPLICATION
+======================
+
+* improve command line interface. The somewhat antique method of
+giving the library name in the command line should be replaced by a
+more modern method where kviewshell uses some kde wizardy
+(e.g. 'services') so that installed kmultipage implementations can
+announce what mime type they are supposed to handle, and kvieshell
+then loads them automatically
+
+