		===========================		    
                    RTK - DEVICE DESIGN
		===========================

		
1. Device, Canvas & OS
----------------------

    First of all we should clearly define what a device is. Device can be all
the platform dependent code. Or the drawing code for one platform. Or an object
representing a controller for a piece of hardware. I use the following names
for objects:

    - OS : the platform dependent code (file handleing (select), event reading,
	etc.). RTK has ONLY ONE OS object compiled in (X11, W32, WCE, MAC, etc.)
	That's why the OS objects are not implemented by subclassing and
	virtual methods. That would mean a lot of unnecesarry indirection.
	The current OS is compiled in by _including_ the corresponding file.
	NOTE: for cleaner code, all os dependent code will go to it's subdir,
	but we should also try to move as much code in the common files as we
	can.

    - Canvas : an object used for drawing. This can be called also an
	OutputDevice (see below why I still use the Canvas name)
	For one OS there can be several types of Canvas. There are also OS
	independent canvases. For example for X11 there can be two canvases
	for drawing on the screen: X11 and XFT, and a PS or PDF canvas for
	printing purposes.

    - EventGenerators : are in fact plugins, which reads data from a piece
        of harwdare and generates an event. Examples:
	* tablet: reads data from an additional/external table/mouse device
	    and generates the corresponding MOVE/PUSH/RELEASE events
	* remote-controller: reads commands from a socket, and sends special
	    command events to the application (image a presentation program
	    running on a bunch of computers, and is controlled from one of
	    them)
	It's the EventGenerators's responsibility to register themself and
	to send the events (I cannot find an elegant way to do this better,
	because only the EventGenerators knows when an event is recieved.)
	(Maybe having an 'IsEvent' method, and use polling on the event
	generators .... hmm ...)

    - Device : in my terminology, device is a driver for a hardware, from
	which, or where to the application can read or write data. Canvas
	and EventGenerator can be considered devices also, but they are very
	specific, and is better to treat them separately. Moreover Canvas should
	be optimized. If it's a must to see Canvas or EventGenerator as a device,
	a proxy can be used (see 1-device.dia).
	    The Device can create an IO through which the application reads and
	writes the data. The control line is implemented with GetParam & SetParam.
	The first argument is an integer, because it's faster to lookup integers
	(mostly when these integers are defined by the object, hence they probably
	are small positive values -> lookup table). 
	    Of course there is a need to use symbolic names. That's the use of
	Str2Id, which converts from symbolic names. Why not integer constants?
	Because the application may have to control devices, which are not
	known at compile time. And why there isn't a version of Set/GetParam
	with the first argument as String? Because this way we force the user
	to optimize the code, by looking up the symbolic name first (where it's
	the case, ie. for known devices).
	    The parameters of the device can be retrieved using GetParams
	(the return type should contain all the parameters with some description)

2. The OS and/or Kernel objects
-------------------------------

Because we will use namespaces, we don't have to create another object for this.
Also maybe we can combine the OS and Kernel objects. But first of all, what are
these ? OS is the collection of platform dependent code. Kernel is the new name
for Fl. So it's practically a collection of common methods. A part of the Kernel
can be considered the 'global' methods from the package 'core' (sleep, etc.).

The sections of the Kernel object:
(NOTE1: the sections which makes part of the core package are marked with 'CORE')
(       the sections where only a part of it is int the core, are marked with)
(	'core')
(NOTE2: the order is random)

    1) window management 
	- first_window
	- find_window 
	- set_window_title
	- etc. (maybe includes the Fl_WM class also)
    2) (CORE) handler and callback management 
	- add/remove-fd
	- add/remove-idle
	- etc.
    3) (CORE) plugin/module management
	- (un)load-module
	- (un)load-plugin
	- enum-modules/plugins
	- (de)activate-plugins
    4) (core) retrieve information
	- get_screen_info
	- get_host_info
	- etc.
    5) (core) messages and logging
	- get/set_message_priority 	<-- each message can have a priority
	- open/close-log		<-- messages can be logged in a logfile
	- set_message_callback
	- message, error, fatal, warning
	    - several callbacks can be defined, a few of them are predefined
		ex. CB_LOG_FILE -> to log the message in a log
	    - priority may be given for each message callback:
		- all messages are written in a logfile	
		- the most important ones are shown in a popup window
		(of course the priority maybe considered the message type, ie.
		error, fatal, warning, etc.)
    6) events
	Events are encapsulated in objects, because
	    - the application this way may store, queue events
	    - the application/device can generate events
	    - there will be a global event object, called last_event,
    		thus there will be no speed loss comparing to the current
		implementation
	- last_event	
	- send_event	<-- sends the event immediately
	- queue_event	<-- enqueues the event conforming to it's priority
	- flush		<-- remaint everything what needs repaint
	- handle
	- etc.
    7) waiting & main cycle
	- wait
	- run		<-- the current implementation of these methods
	- check		<-- proved to be OK, so it should remain the same
    8) (core) initialization
	- args
	- open_display
	- init_locale
	- etc.
    9) (CORE) threading
	- lock/unlock	<-- there will be a separate thread object		
	- etc. 		<-- some methods to controll ALL the threads
    10) (CORE) misc. utility function
	- get_ticks
	- sleep
	- etc.
    11) ... any ideas ?
		