Bug report #15177
Updated by Denis Rouzaud almost 7 years ago
Some floating widgets used with map tools have the ability to be docked (e.g. for rotate feature tool, offset curve tool, add circular string by radius) - see QgsUserInputDockWidget.
There are however multiple issues related to the current approach:
* when the widget is floating (default), it is not possible to detect that "X" (close) button was pressed (to cancel pending operation)
* when docked, the widget moves other dock widgets and it may also resize canvas, causing unpleasant flicker
* widgets need special handling for focus, e.g. widget for rotate tool (QgsAngleMagnetWidget) has custom event filter to handle end of editing. Widget for offset curve does not have custom event filter and has issues (1. closing of widget behaves as if enter was pressed, 2. docking it makes it disappear immediately)
In my opinion a better solution would be to have a common area embedded in map canvas area where map tools could ask for numeric user input whenever needed (just like we have message bar embedded in canvas). This should solve all problems:
* cancelling pending operation (the widget would have a close button)
* predictable position for user input (e.g. lower-left corner of map canvas), no need to move floating widget
* dock widgets "jumping" around if docked user input widget is shown/hidden
* no need for custom event filters or other hacks to sort out focus issues
There are however multiple issues related to the current approach:
* when the widget is floating (default), it is not possible to detect that "X" (close) button was pressed (to cancel pending operation)
* when docked, the widget moves other dock widgets and it may also resize canvas, causing unpleasant flicker
* widgets need special handling for focus, e.g. widget for rotate tool (QgsAngleMagnetWidget) has custom event filter to handle end of editing. Widget for offset curve does not have custom event filter and has issues (1. closing of widget behaves as if enter was pressed, 2. docking it makes it disappear immediately)
In my opinion a better solution would be to have a common area embedded in map canvas area where map tools could ask for numeric user input whenever needed (just like we have message bar embedded in canvas). This should solve all problems:
* cancelling pending operation (the widget would have a close button)
* predictable position for user input (e.g. lower-left corner of map canvas), no need to move floating widget
* dock widgets "jumping" around if docked user input widget is shown/hidden
* no need for custom event filters or other hacks to sort out focus issues