The following list of TODO-items is NOT complete!
Also, plans change frequently. If something is listed for a specific release, that's no more than a rough plan.
All in all, this TODO list is mostly for internal purposes, and many parts may not necessarily be intellegible to anybody but the authors.

- Advertizing:
	- start being a bit bolder about RKWard (descriptions, startup notification, etc.)

Some items I'd like to get done for 0.3.6 or whatever the next release is going to be called, if they don't take too long:
- RKEditorDataFrame
	- undo/redo
	- deletion of multiple columns in one step
- Rework package management dialog
	- use install.packages () to handle dependencies
	- manage R library locations, install to location with user write access
	- the UI should probably be simplified somehow. But how? All in a single list with "filter"? Ask for ideas/look at other apps
- Create an editor for single vectors/factors, or rework RKEditorDataFrame to handle those as well
- RObjectListView
	- use icons to mark up the different base types
- David's usability items
Optional stuff, that could possibly be attacked for 0.3.6:
- RExpressionObject as an abstraction for R-Expressions (i.e. manually edited expressions).
	- It will be possible to "store" these in the RObjectList and select them just like any other object
	- RKVarslot will allow editing the selected value by hand (or just typing the name in)
		- How to do this nicely UI wise?
- RFunctionObject for user defined functions. Maybe later it will be possible to use for functions from packages as well
	- would be nice, if it also had some knowledge about function arguments
	- ideally it would also know about the type of the return value, but this may not be realistic
Timeframe for 0.3.6 release:
- It would be good, if we're at a releasable state within one month from now (i.e. mid May).
	- if reasonably possible, I think we should release then, even if some of the desired features are still missing

RObjectTables sounds highly interesing. Maybe we can use a transparent table to find out about assignments?
R_MakeActiveBinding sounds even more interesting. Maybe we can use this to "watch" symbols?!?

Little annoying stuff:
- hide tabs in console
- add an example to show rkward-specific commands (rk.print, rk.graph)
- instead of delete RObject, call RObject::deleteThis () and check for deleted in rCommandDone ()?
- use more QDicts instead of QMap<QString,...>s
- use R_DirtyImage to determine, whether workspace needs to be saved
- in REmbedInternal, add extractTemporaryStrings (), for strings that do not have to be copied
- find out how to save toolbar states properly in parts-GUI
- use constBegin (), constEnd ()
- get rid of all the superflous dependencies: http://lists.debian.org/debian-devel/2005/12/msg00439.html

PHP-backend:
- switch to KProcIO for easier logic
- http://de3.php.net/manual/en/function.call-user-func.php seems to be faster than eval
- find out why an error in the backend often leads to a subsequent crash

- on viewDeactivated, it may not be safe to call setCaption and there activeWindow (). Apparently, the pointer may be invalid:
	- start rkward with empty table. open command editor. switch back to table. Edit some stuff in the table. Ctrl+W. Crash

Configuration options to add:
	- additional console options:
		- color highlighting for warnings/errors (once we can identify them reliably)
	- additional R engine options:
		- stack size (commandline arg --map-ppsize)
		- disable html help
	- new dataeditor options:
		- see below: comments on RKEditorDataFrame

RKHelpDlg:
	- in the mid term, this should probably be renamed and moved to windows
	- call .rk.get.installed.packages, and update package selection drop down on every show, but not on startup

- RKConsole:
	- Console should start a command chain when submitting a batch of pasted commands

RKwatch:
	- optionally keep a file log!

- check whether we're running in a PTY, and warn otherwise. Currently the R backend needs this.

- remove classes/files:
	- RKDocManager? Is this used?
	- RKGlobals
		- static members should be moved to the respective classes. Much cleaner!

stuff to do before 0.4.0 release
- plugins (general)
	- add import-filter plugins
- on exit, check whether there are still RCommands left in the backend and wait/request user-interaction before tearing down the thread. After all, the last command might have been a "save"!
	- How about always doing exiting via a "q ()" command in the backend, instead? That way we could always be sure, all previous commands have been completed before the q ()!
- error-handling/raising in .rk.do.call
- pick some from below:

code cleanups
- I've changed the simple RInterface::issueCommand (QString, ...) command to return a pointer to the RCommand created. This will allow for lots of small cleanups. Do them.
	- well, on second thought, it might be better to rely more on RCommand::id () instead of pointers. Why? The id is unique (until integer overflow). The pointer may be reused after a delete -> potential problem when trying to cancel command which is actually already deleted (and potentially other cases)
	- let's set this back for a while

API documentation:
- add page containing a rough overview of general architecture
- RCommandStack

(relatively) small stuff to do soon
- Twintable/RKEditorDataFrame
	- merge the two classes
	- more efficient syncing: fetch only the values actually needed instead of the whole table
	- make configurable:
		- invalid color (global and per variable)
		- unused color (global and per variable)
		- default alignment (per var type)
		- default precision
		- display of factor level labels (global and per variable)
		- delay of factor-level popup
	- highlighting of value ranges
- Object editing / modification tracking:
	- functions to set double/int/string-vectors directly. Use in paste-operations
- RKVariable:
	- use QIntDict instead of string-map for value-labels / factor levels?
- change EditLabelsDialog to use a small QTable? Probably a lot easier / straightforward to use
- plugins (general)
	- add more plugin-widgets
- formula-widget:
	- use smart sorting, esp. of generated string
	- add labels, add "up to level" option
	- add constant term option
- create a spinbox, that can really deal with real numbers
- UNPROTECT_PTR
- use RKGlobals::marginHint (), RKGlobals::spacingHint () everywhere
- give informative feedback on syntax errors (line numbers, etc.)!

stuff to do before the thing is usable
- add a help-system
- mostly everything

stuff to do before a 1.0 release
- handle graphics

Notes for x11-window capturing:
- See deactived class-header rbackend/rkwindowcatcher.h

################## menu structure file/workspace ###########
File
	New
		Dataset
		Script File
	Open R Script File
	Open Recent (Script File)
	Save/Load R Objects
		Save
			...
		Load
			...
	Save
	Save As
	Reload
	Print
	Quit

Workspace
	Open Workspace
	Open Recent (Workspace)
	Save Workspace
	Save Workspace As
	Configure Packages (redundant)

How should this be changed? Maybe:

File
	New
		Dataset
		Script File
	Open R Script File
	Open Recent (Script File)
	Open Workspace
	Open Recent (Workspace)
	Import (previously Load R Objects)
	Export (previously Save R Objects)
	Save
	Save As
	Save Workspace
	Save Workspace As
	Reload
	Print
	Quit


################## cryptic notes ######################

- printutils.c->481 Rvprintf: can we get at the standard out-connection and give it a fake vprintf (or better write?!) and fake fflush?
	- see also: connections.c line 3246ff InitConnections
	- seems ok now. But maybe we could still use this to catch immediate warning messages (which go to R_Consolefile)?

- still mysterious in warning-handling: 'help (doesnotexist); print ("stuff");'. Why is the order wrong?!

tryCatch (message ("a"), error=function (x) {print ("e"); x$message}, warning=function (y) {print ("w"); conditionMessage(y)}, message=function (z) {print ("m"); conditionCall (z)})
withCallingHandlers ({message ("a"); stop ("b");}, error=function (x) {print ("e"); x$message}, warning=function (y) {print ("w"); conditionMessage(y)}, message=function (z) {print ("c"); conditionCall (z)})

Not quite correct yet:
	.Internal (.addCondHands (c ("error"), list (function (x) {print ("e"); print (conditionMessage (x))}), parent.frame (), NULL, TRUE))

.Internal (.addCondHands (c ("warning"), list (function (x) {print ("w"); print (conditionCall (x))}), globalenv (), NULL, TRUE))

condition handlers seem to be reset after an error!
condition handlers do not seem to carry over two separate calls of R_tryEval ().

http://slashdot.org/article.pl?sid=05/06/24/149231&tid=121&tid=188&tid=95&tid=1
