Add automatic-notebooks to wxAUI.

[huge_]

This mod adds "automatic notebooks" to wxAUI. This allows panes to be dragged over the top of other eligible panes for form notebooks, and then you can drag the tabs out to for normal panes again.

To dock on another pane, firstly both panes must have the "optionNotebookDockable" flag (now on by default) and not be "Fixed" size. Then you drag over the centre 1/3 of the pane to cause a notebook-drop. You can globally disable this mod using wxAUI_MGR_NO_AUTO_NOTEBOOK flag on the manager.

This mod replaces 1626617 (wxAUI wxFrames), as the changes are too intertwined.

You can programatically create a notebook by first creating a notebook id at a certain position, and then adding pages to it:

int notebook = mManager->AddNotebook(wxAuiPaneInfo().Left().BestSize(250,500));

mManager->AddPane( pane1, wxAuiPaneInfo().BestSize(200,400).NotebookPage(notebook) ); mManager->AddPane( pane2, wxAuiPaneInfo().BestSize(200,400).NotebookPage(notebook) );

If you remove all-but-one pane, the notebook will convert to a normal pane.

Known issues: The notebook gets the "BestSize" from the first pane - perhaps some other thing would be better? MinSize/MaxSize are currently ignored. The notebooks are simple arrays of tabs - you can't split them like you can the wxAuiNotebook - although you don't really need to. The tab-order is currently hard to change. The active tab is not remembered.

[biwillia76]

Thanks for the patch. We also intend to implement this functionality, but in a slightly different way that allows the tabbed layout to be saved in a perspective via Load/SavePerspective(). If you don't need to load and save perspectives, then this patch will most likely work quite nicely for you.

All the best,
Ben

[huge_]

Patch files for wxAUI code

[huge_]

I have updated the patch to fix a bug when closing panes, and to allow tab order to be remembered.
File Added: aui_patch3

[vadz]

I don't know what to do about this patch -- it was meant to be replaced by something else but this has never happened and in the meanwhile this patch doesn't apply at all to svn trunk any more so we can't really do anything about it.

The functionality added by this patch seems useful to me but I can't judge if it's implemented in the best way and I can't update the code to work with the trunk myself.

[huge_]

I have a more recent update, but not in patch form - was not sure if I was wasting my time.
There are some objections to the implementation - it has child windows, which are outside the design theory of wxAUI. However, it is an implementation and I think the API is pretty sound & in the spirit of wxAUI. So you could use the code and when a better implementation comes along, switch that in with the same API. If you want to put this in, I can create a new proper patch. Also, load/save perspective is addressed with the new code.

[vadz]

Ben, could you please tell us if it makes sense to ask Huge to submit a new and improved version of the patch or if you already have something similar (or better) in your code? In any case, I don't think we should apply the old patch, should we?

[biwillia76]

Hi Vadim and Huge,

Correct. This patch needs to be reworked so that it doesn't create wxAuiNotebook windows. The general policy of wxAUI so far has been to let the user create the windows, and don't create any windows itself, a la wxSizer et al. This of course with the obvious exception of floating panes.

That said, I've been most appreciative of this important exploratory work.

All the best,
Ben

[huge_]

Hi,
I do not intend to rework this without extra windows, since this would involve re-writing a tabbed panel, and changing the list of panes from a list of "wxWindows" to a list of "wxWindows or window-like-class", or alterantively using a completely different approach. As I have said, the API need not change if an eventual replacement comes along, and if the developer does not wish to use extra windows, they do not need to allow tabbed panels. But perhaps they should be given a choice between these evils? I see it has been over a year without any action on the front, so I guess we stick a fork in this one :(

[triton]

Can this work merged to trunk?

No better option has surfaced, and I know some people would really like this feature. As huge_ said, if someday, something better comes along, the API doesn't need to change.

huge_, do you have an updated patch for this?

[vadz]

What's (if any) the relationship of this one with #9419?

In any case, I won't apply the patch if Ben still thinks it's a bad idea to do so (and I understand his argument for saying this) so unfortunately I don't think anything is going to happen with it.

[vadz]

(In #14756) Thanks, one question after looking at the patch: could we avoid the need for dynamic cast to wxAuiNotebook by always generating wxEVT_AUI_ALLOW_DND and then generating wxEVT_COMMAND_AUINOTEBOOK_ALLOW_DND from its default handler in wxAuiNotebook? If we could do it like this, it'd be much cleaner IMHO. But maybe I'm missing something that prevents us from doing it like this?

[mmacleod]

(In #14756) Yes, I don't see anything stopping it from being done that way and I agree it would be cleaner.

[jens]

(In #14756) First:
sorry for the delay.
Here is a first patch that fixes issues with left/right tabs.
Moving the tabs with the up-/down-arrows works, furthermore the up-arrow is visible again.

I implemented a short loop, that ensures we can see as much tabs as fit on the screen, or in other words: while there is enough free space on the right or bottom of the tab-control for a tab (and not all tabs are shown) the taboffset is decreased.
This option can possibly be made configurable with a flag.

I also change dthe default tab-height from 30 to 42, but that's just another hack until we can use calculated values again.

[vadz]

(In #14756) Thanks for the patches but I'm concerned about the use of wxDC::GetSize() as AFAIR it's not implemented in wxOSX. Why do we have to use it, don't we have the size in the window itself somewhere?

Also, the situation with variable names is completely catastrophic :-( We can't keep renaming them like this, with one patch doing 's/foo_bar/fooBar/g' and the next one doing 's/fooBar/foo_bar/g'. Ideal would be to keep the original names until the dust settles and then do one single renaming at the end. But this is going to be difficult as the changes of the original patch contained a lot of name changes.

BTW, speaking of this, I am really not sure we want to deprecate the old non m_-prefixed names of wxAuiPaneInfo fields. There is no real harm in not using m_ here and this results in hundreds of deprecation warnings, so I'll probably undo this before merging into the trunk.

[jens]

(In #14756) About wxDC::GetSize(), yes it's needed at the moment, the window-size is unusable at the moment, but if it is really needed, I will find another solution.
As far as I know I only use it in wxAuiGtkTabArt, is wxGTK usable on Mac ? and if it is, wouldn't it use the same wxDC than on linux ?

About the variable names, where did the change from fooBar to foo_bar ?
I tried to keep them as they are in the initial merge-patch.
But it might be, that I have overread some.

[vadz]

(In #14756) Replying to jens:

About wxDC::GetSize(), yes it's needed at the moment, the window-size is unusable at the moment

I don't really understand how can wxDC have the correct size if the window doesn't. Where does the DC size come from?

, but if it is really needed, I will find another solution.
As far as I know I only use it in wxAuiGtkTabArt, is wxGTK usable on Mac ?

Maybe/probably, but it's true that I overlooked the fact that it was only used in wxGTK-specific code so wxOSX considerations are irrelevant here. Still, I'm bothered by the fact that window size can't be used, it's probably another bug somewhere.

About the variable names, where did the change from fooBar to foo_bar ?

totWidth is being changed to tot_width in several places.

There are also not really necessarily changes of m_flags & XXX to HasFlag(XXX). It's not that I disagree that the latter is better but I'd really like to avoid making all these changes at the same time, it would be much better to leave them off until after the merge.

[jens]

(In #14756) Replying to vadz:

Replying to jens:

About wxDC::GetSize(), yes it's needed at the moment, the window-size is unusable at the moment

I don't really understand how can wxDC have the correct size if the window doesn't. Where does the DC size come from?

, but if it is really needed, I will find another solution.
As far as I know I only use it in wxAuiGtkTabArt, is wxGTK usable on Mac ?

Maybe/probably, but it's true that I overlooked the fact that it was only used in wxGTK-specific code so wxOSX considerations are irrelevant here. Still, I'm bothered by the fact that window size can't be used, it's probably another bug somewhere.

The DrawButton seems to get the frame containing the whole notebook (including the pane) as parameter.
The dc is a memory dc especially created for drawing and it has the correct size.
Before the merge the window was the wxAuiTabCtrl, which no longer exists.
The rect can not be used directly, because the width is decreased for each drawn button, so the close and window-list button can be drawn at the right side, but the up button needs to be drawn in the middle of the rect, but this can not be determined after the width has decreased.
But I'm sure there will be another solurtion.

About the variable names, where did the change from fooBar to foo_bar ?

totWidth is being changed to tot_width in several places.

Ooops, sorry. I will change it back, or you can do it.

There are also not really necessarily changes of m_flags & XXX to HasFlag(XXX). It's not that I disagree that the latter is better but I'd really like to avoid making all these changes at the same time, it would be much better to leave them off until after the merge.

I did this, to be more consistent with other parts of the merge.
But I agree, it makes it harder to review the patches.

[jens]

(In #14756) I fixed the sizing problems, or more exactly calculation of tabs (width and height) now works correctly.
Also the drawing of the buttons/arrows.

The tabart-class now has to care for the placement of the buttons and no longer the Render()-function, what was wrong in my opinion.
The tabart-class has to "decide" which buttons should be placed where.

Drawing of the right-tabs with gtk is also fixed.

Some minor issues are left with bottom tabs (at least with generic-tabart.
But this should not be a greatl problem.

Should I create a new patch based on the old ones (assuming the old patches have been applied) or should I create (a) new patch(es).

And what about the naming (camelCase vs. however_it_is_called) and using of HasFlag instead of m_flags&xxx ?
Shall I fix it also ?

I can upload (a) patch(es) this evening

[mmacleod]

(In #14756) > BTW, speaking of this, I am really not sure we want to deprecate the old non m_-prefixed names of wxAuiPaneInfo fields. There is no real harm in not using m_ here and this results in hundreds of deprecation warnings, so I'll probably undo this before merging into the trunk.

I agree here that there is no need to rush the deprecation, feel free to take the deprecation away for now.

[vadz]

(In #14756) Replying to jens:

I fixed the sizing problems, or more exactly calculation of tabs (width and height) now works correctly.
Also the drawing of the buttons/arrows.

Great, thanks!

Should I create a new patch based on the old ones (assuming the old patches have been applied) or should I create (a) new patch(es).

The currently applied patches are in the aui branch of git@…:vadz/wxWidgets.git

And what about the naming (camelCase vs. however_it_is_called) and using of HasFlag instead of m_flags&xxx ?
Shall I fix it also ?

I'd be really glad if all the patches could only include the important/critical changes right now and we postponed the rest of them until later. I'll actually probably try to revert some of the naming changes of the original patch just to be able to see more clearly what it does.

I can upload (a) patch(es) this evening

If you do, please let me know if they should be applied after aui_fix_external_tab_drop_crash2.patch or before it. Unfortunately I won't have time to apply this one today.

[jens]

(In #14756) I just attached two patches, that (hopefully) fix almost all drawing issues in auinotebook.
You can apply them before or after the drop-crash patch, both works for me.

The calculate-tab-size patch must be applied before the fix-drawing-issues patch.

What stiil needs to be done is reimplementing the fixes for #14710.

That's the next thing I will do.

There are other sizing issues left, when draging (or better after dropping) tabs in some cases.
And I still can produce crashes on drop (even with the crash-drop-patch).

I will try to give detailed steps to reproduce, or find the reason.
But the drawing stuff has a higher priority for me, because I'm more familiar with the drawing code.

[mmacleod]

(In #14756) Replying to jens:

I just attached two patches, that (hopefully) fix almost all drawing issues in auinotebook.
You can apply them before or after the drop-crash patch, both works for me.
The calculate-tab-size patch must be applied before the fix-drawing-issues patch.

Thanks, will try have a look over it this afternoon.

There are other sizing issues left, when draging (or better after dropping) tabs in some cases.

If you can let me know what cases I can have a look from this side as well.

And I still can produce crashes on drop (even with the crash-drop-patch).
I will try to give detailed steps to reproduce, or find the reason.

If you can give a stack race that should be enough, although any detailed steps are also appreciated.
Will have another look from this side as well.

But the drawing stuff has a higher priority for me, because I'm more familiar with the drawing code.

Yes, its probably more efficient if we each focus on the code we are more familiar with.

Thanks,
Malcolm

[jens]

(In #14756) I just saw that fixed-size of tabs is broken.

There is one typo, but also a real issue with the order of calculating dynamic and fixed width and height.

I try to find a solution and post a patch.
Other stuff should not be affected.

Jens

[jens]

(In #14756) Replying to jens:

I just saw that fixed-size of tabs is broken.

I just attached a patch that should fix this.

Jens

[jens]

(In #14756) Hi Malcolm,

I just uploaded two backtraces after a drop-crash.
Your patch and my new patches are installed.

The  first one appeared after a drop near the bottom of the auidemo window.
It happened sveral times, but I did not find a way to reproduce it reliably.
The  scond one happened with close on all tabs active. I pressed the mouse over the close-button and dragged the tab, no hint-rectangle was visible before the crash.

Jens

[vadz]

(In #14756) I applied (admittedly, without any review as I'm simply too lost here) all the patches to facilitate testing but the aui sample still crashes all the time. E.g. just make the tree pane floating -- it dies in wxAuiFloatingFrame::OnMoveFinished()...

[mmacleod]

(In #14756) Okay thanks.
I've managed to reproduce the crash here and I should have some spare time tomorrow so will try get to the bottom of it and do a bit more stress testing.

Regarding the left/right changes I have a concern, for left/right notebooks "fixed width" seems to have been "re-purposed" to mean "fixed height".
I don't think this is a good idea, as it could be confusing for users. Left/Right notebooks are currently allocating as much space as necessary to fit the "page title" for very long page titles this can look somewhat unwieldy and as such it is not hard to imagine that a program author in this situation might want a "fixed width" for right/left tabs, getting instead a fixed height would be annoying.
Should we not consider just separating the two and having a "fixed height" as well, one could have both "fixed width" and "fixed height" for left/right notebooks, while for top/bottom notebooks "fixed height" could be ignored. (Unless of course some meaningful behavior could be done here as well)

[jens]

(In #14756) At the moment "fixed height" for left/right is the same as "fixed width" for top/bottom: distribute the available space equally on all tabs, using a hard-coded min value.
Maybe wee need (or better should introduce) a min (and probably) a max-size for all alignments and also a real fixed width (or better size), which is not dynamical as it is now for top/bottom tabs.
SetMinSize(), SetMaxSize() and probaly a SetSize() could be used.
What we have now is more or less the same as sizeritems with wxEXPAND set, with a hardcoded min- and max-size and same proportion for all of them.

[mmacleod]

(In #14756) Above patch should fix those two crashes.
The one fix is not 100% right as it fixes th symptom but not the underlying cause, I will need to look into it in a bit more detail to fix the underlying cause as well, will try do that this afternoon.
In the meantime would be good to know if this at least fixes the crashes for you or if they continue.

Thanks,
Malcolm

[mmacleod]

(In #14756) Okay, updated version of the patch attached.

This properly fixes the cause of the above crashes as well as one or two other "strange" behaviors that were related. There seems to be one more crash lurking but it takes quite a while to reproduce and I've not yet managed to catch it in a debugger, will carry on looking into it but that should probably be applied separately (after this patch)

[jens]

(In #14756) I attached three patches:

the first one reimplements the changes made for #14710,

the second fixes minor drawing issues in generic tabart,

the third fixes build issues I mentioned in windows 7:
auibook.h needs containr.h for wxNavigationEnabled and framemanager.cpp needs dcmemory.h for wxMemoryDC.

[jens]

(In #14756) The newest patch implements a better calculation of tab- and gapbox-size.

[RedTide]

(In #14756) I tested the auidemo under GTK2 and GTK3 applying also all the patches starting from aui_fix_tab_drops.patch,
let me know if this is correct (where is the new auidemo?).

I got some debug warnings under GTK2 and a crash on GTK3.

Both warnings and crash seems to happen in some circumstances when dragging some wxAuiToolBar control, where in GTK2 in particular, the vertical toolbar sometimes, trying to dock it when floated, disappears.
Other than that, when switching to the 'all panes' perspective, some toolbars shrinks to the left (same issue I have in my AUI XRC patch), so troubles (crash and warnings) starts when trying to move them (they seems to resize back to the original size once dragged).

The only weird thing I noticed (without considering the wxAuiToolBar issues) is the 'global' close button on the right, when no notebook tab have one, that disappears when changing perspective and go back again to the startup one, resulting with the original 'close button in all tabs' behaviour.

About the warnings I'm not sure if they are related to my GTK2 theme I'm using in my Ubuntu 12.10 + LXDE system, I have to test again applying changes in my local trunk.

[RedTide]

(In #14756) > The only weird thing I noticed (without considering the wxAuiToolBar issues) is the 'global' close button on the right, when no notebook tab have one, that disappears when changing perspective and go back again to the startup one, resulting with the original 'close button in all tabs' behaviour.

Oops, this happens when changing notebook theme and default behaviour is 'close button in active tab'.

[jens]

(In #14756) Replying to RedTide:

The only weird thing I noticed (without considering the wxAuiToolBar issues) is the 'global' close button on the right, when no notebook tab have one, that disappears when changing perspective and go back again to the startup one, resulting with the original 'close button in all tabs' behaviour.

Oops, this happens when changing notebook theme and default behaviour is 'close button in active tab'.

I think this is related to the changes of the constants for the auibook-flags in the dynamic aui branch.
Should be easily fixable.

In fact I saw it also, but it has low priority at the moment.

Gtk3 is more interestant, but drawing (and calculating of sizes) has changed a lot, so I still have no patch to attach here.
It compile sfine with gtk3 and drawing works also, but tabsize calculating still needs some more work.

[RedTide]

(In #14756) Replying to jens:

Replying to RedTide:

Gtk3 is more interestant, but drawing (and calculating of sizes) has changed a lot, so I still have no patch to attach here.
It compile sfine with gtk3 and drawing works also, but tabsize calculating still needs some more work.

I think that this should be done later, if possible, in wxRenderer with a 'new' (wxUniv have it already) DrawTab().

[RedTide]

(In #14756) I tested also on MSW and I got a segmentation fault adding a new notebook and then dragging a notebook page to the new one.
I'm using XP SP3 under VirtualBox + MinGW (official, not TDM) + MSYS (GCC 4.7.2).
It seems that gdb won't redirect output to a file like it does in linux, and interpret them as auidemo command line parameters, so, if needed, I can provide a jpg of the backtrace...

[vadz]

(In #14756) Thanks for the testing. I still didn't have time to do much debugging of it myself but your results show that we still can't merge this in, getting crashes is really not acceptable.

So the question is whether we should delay 2.9.5 until somebody has time to fully iron out all the fatal bugs in this code or just go ahead with 2.9.5 and postpone this for 3.2.

Neither alternative is very appealing unfortunately :-(

[RedTide]

(In #14756) Replying to vadz:

So the question is whether we should delay 2.9.5 until somebody has time to fully iron out all the fatal bugs in this code or just go ahead with 2.9.5 and postpone this for 3.2.

Neither alternative is very appealing unfortunately :-(

I don't see why a release of a development version shouldn't wait a bit, but this depends to how many hands/heads will work on this issue.
I'm for waiting this to be fixed and applied before 2.9.5, with some effort also from other devs also if not much interested on AUI.
If 2.9.5 will be last development version before 3.0 release, users will test it more deeply, but this is just my own opinion.

[jens]

(In #14756) If this branch will not make it into 2.9.5 I would like to (back-)port the left-/right alignment stuff to trunk (in fact it was done already and should work without much effort).

It's a nice feature to have the tabs at the left or right side in times of wide-scale monitors.

There is already a ticket open (currently blocked by this one).
Last comment there was http://trac.wxwidgets.org/ticket/13787#comment:20 .

In any case we should decide what to do with the fixed-width/fixed-height(?) flag.

Currently it's more a give all tabs an equal width flag, which indeed not makes much sense at all and more or less no sense for left-/aright-alignment. Her we should have something like max width or make fixed-width a real fixed-width no matter what the content is.

[RedTide]

(In #14756) Replying to jens:

If this branch will not make it into 2.9.5 I would like to (back-)port the left-/right alignment stuff to trunk (in fact it was done already and should work without much effort).

Is your GTK3 work to be going in wxRenderer?

I would like to see drawing stuff applied to it to having a native drawing apart, this could make code modular
and some parts also of this patch could be extracted and applied already and other non AUI users could benefit from it, but maybe I wrong/miss something.
Anyway I did some initial code to patch against wxRenderer also for tabs other than toolbars if it could be useful.

Vadim, could be possible to apply all the patches above and sync your clone with current trunk to be able to work on this issue meanwhile?

[vadz]

(In #14756) Replying to RedTide:

Vadim, could be possible to apply all the patches above and sync your clone with current trunk to be able to work on this issue meanwhile?

I'm actually lost as to which patches should be applied (and in which order). I had started hacking on my own version about 3 weeks ago, trying to get rid of insignificant changes (and thus understand the significant ones better) but never finished it so right now my tree is a mess...

Anyhow, does anybody have a branch with all the patches applied to it on Github by chance? I think it would be more productive to work on this there instead of attaching patches to this ticket.

TIA!

[RedTide]

(In #14756) Replying to vadz:

Replying to RedTide:

Vadim, could be possible to apply all the patches above and sync your clone with current trunk to be able to work on this issue meanwhile?

I'm actually lost as to which patches should be applied (and in which order). I had started hacking on my own version about 3 weeks ago, trying to get rid of insignificant changes (and thus understand the significant ones better) but never finished it so right now my tree is a mess...

Anyhow, does anybody have a branch with all the patches applied to it on Github by chance? I think it would be more productive to work on this there instead of attaching patches to this ticket.

TIA!

The order, AFAIU, is starting from aui_fix_tab_drops.patch, that seems replacing the previous one (I had to add a --ignore-whitespaces to apply) and below.

I have it at home with all the patch applied, so I could, if Malcom and Jens agree, upload it in my Github account and take care to sync it with the main upstream adding you all with write permission after uploading (merge the current trunk to it after upload as first commit, using it as origin where you will work on and adding the read only wx trunk as upstream to be able to keep this branch in sync with it).
I can do it only starting from the next week so meanwhile let me know if this could be a useful/correct solution.

[vadz]

(In #14756) It would be definitely useful, thanks.

But I'm still tempted to release 2.9.5 now because I didn't manage to work on this this weekend (got ill and spent what little time I managed on fixing a couple of new bad regressions instead) and so we're basically not going to release 2.9.5 at all this year if we delay it further.

We could do a 2.9.6 early in the next year if this stabilizes enough for then though.

[RedTide]

(In #14756) I've pushed the changes to  https://github.com/redtide/wxWidgets/tree/aui-dynamic-notebook
against the current trunk code:
after some talking with Brian, I realized that should be better that anyone have to keep his own wxWidgets forked repo and pull only from other ones instead sharing the same, so I hope that my simple file replacement with the files with all patches applied is fine too.
Let me know about any problem/issue, meanwhile I'll test it.

[vadz]

(In #14756) We need to integrate r73263 (see #10848) into this branch,

[RedTide]

(In #14756) Replying to vadz:

We need to integrate r73263 (see #10848) into this branch,

I suppose also r73288 / #14927
I think I'll wait for Malcom before do this my self on my cloned repo.

[RedTide]

(In #14756) Replying to RedTide:

Replying to vadz:

We need to integrate r73263 (see #10848) into this branch,

I suppose also r73288 / #14927
I think I'll wait for Malcom before do this my self on my cloned repo.

I'm not familiar with this code, but it is so different that I suppose that both issues was already managed, so I merged the code with a recent trunk version leaving auibook.cpp code unmodified.

[vadz]

(In #14756) Sorry, this clearly won't happen for 3.0 :-(