Many things are missing in the current library.
The ones with a "*" are priorities.

WIDGETS:
	* kill selection in text entry
	* Input of composed characters in text entry : Input method
	- Alignement left/right in an horizontal widget
	- Framing (border + name) : decorator enhancement
	- zmw_table : border are too small to be draggable
	* zmw_window_drag(): Choose the window position relative to cursor
	  with values in current state.
	* Semantic Lens (move the code from book example to the library)
	* For the menu item with accelerators and the file browser,
	  the table lines must be focusable.
	    - It is not possible to put the widgets in the line inside
	      a widget focusable because the table can't compute the
	      alignment on grand children.
            - It is possible to replace the table by something like :
	          for(...)
			ZMW(zmw_hbox_activable())
				{
				zmw_x(..) ;
				zmw_label() ;
				zmw_x(..) ;
				zmw_label() ;
				}
	      But the optimal size computing is lost.			
	   - Or create a tabuled widget.
		zmw_htab_init(nb_widths, width, width_min, width_max) ;
	        for(...)
			ZMW(zmw_htab_activable(widths))
				{
				zmw_label() ;
				zmw_label() ;
				...
				}
	     "zmw_htab_activable" compute the maximum widths of the widgets
	     when they are not yet fixed by "zmw_htab_init"
	     "zmw_htab_init" set widths to the min and clamp to the max
	     This API allows to split table in multiple part.
		

LIBRARY CORE:
	- Store the default value in the resource so it is possible
	  to sometime purge the resources list from resources
	  equals to their default value.
	- Make a pile by attribute with a bit vector to indicate
	  which attributes where pushed.
	  So in the most current case, there only one 'int' to push
	  to push all the attributes (see at the end of this text).
	  Define the attributes in current state dynamicly
	- Use OpenGL
	- zmw_name must not be called with the same name for sibling.
	- animation: Specify the next frame time
	* Remove "zmw_pass_through" function (should be used everywhere)
	* event_in_(masked/focus) put in the correct place.
	* Create an explicit (in zmw_run.c) top level widget containing
	  all the other windows because it simplify algorithms :
		- no more "zmw_event_button_release"
		- function calls outside user top level widgets
		  are no more a special case.
	  It is not a small change.
	- Hide references to gdk inside zmw_device (apply also to widgets)
	* Currently, any change in "zmw" data structure imply a recompilation
	  of the applications : it is bad.
	  zmw-fast.h will allow fast and slim executable
	  zmw-slow.h will allow portable executable
	  Or better: a compilation option

MISC:
	* Append menu3.c example in the documentation

BUGS:
	- X window is locked (grab?) when debugging info is printed
	  (This is no more the case, I don't know why)
	* zmw_text(): the selection must be cleared on button 1 press
	- Window content has not the correct size a little time when the window
	  is mapped the first time. It is because gdk_window_resize
	  does not immediatly change the gdk_window_get_size result.
	  I do not see an easy way to correct this.
	- zmw_image_from_file are not freed : "when" is the question.
	  Add a timestamp in resource in order to free images not
	  used for 1 minute ?
	- A menu can't be inside a not popped (a normal) window.
	- Vertical cursors movement needs an attribute "x" in order
	  to have regular motion.

LIMITATIONS:
	- Only one button mouse is used.
	- if ZMW(zmw_popup()) contains a window, it must be its direct child

QUESTIONS:
	- Does the tips should appear if the mouse button is pressed?
	- Window in an invisible notebook page is not visible? Is it a problem?
	- Having children "not_used_to_compute_parent_size" in CHILDREN
	  complexify the size computation.
	  Should the CHILDREN_VISIBLE table be created?
	- Should zmw_action_dispatch_event be separated into
	  zmw_dispatch_button_press, zwm_dispatch_key_press, ...
	  It will simplify the drag and drop operation,
	  zmw_dispatch_test_receptor, zmw_dispatch_drop, ...
	- Create an zmw_action_assert to verify widget tree?
	- some space is taken to draw the focus, it is not the case for GTK
	  Which is the best way ?
	  
NOT TO DO THINGS :
	- Test "nb_draw" instead of wait a small time in the tests.
	  This value is unpredictable (because there is event
	  and a timer, the two things are not synchronized...)

	- Create a shortcut to stop tree traversal (complex).
	  Very bad idea, some functions may need a full traversal.
	  It does not speed hugely things so it is not interesting.

	- Code optimization done by computing an INDEX affected
	  to each widget is a bad idea.
		- The code is very complex
		- Other optimisations are not possible
		- 

	- The event dispatching must be immediatly stopped
	  when the user knows about a state change.
	  Because it can change the widget tree.
/*
*****************************************************************************
 * Idea about current state
 *
 * The current values are directly accessible
 *
 * First pass: compute the list of attributes modified
 * by the widget itself (not its children)
 *
 * When entering in a widget, the attributes it modifies are pushed.
 *
 * On value change: The value change
 *
 * When quitting the widget, the attributes are restored.
 *
 * This allows to not push everything in the stack each time.
 * But is it necessary to speed up this push/pop ?
 * push: 13% cpu time, pop: 0.9% cpu time
 * Using real booleans can speed up things
*****************************************************************************
 */



