This is a copy of libufo cvs with a couple of patches applied.

libufo CVS checkout date: 2005/07/14

Patches applied currently:
- Patch to uwidget.hpp and uwidget.cpp to take a ufo::UCollectable* as widget
  deleter. This object is deleted at the very first in the d'tor.
- Patch to include/ufo/ufo_gl.hpp and usysteminfo.hpp to include bogl.h instead
  of gl.h and glu.h
- Patch to ufo/include/ufo/usysteminfo.hpp and ufo/include/ufo/ux/uxglxdriver.hpp
  to include boglx.h instead of glx.h
  note that this must be included before X11/Xlib.h
- Patch to uboxlayout.cpp:
  * widgets use remaining space
  * support for "stretch" property
  -> in general: use our own code, instead of the libufo code
- Patch to urootpane.cpp and udesktoppane.cpp to fix URootPane::setMenuBar()
  when there is already a menubar set. I.e. fix menubar removal.
  For this UDesktopPane::removeDockWidget() got implemented.
  (patch is also in official libufo cvs (05/07/19))
- Patch to ulayeredpane.cpp to insert new widgets at the beginning of a layer
  (which makes it the last widget that is painted), if not specified otherwise
- Patch to ugl_driver.cpp to use bogl functions instead of loading the OpenGL
  library once again
- Patch to ustylehints.cpp to avoid uninitialized values (especially bordertype)
  (patch is also in official libufo cvs (05/07/19))
- Patch to ubasicstyle.cpp to use icon_size.h instead of .w, when calculating
  the height in getCompountPreferredSize()
  (patch is also in official libufo cvs (05/07/19))
- Patch to uabstractcontext.hpp, uabstractcontext.cpp, uwidget.cpp and ubasicmenuitemui.cpp
  to improve events for our needs:
  Instead of delivering a mouse event to root->getVisibleWidgetAt(), we
  implement a getVisibleWidgetsDFS() function, that starts at the root and finds
  all currently visible widgets (at the relevant point) using a depth first search
  and returns them in a stack.
  We then dispatch it to every widget on the stack until one widget consumes
  the event (in that case we stop then).
  This especially fixes layered panes: previously an event was delivered to the
  topmost layer only and to the layered pane itself, if the widget was not
  interested in that event. Now the event is first delivered to the topmost
  layer, then to the layers below it, then to the layered pane.
  ubasicmenuitemui.cpp had to be patched, because mousePressed() needs to
  consume events for items as well, not only for menus.
  UPDATE: AB: after the update to libufo CVS of 05/07/14, the menuitems were NOT
              patched again. we may need to do though, so. the code is now in
              umenuitem.cpp (ubasicmenuitemui.cpp doesnt exist anymore)
- Patch to uwidget.cpp to return (0,0) instead of maxSize when maxSize is 0 in
  one direction in getPreferredSize().
- Patch to uinternalframe.cpp to initialize m_frameState
- Porting menu patch from official libufo cvs (05/07/19)
- Fix invalid memory access in utextwidget.cpp
- Fix a crash in utextlayout.cpp due to a uint underflow for the line length
- Fix to umenumanager.cpp to consume() mouse press events for menu items (before
  it consumed press events for menus only). This makes sure that a press event
  is not propagated to the parents (and siblings in a layered pane).
- Patch to umenumanager.cpp: Fixing highligt state of activated menu item.
  backported from libufo cvs, 05/08/15, revision 1.14
- Porting menu patch (ufocusmanager.cpp, revision 1.8) from official libufo cvs (05/08/15)
- Backporting fix for memory leak in uwdget.cpp: delete m_styleHints, if the
  object is detached.
- Backporting fix for a huge memory leak in uvertexarray.*: the getArray() array
  was never deleted
- Patch to ucombobox.cpp to remove the trackPointer(m_textEdit) call, as
  add(getTextEdit()) already calls this. This fixed a memory leak.



Use
 make_ufo_dir.sh ufo_dir code/ufo
from the tools module (boson cvs) to update this directory (all changes will be lost!).

This copy of libufo is required because of several reasons:
- libufo can not (because of it's current development state) preserve binary
  compatibility and not even source compatibility among releases. Therefore
  boson must compile _exactly_ against a certain version of libufo (a more recent
  version may not work anymore)
  -> this is a lot of work for users (and developers)
- Some patches against latest libufo are required for boson. Without them boson
  cannot make actual use of libufo. It is a hell of work to developers (and
  eventually users) to track all required patches (or install modified libufo
  versions).
  E.g. as of today version 0.7.3 is the most current official libufo version,
  but that does not support multiline labels (not even cvs does as of today).
  Multiline labels are an absolutely required feature.
- Because of the lack of binary compatibility it only makes sense to link
  statically against libufo. However that requires yet another custom
  configure switch - it's a pain to the developers to make the users actually
  understand and do that, but it's even worse to the users who have to remember
  and follow 10 million different ways of compiling a hundred different libs,
  only to install boson.

