This article describes future directions for HID development, in line
with <a href="../hid_policy"> with our HID policy </a>. It's constantly
updated as the docking effort progresses.
<p>
The difference between a DAD dialog  and any larger block of widgets in
the top window (e.g. layer selector or  the coordinate readout) is just
the parent widget pointer. Which means the API and the central, HID-agnostic
GUI code wouldn't be different if the widgets would be realized not in a
separate non-modal dialog but as part of the top window.
<p>
Which means any such non-modal DAD dialog code could potentially be
re-hosted in the top window, without the code knowing about this. That
lets us implement our own, custom "docking" mechanism  that will be the
same with all HIDs. Properties of that docking system will be:

<ul>
<li> any larger portion of the top window is really a DAD subdialog; for
example the layer selector, the route style selector, the toolbar,
the bottom status line and the coordinate readout are DAD subdialogs.

<li> instead of hardwiring these in the top window, we have "docking
areas" where any DAD dialog can be docked; the current top window layout
will only be the default configured layout

<li> (this also means the layer selector or other such, currently always-docked
sub-window will be able to get 'un-docked' into their non-modal dialog box)

<li> in the far future
any non-modal DAD dialog can be either docked in the top window or
floating; whenever the user switches between the two states, the DAD
dialog is destroyed and recreated with a different parent

<li> this way majority of the lib_gtk/bu_* code got moved to common
lib_hid_pcbui plugin, and doesn't need to be reimplemented in lesstif
and later in SDL

<li> the main menu bar, the drawing area, the new resize widget and the generic
layout/handling of the docking areas will remain HID-specific, local
implementations

<li> the window position/size config system has been generalized and
automatically applied to any DAD window on any HID; the HIDs just
provide glue code for this, but the window placement code is common

<li> as a side effect this also moves a lot of PCB-specific code out from
the HIDs, to a plugin that will not be part of the
<a href="../hidlib">hidlib</a>. This helps hidlib to happen sooner.
</ul>

<p>
Generally this will help:
<ul>
<li> further reducing gtk-specific code
<li> reducing  HID differences 
<li> which in turn will make documenting the HIDs easier
<li> reducing the cost of writing new HIDs
<li> reducing code duplications among HIDs.
<li> the progress with the hildib
</ul>

<p>
Note: the lesstif HID is lagging behind with the docking effort.