3.1.0 plans

[Vadim Zeitlin]

Hello,

Now that 3.0.2 is done, the next goal for me is to release 3.1.0. My
original plan was to wait until all GSoC 2014 work was merged into trunk
before doing it, but I don't really know when the remaining projects
(Chromium WebView and wxAndroid) are going to be integrated, so maybe we
don't have to wait for this to happen.

The other big goal was the new dynamic notebook AUI branch integration.
But I am still not sure in which state it currently is, notably how
[in]compatible it is with the current UI and if there are [m]any
regressions. If it's in a good enough state, I'd merge it now to give the
new code more visibility.

And then there is a list of miscellaneous bugs with 3.1.0 milestone at

http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&milestone=3.1.0&group=component&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority

As usual, I think most of them will just end postponed, but I will try to
address at least some of them and would, of course, be glad for any help
with the others, especially OS X ones.

Finally, one of these bugs is about svn to git transition. This is not
something I want to block 3.1.0 release, but it would, of course, be great
to switch to git if we can.


All this being said, I think we should plan for the release in the (end)
of November[*]. We'll probably need at least one RC, too, so this leaves us
slightly more than a month to do what can be done.

What do you think?
VZ

[*] 2014

[Marian 'VooDooMan' Meravy]

Greetings,

On 2014-10-13 20:06, Vadim Zeitlin wrote:
> Hello,
>
> Now that 3.0.2 is done, the next goal for me is to release 3.1.0. My
> original plan was to wait until all GSoC 2014 work was merged into trunk
> before doing it, but I don't really know when the remaining projects
> (Chromium WebView and wxAndroid) are going to be integrated, so maybe we
> don't have to wait for this to happen.
>
> The other big goal was the new dynamic notebook AUI branch integration.
> But I am still not sure in which state it currently is, notably how
> [in]compatible it is with the current UI and if there are [m]any
> regressions. If it's in a good enough state, I'd merge it now to give the
> new code more visibility.

IMHO the main blocker is shitty SVN merge, not the hard merging procedure.

[1]November 2014 is enough time to merge GSOC into trunk. I don't want
to be rude, but it is lazyness thing, though very hard to achieve
(because of SVN).

best,
vdm
.

[Steven Lamerton]

On 13 October 2014 19:06, Vadim Zeitlin <va...@wxwidgets.org> wrote:

 Hello,

 Now that 3.0.2 is done, the next goal for me is to release 3.1.0. My
original plan was to wait until all GSoC 2014 work was merged into trunk
before doing it, but I don't really know when the remaining projects
(Chromium WebView and wxAndroid) are going to be integrated, so maybe we
don't have to wait for this to happen.

I think I am down to the last remaining build issue with wxWebViewChromium, I hope to get it sorted in time for 3.1.0.

Steven

[Xaviou]

Hi

Le lundi 13 octobre 2014 20:06:59 UTC+2, VZ a écrit :

Hello,

 The other big goal was the new dynamic notebook AUI branch integration.
But I am still not sure in which state it currently is, notably how
[in]compatible it is with the current UI and if there are [m]any
regressions. If it's in a good enough state, I'd merge it now to give the
new code more visibility.

Interresting.

Is there a way to test this ?

Regards

Xav' 

[Laurent Poujoulat]

Le 14/10/2014 08:05, Xaviou a écrit :

Hi

Le lundi 13 octobre 2014 20:06:59 UTC+2, VZ a écrit :

Hello,

 The other big goal was the new dynamic notebook AUI branch integration.
But I am still not sure in which state it currently is, notably how
[in]compatible it is with the current UI and if there are [m]any
regressions. If it's in a good enough state, I'd merge it now to give the
new code more visibility.

Well, the only serious issue remaining is that I did not yet updated the documentation. It should be a drop in replacement for the current wxAui at API level. For my own usage, it behaves better than the current one, but as the code base is really different, we might expect some surprises as more people will test it. The ABI is different of course, and there are some differences in the manager flags values.

I will update the interface files before the end of the week.

Interresting.

Is there a way to test this ?

You can get the dynamic wxAUi branch code from Nathan Hold's github repository.
https://github.com/nhold/wxWidgets.git

You will also find the list of opened issues at the same location. Most of them are new features request, or issues that already exist in the current wxAui.

Regards

Xav' 

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

You can ask me if there is any question/remark

Regards
Laurent

[Teodor Petrov]

Hi,

Just an of topic question:
Will this release be marked as stable or it will be a development
release similar to 2.9?

Sorry if this is answered before.

Best regards,
Teodor

[Werner]

On 10/14/2014 9:46, Teodor Petrov wrote:
> Hi,
>
> Just an of topic question:
> Will this release be marked as stable or it will be a development
> release similar to 2.9?
>

I think it follows this:

http://wiki.wxwidgets.org/Versions

Werner

[Bryan Petty]

On Tue, Oct 14, 2014 at 1:46 AM, Teodor Petrov <fusc...@gmail.com> wrote:
> Will this release be marked as stable or it will be a development release
> similar to 2.9?

Yes, this will be a development release as usual with odd-numbered versions.

--
Regards,
Bryan Petty

[Bryan Petty]

On Mon, Oct 13, 2014 at 12:06 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> Finally, one of these bugs is about svn to git transition. This is not
> something I want to block 3.1.0 release, but it would, of course, be great
> to switch to git if we can.

Robin: I have some time to help out with this, just let me know.

--
Regards,
Bryan Petty

[Artur Wieczorek]

> And then there is a list of miscellaneous bugs with 3.1.0 milestone at
>
> http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&milestone=3.1.0&group=component&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority
>
> As usual, I think most of them will just end postponed, but I will try to
> address at least some of them and would, of course, be glad for any help
> with the others, especially OS X ones.
>

I think it would be nice to address in 3.1 also these tickets:
#14324 - Because memory leak in the demonstration program doesn't look
good (patch proposed).
#16512 - Because wxBitmap is a core object (patch proposed).
#16539 - Because this enhancement seems reasonable and should be simple
in implementation (no patch but there is a solution outline). I could
help if necessary.

Regards,
AW

[Vadim Zeitlin]

On Sat, 18 Oct 2014 14:44:55 +0200 Artur Wieczorek wrote:

AW> I think it would be nice to address in 3.1 also these tickets:

Thanks for the reminders!

AW> #14324 - Because memory leak in the demonstration program doesn't look
AW> good (patch proposed).

I usually don't touch wxRTC stuff, but this one seems obvious, so I'll
take the risk of applying it, thanks.

AW> #16512 - Because wxBitmap is a core object (patch proposed).

I meant to look at this one since quite some time, sorry for taking so
long. The new patches are just perfect and I'm committing them. I guess
they should also be backported to 3.0 or do you think there might be some
code that could rely on the old, wrong, conversion behaviour?

AW> #16539 - Because this enhancement seems reasonable and should be simple
AW> in implementation (no patch but there is a solution outline). I could
AW> help if necessary.

To be honest, this doesn't strike me as very high priority, but it would
still be useful to have it, of course, so any patches would be gratefully
accepted.

More generally speaking, I'm going to try to review the list of pending
patches of which we have ~200 not counting the Python ones:

http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&version=!2.8.x&component=!wxPython&component=!Phoenix&component=!AGW&patch=1&group=component&col=id&col=summary&col=component&col=status&col=changetime&col=reporter&report=11&order=priority


And, after reviewing them, I'd also like to fix the following before 3.1.0
if possible (but none of them is really critical, so I'd still rather
release 3.1.0 in time rather than waiting until they are fixed):

#4437: DrawEllipticArc() should behave in the same way under all platforms.
#4711: Similarly wxListCtrl should behave in the same way everywhere too,
we need to decide how (difficult part) and implement it (simpler).
#16206: wxExecute() should handle spaces properly and it's easy to do.
#10884: We need to decide something about this, it's unlikely we're going
to have any new ideas after 5 years, but something does need to be
done.
#16339: Add copy ctor for wxStringTokenizer because it's embarrassing to
not have it.


Needless to say, any help with any of these tasks would be welcome too.
E.g. if people could test patches from the above list they're interested in
and report their results, it would be very, very useful.

TIA,
VZ

[Igor Korot]

Vadim,

Sorry to bother you but could you also include 4022 in the list.
It is a simple implementation, but needs to be tested and reviewed by
someone familiar with OSX.

Thank you.

[Paul K]

Vadim:

> The other big goal was the new dynamic notebook AUI branch integration. 
> But I am still not sure in which state it currently is, notably how 
> [in]compatible it is with the current UI and if there are [m]any 
> regressions. If it's in a good enough state, I'd merge it now to give the 
> new code more visibility. 

I tried to test the dynamic notebook branch back in mid May, but ran into several issues (all described here: https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ). I reviewed the list of commits applied after that build, but don't see changes that may affect/fix those issues (there was a change by mjmacleod to improve compatibility with replaced classes, which should be helpful for those bindings that may be still using the old api).

I plan to re-test on the current version of that branch, but I think we need more testing before the merge to iron out some of these issues. Also, there are several tickets in nhold's branch on github (https://github.com/nhold/wxWidgets/issues) and it seems like some of them need to be addressed before the merge.

Paul.

[Laurent Poujoulat]

Le 21/10/2014 20:13, Paul K a écrit :

Hi Paul,

Vadim:

> The other big goal was the new dynamic notebook AUI branch integration. 
> But I am still not sure in which state it currently is, notably how 
> [in]compatible it is with the current UI and if there are [m]any 
> regressions. If it's in a good enough state, I'd merge it now to give the 
> new code more visibility. 

I tried to test the dynamic notebook branch back in mid May, but ran into several issues (all described here: https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ). I reviewed the list of commits applied after that build, but don't see changes that may affect/fix those issues (there was a change by mjmacleod to improve compatibility with replaced classes, which should be helpful for those bindings that may be still using the old api).

Please test with the current version in Nathan's repository and report the remaining issues you have in github's ticket system. In the current state, the new wxAui is pretty stable and I use it in several production applications since months. The problem is, if it stays aside out the main repository, very few people will see and test it, and the few people regularly involved can't cover all the use cases of those pretty rich classes. Sure it's not perfect, but we have to merge it back for the unstable 3.1 so we have a real chance to make it visible, used, tested and debugged in all aspects.

I plan to re-test on the current version of that branch, but I think we need more testing before the merge to iron out some of these issues. Also, there are several tickets in nhold's branch on github (https://github.com/nhold/wxWidgets/issues) and it seems like some of them need to be addressed before the merge.

Of the remaining issues reported on github, aside of enhancements, the remaining ones are:
- Documentation: I just completed it and made a pull request for Nathan's.
- wxAuiTabContainer issues: no complete fix is done for this, and we wonder if it should really be fixed (see discussion in the ticket)
- Hint drawing in corner cases: not mandatory to fix this for merging
- Updated sample for new features: it's a work in progress. The current sample works out of the box with the new wxAui.
- Docking in center area is fixed (the bug as never been closed as we are using it to discuss a side effect of docking in center area)

So nothing here is really blocking.

Best regards
Laurent

--

[Paul K]

Laurent:

> Please test with the current version in Nathan's repository and report the remaining issues you have in github's ticket system. In the current state, the new wxAui is pretty stable and I use it in several production applications since months.

I just finished testing with the current version of the dynamic-notebook branch and unfortunately I still see the same issues I described in my earlier email. I'm attaching a screenshot to give a better picture on what defects we are talking about. Notice that in my case the defects are visible just by starting the application. I should mention that the current version of the application (based on wxwidgets 2.9.5) has been in wide used on Windows/OSX/Linux for at least two years (earlier versions were using 2.8).

I also noticed another issue that I should mention. All event handlers like wxEVT_COMMAND_AUINOTEBOOK_BG_DCLICK and wxEVT_COMMAND_AUINOTEBOOK_TAB_RIGHT_UP get wxAuiNotebook object instead of wxAuiTabCtrl object they were getting before. wxAuiTabCtrl object is gone, but instead they should be getting wxAuiTabContainer object as there may be multiple containers for the same notebook (when the tabs are split) and for proper click handling the user would need to know which of the containers is sending the event.

I noticed that the current version has a similar issue with wxEVT_AUINOTEBOOK_PAGE_CHANGING: when the event is called after a tab click it sets wxAuiTabCtrl as EventObject(), but when it happens from wxAuiNotebook::DoModifySelection, it sets wxAuiNotebook as EventObject(), whereas it should probably be wxAuiTabCtrl (to know what tabctrl triggered the change as there may be multiple controls per notebook). wxEVT_AUINOTEBOOK_PAGE_CHANGED called from DoModifySelection suffers from the same issue as it reuses the same event.

I haven't opened a ticket for this as with the coming merge it's a moot point, but I think it needs to be address in the dynamic notebook branch as well.

Paul.

[Laurent Poujoulat]

Le 24/10/2014 07:50, Paul K a écrit :

Laurent:

> Please test with the current version in Nathan's repository and report the remaining issues you have in github's ticket system. In the current state, the new wxAui is pretty stable and I use it in several production applications since months.

I just finished testing with the current version of the dynamic-notebook branch and unfortunately I still see the same issues I described in my earlier email. I'm attaching a screenshot to give a better picture on what defects we are talking about. Notice that in my case the defects are visible just by starting the application. I should mention that the current version of the application (based on wxwidgets 2.9.5) has been in wide used on Windows/OSX/Linux for at least two years (earlier versions were using 2.8).

Thanks for the test, and I must admit I'm very surprised of the result. Did you restore an existing perspective in this test ? If so, could you try without restoring it: the save format is not compatible as the values of some flags have changed and probably more.

I also noticed another issue that I should mention. All event handlers like wxEVT_COMMAND_AUINOTEBOOK_BG_DCLICK and wxEVT_COMMAND_AUINOTEBOOK_TAB_RIGHT_UP get wxAuiNotebook object instead of wxAuiTabCtrl object they were getting before. wxAuiTabCtrl object is gone, but instead they should be getting wxAuiTabContainer object as there may be multiple containers for the same notebook (when the tabs are split) and for proper click handling the user would need to know which of the containers is sending the event.

I noticed that the current version has a similar issue with wxEVT_AUINOTEBOOK_PAGE_CHANGING: when the event is called after a tab click it sets wxAuiTabCtrl as EventObject(), but when it happens from wxAuiNotebook::DoModifySelection, it sets wxAuiNotebook as EventObject(), whereas it should probably be wxAuiTabCtrl (to know what tabctrl triggered the change as there may be multiple controls per notebook). wxEVT_AUINOTEBOOK_PAGE_CHANGED called from DoModifySelection suffers from the same issue as it reuses the same event.

It may be tricky to have the exact same event handling as the wxAuiNotebook had major changes. I'd be interested to have some hints on how you reuse the event object information when processing the event. It may help to find a suitable solution.

I haven't opened a ticket for this as with the coming merge it's a moot point, but I think it needs to be address in the dynamic notebook branch as well.

I agree we'll have to dig into this as soon as the merge is done.

Paul.

Thanks again for the time time you spent on testing.
Regards
Laurent

[Kinaou Herve]

Hello,

What about Doc/View framework for wxAui MDI ?

The patch works pretty well under Windows (and was already ported on wxPyton as far as I know), but it lacks a bit of work to make it work with GTK.

http://trac.wxwidgets.org/ticket/8945#comment:65

The work on aui-dynamic-notebook will probably be in conflict with some parts of the code, but I have no more time (nor energy after 7 years) to work on that.

The patch had been applied by vadz on its GitHub fork :

https://github.com/vadz/wxWidgets/tree/8945-aui-mdi

And on my own fork with a (ugly) debug proposal which allows to start seeing the problem with GTK :

https://github.com/ru10/wxWidgets/tree/8945-aui-mdi

Hoping seeing this patch applied a day...

Regards,

Kinaou (alias R.U.10)

Le lundi 13 octobre 2014 20:06:59 UTC+2, VZ a écrit :

[Vadim Zeitlin]

On Fri, 24 Oct 2014 09:39:17 +0200 Laurent Poujoulat wrote:

LP> Thanks for the test, and I must admit I'm very surprised of the result.

Yes, this doesn't look good at all. Thanks a lot for testing Paul, but the
results are not what I would have expected :-(

LP> Did you restore an existing perspective in this test ? If so, could you
LP> try without restoring it: the save format is not compatible as the
LP> values of some flags have changed and probably more.

Even if this explains the problem, wxAUI needs to detect the old version
(e.g. by prefixing the new one with "version=2" and supposing that
perspectives without "version=" prefix as from the old version). We really
don't want people to see their GUI broken after upgrading to wxWidgets 3.2.

Regards,
VZ

[Vadim Zeitlin]

On Fri, 24 Oct 2014 04:08:18 -0700 (PDT) Kinaou Herve wrote:

KH> What about Doc/View framework for wxAui MDI ?

Sorry, I know I promised to apply it for many years, but for me the new
AUI merge remains a higher priority, so I'd like to do it first, if
possible, and then merge this one later.

KH> The patch works pretty well under Windows (and was already ported on
KH> wxPyton as far as I know), but it lacks a bit of work to make it work with
KH> GTK.
KH> http://trac.wxwidgets.org/ticket/8945#comment:65

What about OS X which was traditionally the most problematic platform for
wxAUI?

KH> The work on aui-dynamic-notebook will probably be in conflict with some
KH> parts of the code, but I have no more time (nor energy after 7 years) to
KH> work on that.

I understand this. I'll try to resolve the conflicts myself if/when it's
being merged.

Regards,
VZ

[Laurent Poujoulat]

Le 24/10/2014 15:06, Vadim Zeitlin a écrit :
> On Fri, 24 Oct 2014 09:39:17 +0200 Laurent Poujoulat wrote:
>
> LP> Thanks for the test, and I must admit I'm very surprised of the result.
>
> Yes, this doesn't look good at all. Thanks a lot for testing Paul, but the
> results are not what I would have expected :-(

This is why I'd like to have more details on wxAui usage by Paul's
application, as nor me or Malcom or Nathan had such problem.

>
> LP> Did you restore an existing perspective in this test ? If so, could you
> LP> try without restoring it: the save format is not compatible as the
> LP> values of some flags have changed and probably more.
>
> Even if this explains the problem, wxAUI needs to detect the old version
> (e.g. by prefixing the new one with "version=2" and supposing that
> perspectives without "version=" prefix as from the old version). We really
> don't want people to see their GUI broken after upgrading to wxWidgets 3.2.

The way perspective are saved (even now) quickly leads to such artefacts
if there is even the smallest mismatch between panes and the saved data
in the perspective. I myself add some logic to my applications to ignore
saved perspectives when the list of panes may have changed and avoid
these. I think testing the perspective version is a good way to proceed,
and maybe there's a way to adapt the saved data when we detect an old
format. I'll dig into this.

>
> Regards,
> VZ
I committed the documentation fixes suggested by you and Malcom, but I
don't know where to put the list of incompatibilities and known bugs.

Regards
Laurent

[Paul K]

Laurent,

> Thanks for the test, and I must admit I'm very surprised of the result. Did you restore an existing perspective in this test ? If so, could you try without restoring it: the save format is not compatible as the values of some flags have changed and probably more.

Yes, I tried it in several ways: restoring the existing perspective (you see it on the screenshot), starting with an empty perspective (the issues are similar, although the content of the windows is slightly different), and then saving and restoring the new perspective (the result looked like the screenshot as well).

I also compiled this on OSX and got very similar results with one difference: the content of the tree control you see on the left side of the screenshot is clickable on OSX, but is not clickable on Windows. In either case the screen looks very similarly broken (I can provide a screenshot).

In both cases (Windows and OSX) when the docked pane that includes wxAuiNotebook is being hidden, the content of the notebook tabs (wxTreeCtrl) is still visible on the page.

The results I see are quite strange to me as I don't do anything fancy: all my panes have the same structure that includes wxAuiNotebook with some tabs that either have wxSTC or wxTreeCtrl and nothing else. For some reason, the pane that you see on the left (it has wxAuiNotebook, which includes two tabs with wxTreeCtrl objects each) has the tree controls drawn incorrectly with some see-through areas and some parts drawn even when the pane is hidden.

As I already said, it's possible I made a mistake in updating wxlua API to work with wxAuiTabContainer changes, but I'd still not expect all the effects I see as some things are working fine and some are completely off (and don't seem to be related to those straightforward changes I made).

> It may be tricky to have the exact same event handling as the wxAuiNotebook had major changes. I'd be interested to have some hints on how you reuse the event object information when processing the event. It may help to find a suitable solution.

I think wxAuiTabContainer should be provided for all those events for three reasons: (1) consistency with how it's done now as most of those events get wxAuiTabCtrl, (2) the dev can also find wxAuiNotebook this event is for, but not necessarily the tabContainer this event is for, (3) some APIs around wxwidgets only expose public methods (wxlua I'm using is a good example) and since GetActiveTabCtrl() is a protected method I have no way to know which tab control/container generates the event.

One of the use cases I need this for is very simple: when the user doubleclicks on a tab background I need to add a new tab, but it needs to be added to the tab control the user clicked on (as there may be multiple controls in the case of split notebooks). The old API provided the tab control as EventObject for wxEVT_COMMAND_AUINOTEBOOK_BG_DCLICK, but the new API provides wxAuiNotebook object, which is useless in this context; even having GetActiveTabCtrl() doesn't help as the click can be on inactive tab background as well.

Paul.

[Paul K]

Laurent,

I've got big help from one of wxwidgets users who dig into wxwidgets and wxlua code and figured what contributed to some of the issues I was describing (thanks Roberto!). Those drawing artifacts seems to be caused by window ownership: wxTreeCtrl is owned by the main frame when added to the notebook; if I change the parent to the notebook then this particular issue doesn't happen anymore.

Unfortunately this is not something I can (or should) fix in my code as in my case the control is created before the notebook is created (to which it is added) and this was working before, so I assume other users may run into the same issue. The current code rightfully calls page->Reparent(this) inside wxAuiNotebook::InsertPage, so it doesn't matter what ownership the control has, but I don't see this happening in the new code, which is likely to cause this issue unless the added page is already owned by the notebook (which is not a safe assumption).

Paul.

[Laurent Poujoulat]

Le 25/10/2014 20:10, Paul K a écrit :
> Laurent,
>

> I've got big help from one of wxwidgets users who dig into wxwidgets and
> wxlua code and figured what contributed to some of the issues I was
> describing (thanks Roberto!). Those drawing artifacts seems to be caused by
> window ownership: wxTreeCtrl is owned by the main frame when added to the
> notebook; if I change the parent to the notebook then this particular issue
> doesn't happen anymore.
>
> Unfortunately this is not something I can (or should) fix in my code as in
> my case the control is created before the notebook is created (to which it
> is added) and this was working before, so I assume other users may run into
> the same issue. The current code rightfully calls page->Reparent(this)
> inside wxAuiNotebook::InsertPage, so it doesn't matter what ownership the
> control has, but I don't see this happening in the new code, which is
> likely to cause this issue unless the added page is already owned by the
> notebook (which is not a safe assumption).
>
> Paul.

Excellent. The fix seems pretty easy. I'll patch this tomorrow.

Thanks a lot Paul.

[Nathan Hold]

Have already committed it, and am testing now.

Thanks for that Paul and Roberto. As for the event changes, I am not sure of the repercussions for changing it so I'll see if I can investigate that.

Another thing that needs discussion is https://github.com/nhold/wxWidgets/issues/61/

[Paul K]

Hi Nathan,

> Thanks for that Paul and Roberto. As for the event changes, I am not sure of the repercussions for changing it so I'll see if I can investigate that.

Here is the list of events that should get wxAuiTabContainer as the EventObject:

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_PAGE_CLOSE, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_PAGE_CLOSED, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_PAGE_CHANGING, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_PAGE_CHANGED, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_BUTTON, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_BEGIN_DRAG, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_END_DRAG, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_CANCEL_DRAG, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_DRAG_MOTION, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_ALLOW_DND, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_BG_DCLICK, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_DRAG_DONE, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_TAB_MIDDLE_UP, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_TAB_MIDDLE_DOWN, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_TAB_RIGHT_UP, wxAuiNotebookEvent);

wxDEFINE_EVENT(wxEVT_AUINOTEBOOK_TAB_RIGHT_DOWN, wxAuiNotebookEvent);

I realized what might have happened with some of these cases. It seems like the code for many event handlers was copied from wxAuiTabCtrl, but in that case "this" referred to wxAuiTabCtrl, but in the new code it refers to wxAuiNotebook, which is a mistake in my opinion as it should refer to the appropriate wxAuiTabContainer.

Paul.

[Paul K]

Laurent, Nathan,

> Excellent. The fix seems pretty easy. I'll patch this tomorrow. 

Couple of other issues I noticed (using updated version of nathan's branch compiled on Windows):

1. The drawing is not correct between the notebooks and on top of the tab area of the notebook. I'm attaching the screenshot with new/incorrect (on the left) and old/correct (on the right) images. I marked the areas with red arrows, but you can see that the lines are missing with the new version. The sash size is 2 in the images, but the issue is the same with the default sash.

2. I can't get selection switch to work when I'm adding new pages. AddPage() takes the third parameter true/false and true is supposed to trigger selection to the newly added tab and for some reason it doesn't in my case (the master branch works as expected).

I see "if (select || GetPageCount() == 1) SetSelection(pageIndex);" in the code, so I'm not sure what the problem may be. Executing notebook:SetSelection(indexofaddedpage) works as expected.

I still get random crashes when closing tabs or the application and some of my tabs are completely missing when loading the application (you can see on the screenshot that there should be two tabs at the bottom). Even more strangely, where the tabs are not shown, the content may be from one tab, but the label from another.

Paul

[Igor Korot]

Hi, Laurent, Nathan,

On Wed, Oct 29, 2014 at 10:37 PM, Paul K <paulc...@gmail.com> wrote:
> Laurent, Nathan,
>
>> Excellent. The fix seems pretty easy. I'll patch this tomorrow.

Is ticket 3861 will be fixed with the new code?

Thank you.

[Laurent Poujoulat]

Le 30/10/2014 12:48, Igor Korot a écrit :
> Hi, Laurent, Nathan,
>
> On Wed, Oct 29, 2014 at 10:37 PM, Paul K <paulc...@gmail.com> wrote:
>> Laurent, Nathan,
>>
>>> Excellent. The fix seems pretty easy. I'll patch this tomorrow.
> Is ticket 3861 will be fixed with the new code?

Just tried, and it's ok. At least one less problem :) There is still a
limitation that the center panes can only be docked as tabs or side by
side vertically, but not horizontally.

[Malcolm MacLeod]

> Couple of other issues I noticed (using updated version of nathan's
> branch compiled on Windows):
> 1. The drawing is not correct between the notebooks and on top of the
> tab area of the notebook. I'm attaching the screenshot with
> new/incorrect (on the left) and old/correct (on the right) images. I
> marked the areas with red arrows, but you can see that the lines are
> missing with the new version. The sash size is 2 in the images, but
> the issue is the same with the default sash.

It would be helpful if you could open issues for these as you find them
on the bug tracker for the branch, it makes it easier if everything is
in one place.

>
>
> 2. I can't get selection switch to work when I'm adding new pages.
> AddPage() takes the third parameter true/false and true is supposed to
> trigger selection to the newly added tab and for some reason it
> doesn't in my case (the master branch works as expected).

I suspect this is because wxAuiNotebook::InsertPage calls m_mgr.Update()
after SetActivePane, it seems the SetActivePane code checks if a pane is
in a 'notebook' by traversing all the tab containers looking for it -
and as the update has not yet happened won't find anything.

IIRC SetActivePane was working differently at a point for notebooks, by
doing the same calculation that m_mgr.Update does, but this was changed
by someone for performance or other reasons, can't recall exactly
offhand, but likely this is a regression from that.

If you (or someone) can try add a m_mgr.Update() call just before that
SetActivePane call (but leave the one afterwards in as well) and see if
that helps it should give an idea.

>
> I still get random crashes when closing tabs or the application and
> some of my tabs are completely missing when loading the application
> (you can see on the screenshot that there should be two tabs at the
> bottom). Even more strangely, where the tabs are not shown, the
> content may be from one tab, but the label from another.

That you are using wxLua and not the code directly makes it a bit hard
to do anything about this (is your application code available?) as this
could just as easily be a double free or something else.
Could it be related to
https://github.com/nhold/wxWidgets/issues/75#issuecomment-61147861 ?
Can you maybe at least catch one of these random crashes in a debugger
so we can see a stack trace?

- Malcolm MacLeod

[Barry Scott]

On 13 Oct 2014, at 19:06, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>
> Hello,
>
> Now that 3.0.2 is done, the next goal for me is to release 3.1.0. My
> original plan was to wait until all GSoC 2014 work was merged into trunk
> before doing it, but I don't really know when the remaining projects
> (Chromium WebView and wxAndroid) are going to be integrated, so maybe we
> don't have to wait for this to happen.
>
> The other big goal was the new dynamic notebook AUI branch integration.
> But I am still not sure in which state it currently is, notably how
> [in]compatible it is with the current UI and if there are [m]any
> regressions. If it's in a good enough state, I'd merge it now to give the
> new code more visibility.
>
> And then there is a list of miscellaneous bugs with 3.1.0 milestone at
>
> http://trac.wxwidgets.org/query?status=accepted&status=confirmed&status=new&status=reopened&milestone=3.1.0&group=component&col=id&col=summary&col=milestone&col=status&col=type&col=priority&col=component&order=priority
>
> As usual, I think most of them will just end postponed, but I will try to
> address at least some of them and would, of course, be glad for any help
> with the others, especially OS X ones.
>
> Finally, one of these bugs is about svn to git transition. This is not
> something I want to block 3.1.0 release, but it would, of course, be great
> to switch to git if we can.
>
>
> All this being said, I think we should plan for the release in the (end)
> of November[*]. We'll probably need at least one RC, too, so this leaves us
> slightly more than a month to do what can be done.
>
> What do you think?

When will you transistion to the excelent phoenix base wxPython?

Barry

> VZ
>
> [*] 2014