Opened 8 years ago

Last modified 16 months ago

#10466 reopened enhancement

Ability to Save and Load Perspectives in AuiNotebook

Reported by: gooey Owned by:
Priority: normal Milestone:
Component: wxAui Version: stable-latest
Keywords: Cc: biwillia76
Blocked By: #14756 Blocking:
Patch: no

Description

This patch adds the ability to save and load perspectives from a wxAuiNotebook. I did not write this code but it originated from the following thread at kirix:
http://www.kirix.com/forums/viewtopic.php?f=15&t=542#p1479

The reason I'm submitting this patch is that I have successfully used this code in a custom build of wxPython so I believe it is better than having no builtin support for this functionality. I have seen others ask for this functionality so I believe it will be a useful enhancement.

Attachments (1)

auinotebook_perspective.patch download (5.7 KB) - added by gooey 8 years ago.

Download all attachments as: .zip

Change History (58)

Changed 8 years ago by gooey

comment:1 Changed 8 years ago by vadz

  • Cc biwillia76 added
  • Status changed from new to confirmed

The patch looks useful to me, thanks! The only possible enhancement might be to add code showing these new functions to the aui sample.

Ben, do you have any comments about it?

comment:2 Changed 8 years ago by bpetty

Ben said this about this patch a long time ago, and didn't really explain any specifics about what he was talking about:

"The reason I hesitate with all of the proposed solutions is that the only way to do this right is a full implementation. That involves getting your hands dirty with wxAuiManager. This is why nobody has done it yet. Unfortunately we can't settle for band-aid solutions in this case."

Ben has pretty much dropped off of wxWidgets development a long time ago, and hasn't really been addressing any of the new wxAUI tickets... I've been getting geared up for picking up where he left off, and was going to apply this patch regardless myself since I really don't see anything wrong with it myself for the time being, and it's certainly better than nothing.

comment:3 follow-up: Changed 8 years ago by biwillia76

  • Resolution set to invalid
  • Status changed from confirmed to closed

This patch really didn't fit our vision for how we wanted notebook pages to serialize. I still maintain that it would be a big mistake to apply it, because the serialization format will just become a big backwards-compatibility headache in the future. So, please don't apply this one.

My wxWidgets development time comes in bursts. That's why you see 5-month periods of silence.

Best,
Ben

comment:4 in reply to: ↑ 3 Changed 8 years ago by gooey

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to biwillia76:

This patch really didn't fit our vision for how we wanted notebook pages to serialize. I still maintain that it would be a big mistake to apply it, because the serialization format will just become a big backwards-compatibility headache in the future. So, please don't apply this one.

My wxWidgets development time comes in bursts. That's why you see 5-month periods of silence.

Best,
Ben

It's unfortunate that this patch won't be applied to help further the use of AuiNotebook. I remember when I first looked at AuiNotebook it was disappointing to see that this feature was available in AuiManager but not in AuiNotebook. I went searching on the web to see if I could find a solution and I saw a bunch of other people looking for answer as well. I was happy to see a possible solution posted by a user and decided it was worth the effort for our end users for us to apply the patch and start compiling our own wxPython. I know that there are other developers using AuiNotebook who would find this patch useful, see here.

I believe that compatibility is something that can be addressed if and when a correct implementation of this feature is developed. It has been about 1.5 years since the original thread started so I'm not holding my breath for the correct implementation. I'm just trying to help as little as I can to make AuiNotebook a little better.

I'm reopening this ticket for your reconsideration.

comment:5 Changed 8 years ago by Infinity77

I honestly agree with Mark (gooey), as there are posts about saving AuiNotebook perspective on the wxPython mailing list almost on a monthly basis, and our answer is always the same: it can't currently be done. Unfortunately, it is not the correct one: it *can* be done, and this patch is a very simple but powerful enough solution, for the very many wxWidgets users who can not dig well in the source code and for almost all the wxPython users who can not re-compile wxPython from source modifying wxAuiNotebook with this patch.

As compatibility issues seem (to me) very far in the future, I would't be so concerned about them right now. The solution is here, why not use it?

Andrea.

comment:6 Changed 8 years ago by biwillia76

The patch introduces a bolt-on serialization mechanism that will lead to headaches in the future.

I would like the tab control to be implemented natively in wxAuiManager and be serialized there. This will yield a much more powerful and flexible resuly, namely the ability to tear tabs off of a notebook and float them or dock them as panes or tabs in other notebooks.

I don't deny the need for the control, but I'm not willing to settle for a lesser solution in the short term. Somebody (maybe me) will have to implement it in the proper manner.

Ben

comment:7 Changed 8 years ago by ninjanl

So 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.?

regards 

Mal

comment:8 Changed 8 years ago by biwillia76

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.

Should we move this thread to wx-dev?

Ben

comment:9 Changed 8 years ago by ninjanl

I think that would be best.

Perhaps you could outline your vision of interpretation within and ask for further discussion/input.

best regards

Mal

comment:10 Changed 5 years ago by mmacleod

  • Blocked By 14756 added

comment:11 Changed 5 years ago by vadz

  • Blocked By

(In #14756) Thanks, I've applied the latest patch now and visually it's indeed much better, it still seems somewhat sluggish but at least it looks correctly, thanks for fixing this!

However I can trivially make it crash, e.g. by just dropping any notebook page on the title bar of the lower messages window with the following back trace:

 	auidemo.exe!wxBaseArrayPtrVoid::GetCount()  Line 832 + 0x11 bytes	C++
 	auidemo.exe!wxAuiTabContainer::SetActivePage(wxWindow * wnd=0x00aa28a0)  Line 976 + 0xb bytes	C++
>	auidemo.exe!wxAuiManager::SetActivePane(wxWindow * activePane=0x00aa28a0)  Line 757	C++
 	auidemo.exe!wxAuiManager::OnLeftUp(wxMouseEvent & evt={...})  Line 5843	C++

It seems that ctrl in wxAuiManager::SetActivePane() is garbage/uninitialized. Do we need to check for FindTab() return value perhaps?

comment:12 Changed 5 years ago by mmacleod

  • Blocked By

(In #14756) Hmm, no.
Although it is probably a good idea to check that anyway, but it isn't the root cause. (It will just not work correctly instead of crashing - which is of course an improvement)

The problem is that its trying to set an active pane when the wxAuiTabContainer does not yet contain that pane.
The latest patch is meant to fix that and I could have sworn it did in my branch, but perhaps I missed something. (Or maybe the patch missed something)
I'll take a look in the morning and try provide a more permanent fix for this.

comment:13 Changed 5 years ago by mmacleod

  • Blocked By

(In #14756) It seems that the code was getting a bit confused about external drags between managers (from the notebook manager to the surrounding aui manager) - even though the drop was being disallowed it was still going ahead and causing a crash.

The above patch improves the way external drags are handled and should fix the crash, let me know if it doesn't.
(Note the drag won't actually succeed in this case because the parent manager does not handle the wxEVT_AUI_ALLOW_DND event, but if you create a new notebook via the menu you should be able to drag externally between the two notebooks (The old sample implements wxEVT_AUI_ALLOW_DND only for notebooks)

comment:14 Changed 5 years ago by mmacleod

  • Blocked By

comment:15 Changed 5 years ago by vadz

  • Blocked By

(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?

comment:16 Changed 5 years ago by mmacleod

  • Blocked By

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

comment:17 Changed 5 years ago by jens

  • Blocked By

(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.

comment:18 Changed 5 years ago by Hanmac

  • Blocked By

comment:19 Changed 5 years ago by vadz

  • Blocked By

(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.

comment:20 Changed 5 years ago by jens

  • Blocked By

(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.

comment:21 Changed 5 years ago by vadz

  • Blocked By

(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.

comment:22 Changed 5 years ago by jens

  • Blocked By

(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.

comment:23 Changed 5 years ago by jens

  • Blocked By

(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

comment:24 Changed 5 years ago by mmacleod

  • Blocked By

(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.

comment:25 Changed 5 years ago by vadz

  • Blocked By

(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.

comment:26 Changed 5 years ago by jens

  • Blocked By

(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.

comment:27 Changed 5 years ago by mmacleod

  • Blocked By

(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

comment:28 Changed 5 years ago by jens

  • Blocked By

(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

comment:29 Changed 5 years ago by jens

  • Blocked By

(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

comment:30 Changed 5 years ago by jens

  • Blocked By

(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

comment:31 Changed 5 years ago by vadz

  • Blocked By

(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()...

comment:32 Changed 5 years ago by mmacleod

  • Blocked By

(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)

comment:33 Changed 5 years ago by jens

  • Blocked By

(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.

comment:34 Changed 5 years ago by mmacleod

  • Blocked By

(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

comment:35 Changed 5 years ago by mmacleod

  • Blocked By

(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)

comment:36 Changed 5 years ago by jens

  • Blocked By

(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.

comment:37 Changed 5 years ago by jens

  • Blocked By

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

comment:38 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:39 Changed 5 years ago by RedTide

  • Blocked By

(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'.

comment:40 Changed 5 years ago by jens

  • Blocked By

(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.

comment:41 Changed 5 years ago by RedTide

  • Blocked By

(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().

comment:42 Changed 5 years ago by RedTide

  • Blocked By

(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...

comment:43 Changed 5 years ago by vadz

  • Blocked By

(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 :-(

comment:44 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:45 Changed 5 years ago by jens

  • Blocked By

(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.

comment:46 Changed 5 years ago by RedTide

  • Blocked By

(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?

comment:47 Changed 5 years ago by vadz

  • Blocked By

(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!

comment:48 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:49 Changed 5 years ago by vadz

  • Blocked By

(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.

comment:50 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:51 Changed 5 years ago by vadz

  • Blocked By

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

comment:52 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:53 Changed 5 years ago by RedTide

  • Blocked By

(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.

comment:54 Changed 5 years ago by vadz

  • Blocked By

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

comment:55 follow-up: Changed 16 months ago by ngpaton

Hi,
I assume there has been no progress with adding a mechanism to allow saving of notebook layout?
If there is nothing going to happen in the short term might I suggest moving the definition of the wxTabFrame class from auibook.cpp to auibook.h which would then allow developers to apply the original patch in a derived class. Then it is up to the developer as to whether they want to support a possibly non-optimal save format. Personally I've found it very useful.
Thanks
Nigel

comment:56 in reply to: ↑ 55 Changed 16 months ago by paulclinger

  • Blocked By
  • Patch unset

Replying to ngpaton:

If there is nothing going to happen in the short term might I suggest moving the definition of the wxTabFrame class from auibook.cpp to auibook.h which would then allow developers to apply the original patch in a derived class. Then it is up to the developer as to whether they want to support a possibly non-optimal save format. Personally I've found it very useful.

I opened #16262 long time ago to do this (it also includes a patch), so you may want to check the discussion in that ticket and see if the patch works for you.

comment:57 Changed 16 months ago by ngpaton

Thanks, I'll not hold my breath for the 'dynamic notebook' feature. I guess I'll just have to live with patching my local version.

Note: See TracTickets for help on using tickets.