To do
=====

This version:
 * Tweak the themes, including Xeno Buffed. It should use colors from IReX.
   Tweak the theme Xeno Adept even more.

Scheduled for next version:
 * Make it work under GTK 1.3.x. It compiles now, but it crashes on initialization ... ;-)
   Almost none of the patches work, so they should be completely disabled.

 * Optimize for size. Squeeze it out. Object file should be less than 100000 bytes on x86
   when compiled with optimization, runtime checks disable and stripped of unnecessary symbols.
   It is 101084 bytes (on my x86 machine) when I write this... It has actually increased in size.

 * Lazy destruction of the last gradient. Chances are it might be the first to be recreated.

 * x86-assembler for some routines, such as gradients
   They really need to be optimized. They are sooo slow now, but generic.

 * Stepper-arrows will be pixmaps. No fgmid_gc.

 * Write some scripts to recreate the pixmaps with remapping info. Rewrite the remapping code
   to produce XImage's directly and use gamma correction.

 * Finish the new knobs.

 * Extra scrollbar button at top with two at the bottom.

 * Themes
   New:
     Emulate:
     - Xeno'Zilla
     - Xeno Easy
     - Xeno Stripes
     - Xeno Ray of light

     Colorful:
     - Xeno Blue	Blue colors
     - Xeno Ice		Light blue, thin frames
     - Xeno White	Very white, gradients
     - Xeno Dark

     Colorful themes:
     - Xeno Blue
     - Xeno Slate

     XenoStep/XenoFace themes:
     - Xeno DrugAngel
     - Xeno Simian


Future versions .. possibly:
 * A circular slider should appear on right-click in a numeric entry. (GtkSpinButton)
  I wrote a simple prototype with a simple slider as part of the widget itself.
  I am currently rewriting the slider as a separate widget with more
  advanced behaviour as outlined by Eskil Steenberg whose idea it was.

  When right-clicking in the numeric entry widget, a dial will appear around
  the mouse pointer. The dial is a slider with the look and feel of a pie-menu.
  The dial has the layout of a clock: the top is both for 0% and 100% and
  the value increases clockwise.
  If you drag from less than 100% beyond the top mark, the dial will stay
  at 100% until you drag it back. The same applies to the other direction.
  You could picture the dial as having a string from the center of the circle
  to the mouse pointer, and the top mark as a pin; If the pin catches the
  string, then it will remain at that side until you move it the other way.
  The middle of the widget is the "cancel" area: the value will remain/become
  the original value when the pointer is here.

  Selecting values from this widget is very fast. Click, drag down, release
  to select a value of 50%. Click, drag up/right, then left, release to
  select a value of 0%.
	
  Issues:
  - Although the widget would work much like a marking menu, the
    dial has the difference that it requires the movement to be
    large enough to make it around the pin.
  - Only the right mouse button is used, so it is of not much use to pen
    tablet users where marking/pie menus are the most efficient.

  Ideas:
  - Delay, so that the user can "mouse ahead". Use timeouts and threholds
    to catch the end of the gesture. Adjust the diameter of the circle to the
    size of the gesture, and let the user mouse-ahead 0% and 100%.

 * Non-engine KDE version. Still has a lot of quirks. I'd better write a KDE engine
   (a "style" in KDE-speak) that would be able to read gtkrc files... =)
   Funny is that while KDE has more features by default, it is less expressive and it is
   not possible to tweak Qt as much as GTK. (not counting patches)

To do:
 * Check out which themes at gtk.themes.org are the most popular and write
   Xeno-versions of these.

Maybe, maybe never:
 * Rewrite the polygon routine, hardcoded fake antialiasing.
 * Antialiased text ... if freetype is present. Compile-time option perhaps.
   Not necessary. Keith Packard's "xrender" extension will probably be supported
   soon in GDK anyway. Will try it out when XFree 4.0.4 is released.
 * Start using Autoconf.

Maybe also a few new patches. (sorted by complexity):
 * Add smooth jump scrolling to GtkScrollbar, GtkAdjustment, GtkViewport
   or GtkScrolledWindow... well, somewhere at least.
   - Hard to find the point to put the patch.
   - Hard to get it to feel right:
     - Handle rapid successive key presses... harded than it sounds.
     - A jump should not take more than 50 ms.
     - Do not stall when keyboard repeat is used to scroll.
       Time threshold could coincide with key repeat rate.
     - Linear scroll feels better than sine wave somehow - the opposite of
       my expectation. Sine would be better for large scrolls because you can
       *jump* in the middle when the scroll would have exceeded the time limit.

 * Implement Macintosh delay behaviour with submenus.
   I don't care if it may be patented. "Look and feel"-patents suck
   and should not apply. A lot of people try to emulate Mac's behaviour
   in soo many ways using delays but they all fail and introduce delays
   at the wrong places which only annoy the user.
   Hmm.. Maybe I will rewrite the menu code instead, like I did with GtkTable,
   because patching it seemed to be a hell.
   Oh.. did I ever mail that code to the gtk-devel mailing list?
   Naah.. I should concentrate on Morpheus/Gooey instead. :-)

   Update: This is no longer necessary. GTK 1.3.2 has this
   behaviour by default.

 * GtkOptionMenu into having cycling behaviour when the tab is clicked
   or when the whole widget is middle-clicked. Click behaviour is there
   as it inherits GtkButton. It is just not enabled.
   The widget should also open the menu on the right mousebutton.

 * Pressing down multiple mouse buttons in a menu should not close
   the menu but let the user multiselect.
   The signals should be sent when the menu closes.
   You can do this with the keyboard, but not with the mouse.