pcb-rnd knowledge pool
DAD, top window in various HIDs and docking
hid_topwin by Tibor 'Igor2' Palinkas on 2018-10-12 | Tags: roadmap, hid, top, window, topwin, docking, dad, dialog |
Abstract: Long term all HIDs will have all dialogs as DADs coming from the HID-agnostic plugins. Some elements of the top window, like the layer selector should be done in a similar way to avoid code duplication and reduce HID development cost. This will result in a new, more generic DAD approach that also solves the docking problem.
This article describes future directions for HID development, in line with with our HID policy . It's constantly updated as the docking effort progresses.
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.
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:
- 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.
- 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
- (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)
- 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
- 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
- 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
- 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
- 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 hidlib . This helps hidlib to happen sooner.
Generally this will help:
- further reducing gtk-specific code
- reducing HID differences
- which in turn will make documenting the HIDs easier
- reducing the cost of writing new HIDs
- reducing code duplications among HIDs.
- the progress with the hildib
Note: the lesstif HID is lagging behind with the docking effort.