Central widget#243
Conversation
Adde option to set a dock widget as central widget. It influences resizing behavior of the splitters. The central widget will be stretched with the main window and remaing dock widgets and threir respective areas will be resized only vertically if docked left or right and horizontaly if docked top or bottom
githubuser0xFFFF
left a comment
githubuser0xFFFF
left a comment
There was a problem hiding this comment.
Please check the review comments - Thank you
| auto TargetAreaSizes = TargetAreaSplitter->sizes(); | ||
| QSplitter* NewSplitter = newSplitter(InsertParam.orientation()); | ||
| NewSplitter->addWidget(TargetDockArea); | ||
| // updateSplitterHandles(NewSplitter); |
There was a problem hiding this comment.
Is this intentionally uncommented?
There was a problem hiding this comment.
The update happens two line later, so this one can be removed.
| { | ||
| if(d->CentralWidget) | ||
| { | ||
| addDockWidget(RightDockWidgetArea, d->CentralWidget); |
There was a problem hiding this comment.
Could you please explain, what you do here. If there is already a CentralWidget then you move it into the RightDockWidgetArea and make the new widget the central one - is this right?
There was a problem hiding this comment.
Yes. I guess I can add a parameter containing possible DockWidgetArea for existing Central widget with default being RightDockWidgetArea.
There was a problem hiding this comment.
I do not really like this implicit moving of the previous widget into another dock area. Especially if you implement the change below, where you clear the floatable, movable and closable flags. Then you move a non floatable, non closable and non movable dock widget into another area.
I would propose, that an old central widget is removed and returned to the caller if a new widget is assigned. So the function would look like this:
CDockAreaWidget* CDockManager::setCentralWidget(CDockWidget* widget, CDockWidget** oldWidget = nullptr)So the oldWidget parameter is for returning the old central widget. Normally the user should never assign a central widget if there is already one assigned. But if the old one is returned, the caller at least has a chance to set the dock widget flags properly.
What do you think about this?
| } | ||
|
|
||
| d->CentralWidget = widget; | ||
| return addDockWidget(CenterDockWidgetArea, widget); |
There was a problem hiding this comment.
A central widget should be not closable, not flotable and not movable and the dock area title bar should be hidden. In your example you set all these properties outside before you call this function.
What do you think about settings these properties here inside. That means, if someone sets a central widget, this function clears the movable, floatable and closable features and hides the title bar of the created dock area?
There was a problem hiding this comment.
Absolutely. I am adding this there now.
|
|
||
| #include <QLCDNumber> | ||
|
|
||
| class CDigitalClock : public QLCDNumber |
There was a problem hiding this comment.
Please remove all fixed height widgets from the example (the top one and the bottom status bar) and remove the digitalclock source files.
|
I just merged your pull request with some changes and fixes. Thank you. |
|
There seems to be a problem with your central widget implementation. It seems like the central widget will not be saved and restored properly when saving and restoring state (see the issues for more details) I will remove the central widget concept within the next days from the library and hope, that you can provide a fixed implementation. |
2 participants
Added option to set a dock widget as central widget. It influences resizing behavior of the splitter. The central widget will be stretched with the main window and remaining dock widgets and their respective areas will be resized only vertically if docked left or right and horizontally if docked top or bottom.