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

WHAT I AM GOING TO PROGRAM NOW:
	* Convert d&d (widget/test/circuit/book/example/doc) to use
	  zmw_if in place of transients.
	* Remove all the transient management from the kernel.
	* Remove name_next and other next functions (and for previous)
	* Make the regression test in menu3.c (recursive menu)
	* Append menu3.c example in the documentation
	* Remove duplication as ZMW_XXX and ZMW_SIZE_XXX when possible.
          May be change padding convention to do the same thing
	  for the size (they are not the same : +-padding)
	* Remove name comparaison optimization (ZMW_INDEX, ...)
	  because they are too complex, don't allow infinite menu,
	  slow down many thing because other optimisation are not possible.
	* Remove "zmw_pass_through" function (should be used everywhere)

WIDGETS:
	- Alignement left/right in an horizontal widget
	- Text formatting
	- Focus navigation with keyboard
	- Framing (border + name) : decorator enhancement
	- zmw_table : border are too small to be draggable
	- Decorator: remove external or internal padding as an option
	* zmw_window_drag(): Choose the window position relative to cursor
	* Semantic Lens (move the code from book example to the library)
	- Change accelerator/menu management in order to have infinite menu
	- ``infinite'' depth menu are impossible because
	  Dispatch_Accelerator needs to follow all the menu.
	  So a widget "zmw_no_accelerator" must be created
	  to stop the recursion. 


LIBRARY CORE:
	- 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
	- zMw->size[0].alignement zMw->size[0].required for X axis ...
	  and [1] for Y axis.
	- Use OpenGL
	- zmw_name must not be called with the same name for sibling.
	* Cursor shape change when it enters in a widget
	- animation: Specify the next frame time
	- Create zmw_font_name zmw_font_size zmw_font_weight ...
	- Creation of substructs in zmw in order to clarify things

BUGS:
	* X window is locked (grab?) when debugging info is printed
	* 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 ?
	- Lurching : dispatch_accelerator does not manage children list
	  but everybody use it to test activation. It may be possible
          to have an action activating many widgets and the next
	  action is a key press.


LIMITATIONS:
	- Only one button mouse is used.

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?

	  
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.

	- Stop dispatching event when one is received by a widget.
          Because other widget may test the receiver widget.
	  (see the filechooser for example)

	- 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
		- 

/*
*****************************************************************************
 * 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 ?
*****************************************************************************
 */



*****************************************************************************
*****************************************************************************
Idea about transient.
*****************************************************************************

Current transient implementation is complex because
	- Widget may or may not exists.
	- Transient names are specials.
	- Not nice operation are done in the ``next widget name'' functions

Another way to make transient is to introduce a widget.
This widget is ALWAYS here, but its content is hidden or not.
So all the problem should vanish and the code is simplified because
the concept of transient widget is not necessary.
The new syntax that does not hide anything to the programmer is:

	ZMW( zmw_if(zmw_window_is_popped()) )
	   {
	     ZMW(zmw_window_popup_right()) { ... }
	   }

Alternate syntax not hidding the ZMW:
	ZMW( zmw_window_is_popped() )
	   {
	     ZMW(zmw_window_popup_right()) { ... }
	   }

Alternate syntax hidding all:
	zmw_if_window_is_popped()
	   {
	     ZMW(zmw_window_popup_right()) { ... }
	   }

Alternate syntax hidding more than all:
	ZMW(zmw_window_popup_right())
	   {
		// The popup window content
	   }


Old syntax:
	if ( zmw_window_is_popped() )
	   {
	     ZMW(zmw_window_popup_right()) { ... }
	   }

*****************************************************************************
*****************************************************************************

New transient syntax for widget drag.
A case go outside of the switch.

  switch( zmw_drag_from_state() )
    {
    case Zmw_Drag_From_Begin:
      break ;
    case Zmw_Drag_From_End:
      break ;
    }

   ZMW(zmw_if(zmw_drag_from_state() == Zmw_Drag_From_Running) )
      ZMW(zmw_window_drag())
	{
	}


Or :

	if ( zmw_drag_from_begin() )
		{
		}
	if ( zmw_drag_from_end() )
		{
		}
	ZMW(zmw_if(zmw_drag_from_running()))
		ZMW(zmw_window_drag())
			{
			}


*****************************************************************************
*****************************************************************************

Menu:

State:   1 if the menu is detached
       + 2 if the menu is poped
       + 4 if it contains a detached sub-menu

FullState:   State (current)
           + 8 if the new state value should be copied over the current one
	   + 16 * State (new)

The FullState is stored in the "int *detached" given by the
application or in the resource system.

When not dispatching event, if the new state value
should be copied it is done.

When dispatching event, the new state value is set to 0 and recomputed.
If current menu is detached or poped, upper menu new state are updated
until a detached one.

On read, the current state is read:
If  state&1, then the menu is detached   , the recursion continue
else
If  state&2, then the menu is poped      , the recursion continue
else
If  state&4, then somebody visible under , the recursion continue
else
             the recursion stop, nobody visible here or under



1c -+- 11i -+- 111i -+- 1111i
    |       |        +- 1112i
    |       +- 112i -+- 1121i
    |       |	     +- 1122i
    |       +- 113i -+- 1131i
    |		     +- 1132i
    +- 12c -+- 121i -+- 1211i
    |	    |	     +- 1212i
    |	    +- 122d -+- 1221v -+- 12211v
    |	    |	     +- 1222i
    |	    +- 123i -+- 1231i
    |		     +- 1232i
    +- 13c -+- 131i -+- 1311i
	    |	     +- 1312i
	    +- 132i -+- 1321i
	    |	     +- 1322i
	    +- 133c -+- 1331i
		     +- 1332d

