 This is the Graphics Vision TODO, kept in -*- Change-Log -*- format.

	Here you can find a list of things that should be done.
	Volunteers who want to help are very welcome, since I won't have
	the time to do it all by myself.  Any suggestions on what should
	be done are also welcome.

	This list is kept in Change-Log format, so GNU Emacs users get the
	[conditionals in brackets]: highlighted.  New ideas are added on
	top, bad ideas are deleted, and implemented ideas move into the
	ChangeLog file.  I will keep track of my ideas and other peoples'
	suggestions this way.

	I added (ratings in parentheses) to some of the items in the list.
	They say if 1. I think the task is easy or not so easy, and 2. if
	I will do this or rather not, or only if I am particularly bored.
	This is meant as a hint for people who want to contribute code.
	
	
1999-02-13  Matthias Koeppe  <mkoeppe@cs.uni-magdeburg.de>

	* gvfm2.pas [FPC]: (easy, probably-I) Prepare the file mgr demo
	for FPC. The resource must be taken from somewhere else, and
	GvEdit must be taken out because it is not yet available.
	
	* winres.pas [FPC]: (easy, probably-I) Implement the code-page
	translation functions (AnsiTo/From...)  This is not too urgent
	because svgalib can't output characters >=0x80 anyway:(
	
	* FPC-RTL/objects.pp, gvhelp.pas, gvtexts.pas [FPC]:
	(easy, probably-I) Make resources binary compatible, so that we
	can use the same helpfiles and language resources.  This must be
	done in co-operation with the FV people.
	
	* gvdemo.pas: (easy, probably-I) Screenmode code should be
	generalized. When color depth is changed, all views that keep
	images must be killed; not only the bitmap background. This is
	needed because Graphics Vision only uses device-compatible
	bitmaps.
	
	* [FPC-Linux] (dont-know, probably-I): Image clipping with
	>=32K-color modes seems to be buggy in svgalib 1.3.0, workaround
	needed. Icon artefacts in top of chdirdlg occur in all
	modes. Characters >=0x80 aren't drawn properly. Masked-image stuff
	must be implemented for important things like the ghost; note that
	the ghost is not meant to have a pink box.

	* [FPC-other] (advanced, not-I): GV should be ported to every
	other operating system supported by the Free Pascal Compiler.
	
	* [FPC-Linux-X] (advanced, not-I): There should be X-Window
	support, either based on the raw Xlib, or using some toolkit.  Any
	ideas, anyone who wants to implement this?
	
	* [FPC-Windows32] (advanced, not-I): The existing Windows port of
	Graphics Vision should be ported to FPC with Windows-32 API.

	* [Delphi>=2]: (easy, not-I) As we now have assembler-free
	implementations of everything, it should be easy to prepare the
	Windows version to work with 32-bit Delphi [this refers to the
	compiler, not the Delphi object library].
	
	* [FPC] (advanced, not-I): We have to draw our own mouse
	cursor. We are doing this with standard GV visibility management.
	No problem with efficiency.  But the mouse pointer will not move
	when the application is busy.  So we should create a second
	thread/process which just draws the mouse.  The graphics system
	should be locked with semaphores in this case.
	
	* gvviews.pas [FPC-Linux] (easy, probably-I): As there is no
	XORPUT WriteMode in Svgalib, we have to work around it in the
	cursor code, e.g. for the input line.  The current work-around
	simply draws a white bar over the cursor; this should be done
	better. 
	
	* Bgi, GvFPK, WinGr, VgaMem, GvDriver, ... [FPC, Windows, DOS]:
	(dont-know, only-I) Clean up the unit structure, maybe merging
	some of the named units into a single GvSystem unit, which will
	have different implmtn files in each of the supported target
	systems.  This should reduce both confusion with and length of
	conditional `uses' uses.
	
	* [FPC-GO32] (dont-know, not-I): Support of extra screen buffers
	in Graph.  If we can allocate some spare screen memory, redirect
	graphical output thereto, we can improve the performance of
	graphics drastically.

	* gvedit.pas, FV/editors.pas [FPC] (easy, not-I): The Free Vision
	`editors' unit looks pretty advanced, so I would very much like to
	see a GV version of it.  Anyone who wants to do this?  It is just
	a matter of merging-in the graphical display routine and set-up of
	the graphical dialogs.

	* [FPC-GO32] (easy, probably-I): The graphics system is still
	incomplete.  Metafiling or screen buffering, see above, must be
	implemented.

	* [FPC] (advanced, probably-I): It would we a good idea to use
	GRX, the extensive framebuffer graphics library for GO32, which is
	also available for Linux-Svgalib.  This would provide fonts and
	advanced graphics.

	* Documentation (easy/advanced, not-I): The technical
	documentation must be adapted for the current version.  English
	documentation should be written; any native speakers out there?

	* Internationalization (easy, not-I): Graphics Vision supports
	i18n by use of text resources.  German and English standard texts
	are provided.  Translate the text to other languages.  The English
	texts probably also need to be improved.

	* Design (easy, not-I): Implement new designs, which can be chosen
	at compile-time or run-time.  The current design, similar to
	Windows-3, is not what most people want to see today.  So go ahead
	and write code which makes GV look like the Mac interface or
	Openlook or Motif or KDE or newer versions of Windows.  Anyone who
	wants to write his personal powerful GUI with a certain look
	should consider simply changing the appearance of Graphics Vision.

	* Design: (easy, not-I) There is definitely need for a cool logo.
	This might also be used instead of the `Nilhorn' which currently
	appears in gvdemo.  BTW, I don't know what a Nilhorn is, either.

