feat(ui): add a new way to arrange buttons in toolbars
Description
In SightViewer, the number of buttons tends to increase in the left toolbar. With !936 (closed), two new buttons will be added, and there won't be enough place anymore to fit them in the left toolbar in the default window size (1150*700).
The idea is that not all buttons need to be displayed all the time, we only need a subset at each given time. The user may click on a button to display more buttons if needed. For example: The buttons to manage the Shape extruder ("Undo last freehand cropping region" and "Revert last freehand cropping point") should only be displayed if the Shape extruder is enabled (by clicking on "Draw a new freehand cropping region"). The buttons to manage Distances and Landmarks should only be displayed when the respective button is clicked.
Proposal
Optional section to give some functional or technical hints
Functional specifications
There are a few way to do it:
!939 (merged)
Using the Speed Dial buttons which will be added byThe main problem with that approach is that the buttons will be drawn on top of the scene, which might be annoying for the user. A solution would be to fold the buttons as soon as the user clicked on one, but there might be case where it is impractical. For example, if you want to revert multiple extrusions, you would have to click twice for each extrusions you would remove (one to make the revert button appear, and one to click on that revert button).
Displaying a side toolbar for the other buttons
This approach partly solves the problem of the previous approach by adding a parallel toolbar, aside the main toolbar, rather than a "perpendicular" one as the speed dial would be. The side toolbar might still impede on the scene, but it should be less problematic.
Creating an accordion menu
This approach avoids drawing anything on top of the scene, as the buttons are still drawn inside the main toolbar, next to the button that makes them appear, pushing away the other buttons. However, if the user requires to have multiple of these accordion menu to be displayed, there might still be a lot of buttons to be displayed, that might not fit the toolbar. Moreover, whatever approach we choose, we'll have to create two new buttons (one to make appear Distances-related buttons, and another one to make appear Landmarks-related buttons).
Conclusion
After talking about it orally, we decided that the accordion menu would be the best solution. To configure buttons to be in an accordion menu, the <accordion>
subtag must be added in gui.layout tag directly in sight::module::ui::base::SToolBar configuration, for example:
<menuItem name="1" />
<accordion>
<menuItem name="2" />
<menuItem name="2.1" />
<menuItem name="2.2" />
<menuItem name="2.3" />
</accordion>
<menuItem name="3" />
In this example, the buttons 1, 2 and 3 are always displayed, and the buttons 2.1, 2.2 and 2.3 appears when the button 2 is clicked.
Technical specifications
The way the SToolBar configuration is parsed must be slightly modified to take the accordion
case into account. A new field "m_accordion" is added into ActionInfo, which is an enum with the values NO, FIRST and YES. A button which isn't in an accordion has the value NO, the first one, which is always displayed to make the other appears has the value FIRST and the buttons that are in an accordion have the value YES.
The accordion is implemented as a new class derived from QWidget which will handle the layout of the buttons, similar to SpeedDial. We can't use QToolbar as it doesn't support animations. The fact that we can't use QToolbar means that accordion menus can't support separators (or that we must emulate it).
Test plan
GUI tests.