What is required is a method of doing this. There have been suggestions as to how to do it http://trac.wxwidgets.org/ticket/10466 http://www.kirix.com/forums/viewtopic.p ... =542#p1479 but these have been vetoed by Ben. So I think it is possibly time we rose to the challenge and implemented this as Ben sees it so we can use this facility in our programs. What follows is my posting on wx-users and wx-dev, and would welcome any input here or there.
There has been some discussion recently as to a patch placed both on the Kirix "Return to wxAUI Questions, Thoughts & Feedback" forum (http://www.kirix.com/forums/viewtopic.php?f=15&t=542) as well as on the Trac http://trac.wxwidgets.org/ticket/10466
Ben is definitely against this patch, preferring an as yet unwritten method.
From the Kirix forum
After further discussion on the Trac it looks like I might have understood his desires.1) wxAuiPaneInfo already has parameters specifying position: Direction, Layer, Row, etc. You would first need to add another one called Page. "page" by default would be zero for all pages added. If two tabs are docked in the same Direction/Layer/Row/Position, and their page variables are different, then tabs are automatically formed. For example, if you have two pane's, each in the exact same position, one with page 0 and one with page 1, tabs will form.
2) The work of forming tab controls would happen in the Update process. Pretty much all of wxAuiManager's work takes place there. The idea is that you have an array of panes, can change it as much as you want, and then commit the work by calling wxAuiMAnager::Update. This makes serializing/saving the pane array effortless.
3) I have already coded several classes which may be of use. wxAuiTabContainer is a window-less tab container control. There is also wxAuiTabArt which can draw tabs. The implementation might be able to make use of these. If it turns out to be too complicated to use them, I wouldn't force it though.
4) Basically, to sum it up, the main requirement is that tabs are not extra controls added to the frame window. They must be windowless controls, drawing directly on the owned frame, just like the rest of wxAUI. This allows effortless serialization.
His reply wasSo if I understand Ben correctly, what he desires is that each wxAuiNotebookPage will actually just be a wxAuiInfoPane with a different dock_page value? And that a wxAuiNotebook could just be a wxControl/wxPanel(?) with a wxAuiManager and a page count?
wxAuiNotebook::AddPage would then create a new wxAuiPaneInfo having standard values for everything but incrementing the page count?
SavePerspective should work the same as the current implementation (with addition of pagecount information)?
Since wxAuiNotebookPages are then just wxAuiPaneInfo related panes, that it should be possible to drag a page from a notebook (make it a floating pane) and drop it onto another pane whereby it could/should form a new wxAuiNotebook type of implementation? Irrespective of which manager controls the original "fixed" pane? Would that then mean that we could create floating notebooks? What should happen when a floating pane is dropped onto a second floating pane?
That effectively the frame has a sort of "master" manager, which should "control" the notebook managers so that streaming the perspective in and out should be a simple matter?
That it should be possible to drop a floating pane onto a wxAuiNotebook and that that floating pane should become just another wxAuiNotebookPage?
Have I missed anything?
Has any work been done in this direction wrt Ben's ideas/desires?
How about the contents of a wxAuiNotebookPage? Or would this be left up to the user of the library to implement? That ideally the perspective just saves the wxAuiNotebookPages/bitmaps/labels etc.?
I think that this more or less brings everyone up to speed on Ben's desires.Correct. Just as we have Direction, Layer, and Row on wxAuiPaneInfo, we'd add Page. Page would be zero (or -1, depending on how the implementation works) for all pane's that don't have a tab control. Multiple pages could be docked in the same Direction/Layer/Row and increment the page index to determine where they are in the internal tab control.
Significant work towards this end has already been made in auibook.h, but integration and final implementation is still pending.
The advantages to this design are many: Tabs wouldn't require addition window controls, and could be managed by the same sizer mechanism as other panes. Additionally, the same serialization mechanism could be used. Most importantly, tabs could be dragged and moved to other panes supporting tabs or detached into a floating pane altogether.
I know that my coding skills are not up to the task, although I am more than happy to attempt it, but wondered if there are any other developers who might want to get involved?
Ben has already provided several classes with his vision in mind, all it seem to need is someone with the right skill level to implement it. Any takers?
I thought it would be possible to implement an interim solution where adding page count information to the wxAuiPaneInfo and altering the SavePerspective and LoadPerspective functions of wxAuiManager might
suffice for simple serialization (basically each wxAuiNotebook would be responsible for its own Save/LoadPerspective) , but if I understand Ben correctly, then it should be possible for a single wxAuiManager to handle ALL aspects of the possible perspective - I quite probably have this wrong though.