wxAUI Docking & Floating problem

[Michael Richards]

Hi,

I've been using the nhold branch in GIT so I'm not sure how to mention bugs and problems.

If I should create a trac ticket I can.

Here is the problem. If you have a pane that is both center dockable and floatable you can't manage to manipulate it as a floating window or the windowmanager will always try to dock it.

I believe QT overcomes this problem by displaying an icon indicating where to dock it and you have to actually dock it on that icon to have it dock.
Another application I use forces you to grab the window by the gripper not the titlebar. I think this would be a very worthwhile change, allow a flag that allows docking only to occur if you grabbed a window by its gripper (assuming it has one).

Barring that, is there any realistic way to do this using the existing interface?

thanks

-Michael

[Kinaou Herve]

Hello,

Look at this trac which talk about a similar issue and with some ideas to resolve it:

http://trac.wxwidgets.org/ticket/15906

And this one which seems to say that the gripper issue is (almost) resolved:

http://trac.wxwidgets.org/ticket/13177

Regards,

KH

[Michael Richards]

Yes, the first ticket applies. I didn't see it before when I looked. I don't think their suggestion would work in my case but I had no idea that holding a key could do that. I added my own ideas.

The second ticket, I'm not able to reproduce the problem using the nhold code so I assume it has or will be fixed if and when that stream gets merged in. I'm quite happy with the stability of the nhold series of code. It has yet to let me down and I've been testing and application quite extensively for at least 10h solid. I'll be spending most of the day today still working with it. As I get more time in on this thing I think I'd like to spend a day or so and write up some proper documentation - something aui has been a little sparse on from the beginning.

-Michael

[Malcolm MacLeod]

Just to hijack a bit here based on the endorsement of nhold branch by
Michael.

Is there something in particular stopping a merge of the AUI code base
at this point?

While unfortunately I've personally been rather absent for the last
year, there seems to still be activity and contributions on the fork
from others, people seem to be generally happy with it, the issue list
has a lot of issues but these are almost all feature enhancements and/or
things that are wrong with the mainline AUI as well.

In short there seems enough active support for it, that I don't think
concerns of the code being 'dumped' on wx are valid.


Before all these features start getting implemented and the code base
diverges even further from mainstream, would now not be a good time to
go ahead with the merge?
This would finally allow people to start working on other improvements
(like better drop hints etc.) that a lot have been itching for etc. as
well.

I suspect there is a lot of AUI development that people would like to do
but are not, because they are a bit reserved about whether this merge is
ever going to take place or not.

My availability is currently a bit better, so if we do go ahead with the
merge I can make myself available for any high priority issues that crop
up.

Regards,
Malcolm MacLeod

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

[Igor Korot]

Hi,

On Tue, Jul 21, 2015 at 6:53 AM, Malcolm MacLeod <mmac...@webmail.co.za> wrote:
> Just to hijack a bit here based on the endorsement of nhold branch by
> Michael.
>
> Is there something in particular stopping a merge of the AUI code base
> at this point?
>
> While unfortunately I've personally been rather absent for the last
> year, there seems to still be activity and contributions on the fork
> from others, people seem to be generally happy with it, the issue list
> has a lot of issues but these are almost all feature enhancements and/or
> things that are wrong with the mainline AUI as well.
>
> In short there seems enough active support for it, that I don't think
> concerns of the code being 'dumped' on wx are valid.
>
>
> Before all these features start getting implemented and the code base
> diverges even further from mainstream, would now not be a good time to
> go ahead with the merge?
> This would finally allow people to start working on other improvements
> (like better drop hints etc.) that a lot have been itching for etc. as
> well.
>
> I suspect there is a lot of AUI development that people would like to do
> but are not, because they are a bit reserved about whether this merge is
> ever going to take place or not.
>
> My availability is currently a bit better, so if we do go ahead with the
> merge I can make myself available for any high priority issues that crop
> up.

Besides with this merge we can try to do a 3.1 release...

Thank you.

[Vadim Zeitlin]

On Tue, 21 Jul 2015 12:53:33 +0200 Malcolm MacLeod wrote:

MM> Is there something in particular stopping a merge of the AUI code base
MM> at this point?

To the best of my knowledge, the last time this was discussed the
conclusion was that more work was needed and that a merge would be proposed
when this work is done. This proposal has unfortunately never been
received so I suppose that there still remain things to do.

MM> Before all these features start getting implemented and the code base
MM> diverges even further from mainstream, would now not be a good time to
MM> go ahead with the merge?

If it is compatible and works, yes. We really need to check building and
running at least some of wx applications using AUI (CodeBlocks?) to verify
that this is the case though.

Regards,
VZ

[Michael Richards]

I have had the nhold code in production now for 4 months with about 500 users. It's not perfect but is much better than the stuff in the wx tree. As an update to my earlier post 7 months ago I continue my vote to merge it.

-Michael

On Tue, Jul 21, 2015 at 6:53 AM, Malcolm MacLeod <mmac...@webmail.co.za> wrote:

[Vadim Zeitlin]

On Tue, 21 Jul 2015 10:47:57 -0400 Michael Richards wrote:

MR> I have had the nhold code in production now for 4 months with about 500
MR> users. It's not perfect but is much better than the stuff in the wx tree.
MR> As an update to my earlier post 7 months ago I continue my vote to merge it..

"Not perfect" is not a problem on its own. But "has regressions compared
to the current version" definitely is. This is why testing with the
existing applications using AUI would be so important.

Regards,
VZ

[Michael Richards]

I can work with the example app to validate that it continues to work.

The other point is that few people are actually using AUI. Possibly because of documentation and lack of how-to type info. If there are going to be any API additions or deprecations it would be ideal to do so sooner rather than later. Once these things are settled I can definitely contribute to the docs since I have enough hundreds of hours to understand it at a reasonable level.

-Michael

[Vadim Zeitlin]

On Tue, 21 Jul 2015 11:11:39 -0400 Michael Richards wrote:

MR> I can work with the example app to validate that it continues to work.

This would be most welcome. Testing CodeBlocks would be very much so too.
And I think there are other wx IDEs (CodeLite?) using AUI as well. If no
regressions are found in at a couple of big applications using AUI, it
would help my confidence in the new code compatibility tremendously.

MR> The other point is that few people are actually using AUI. Possibly because
MR> of documentation and lack of how-to type info. If there are going to be any
MR> API additions or deprecations it would be ideal to do so sooner rather than
MR> later. Once these things are settled I can definitely contribute to the
MR> docs since I have enough hundreds of hours to understand it at a reasonable
MR> level.

This would, again, be great, of course. But I'm intentionally setting the
bar as low as possible for the merge: I know that current AUI docs are
pretty bad, but the only thing I'd like to ensure is that they don't get
even worse, e.g. refer to things that have changed in the new code.

Regards,
VZ

[Jens Lody]

Am Dienstag, den 21.07.2015, 17:22 +0200 schrieb Vadim Zeitlin:
> On Tue, 21 Jul 2015 11:11:39 -0400 Michael Richards wrote:
>
> MR> I can work with the example app to validate that it continues to
> work.
>
> This would be most welcome. Testing CodeBlocks would be very much so
> too.

I can (and for sure will do) this tests.
And the update will for sure break parts of Code::Blocks, because we
use an own class derived from wxAuiNotebook. Not everything does work,
if I tried the last time (if I remember correctly), but C::B is still
not fully compatible with wx3 and is build against 2.8.12 on almost all
platforms (except my debian nightlies).
I will update my wxAui-repo and test it as soon as possible (my last
workday for the next three weeks is tomorrow, so I should find some
time).

--

Jens Lody

Code::Blocks core developer
http://www.codeblocks.org/

(Un-)official debian-repository for Code::Blocks:
http://apt.jenslody.de/

(Un-)official Fedora- and RedHat/CentOS-repository for Code::Blocks
and Fedora-repository of my gnome-shell-extensions:
http://rpm.jenslody.de/

Developer of OpenWeather and Panel OSD gnome-shell extensions:
https://extensions.gnome.org/extension/750/openweather/
https://extensions.gnome.org/extension/708/panel-osd/

|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
<|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

[Michael Richards]

> MR> I can work with the example app to validate that it continues to
> work.
>
>  This would be most welcome. Testing CodeBlocks would be very much so
> too.
I can (and for sure will do) this tests.
And the update will for sure break parts of Code::Blocks, because we
use an own class derived from wxAuiNotebook. Not everything does work,
if I tried the last time (if I remember correctly), but C::B is still
not fully compatible with wx3 and is build against 2.8.12 on almost all
platforms (except my debian nightlies).
I will update my wxAui-repo and test it as soon as possible (my last
workday for the next three weeks is tomorrow, so I should find some
time).

This would be a great help. When I was offering to test I had the samples app in mind to make sure its behaviour did not change and to make sure the notebook specifics are added as well. I don't really use codeblocks so I wouldn't have the slightest clue where to start.

-Michael

[Eran Ifrah]

On Tue, Jul 21, 2015 at 6:22 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Tue, 21 Jul 2015 11:11:39 -0400 Michael Richards wrote:

MR> I can work with the example app to validate that it continues to work.

 This would be most welcome. Testing CodeBlocks would be very much so too.
And I think there are other wx IDEs (CodeLite?) using AUI as well.

​Yes it does. Note that we don't use wxAuiNotebook though, just the docking

I will be happy to test it (CodeLite is already running on wxWidgets 3.1 (git master) on OSX and Windows)

Just for clarification, is https://github.com/nhold/wxWidgets the correct repo of the wxAUI branch?

 

If no
regressions are found in at a couple of big applications using AUI, it
would help my confidence in the new code compatibility tremendously.

MR> The other point is that few people are actually using AUI. Possibly because
MR> of documentation and lack of how-to type info. If there are going to be any
MR> API additions or deprecations it would be ideal to do so sooner rather than
MR> later. Once these things are settled I can definitely contribute to the
MR> docs since I have enough hundreds of hours to understand it at a reasonable
MR> level.

 This would, again, be great, of course. But I'm intentionally setting the
bar as low as possible for the merge: I know that current AUI docs are
pretty bad, but the only thing I'd like to ensure is that they don't get
even worse, e.g. refer to things that have changed in the new code.

 Regards,
VZ

--

Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Eran Ifrah]

I cloned, compiled and tested the sample (before I try to compile CodeLite with this branch), some observations:

1. When toggling the "Dynamic Notebooks" I cant seem to re-size the main panes (two controls with the long texts) the sash is moving, but their sizes remain

2. While attempting to re-size these 2 panes, the mouse was captured and was never released (the cursor shape is stuck with the double arrow icon). To release it, I needed to tab in and out from the sample application

3. (Dynamic Notebook ON): I created a notebook on the left with 3 pages, I captured one of tabs and dragged it right and left (changed its position, but did not detach it from the notebook)

   while DnD the tab, the wxAuiNotebook size was changing to capture more space in the general layout. 

In the first screenshot, you can see the "Text Control" is at position 0, and height of the notebook is just under "pane"

In the second screenshot, "Text Control" is positioned at 1, however, now the height of the notebook is under "corner"

Not that much of a big deal, but ....

Bug #2 is the most important

Also: should we have a separate thread for reporting bugs? report them directly to the git issue tracker? or...?

[Malcolm MacLeod]

Ideally report them to the git issue tracker with as much info as
possible, I'm going to try contact Nathan to see if we can 'triage' the issues into milestones so that it is more obvious which are the real issues and which are feature requests.

>
> Also: should we have a separate thread for reporting bugs? report them
> directly to the git issue tracker? or...?
>
>
>
>

> Inline image 1Inline image 2

[Malcolm MacLeod]

> 1. When toggling the "Dynamic Notebooks" I cant seem to re-size the
> main panes (two controls with the long texts) the sash is moving, but
> their sizes remain
> 2. While attempting to re-size these 2 panes, the mouse was captured
> and was never released (the cursor shape is stuck with the double
> arrow icon). To release it, I needed to tab in and out from the
> sample application

This seems to be because they are both center panes, which in fairness
is something that shouldn't happen in an app that isn't using dynamic
notebooks anyway.. (Previously AUI always assumed a si ngle center
pane) However I will look into it when I have some time and patch it.

> 3. (Dynamic Notebook ON): I created a notebook on the left with 3
> pages, I captured one of tabs and dragged it right and left (changed
> its position, but did not detach it from the notebook)
> while DnD the tab, the wxAuiNotebook size was changing to capture
> more space in the general layout.

I can't reproduce this, can you provide more details?
Which platform, which git commit? Did you toggle any other options in
the sample before you did this?

- Malcolm

[Carsten Fuchs]

Hi all,

I too would love to see the new AUI code in official wxWidgets soon, so
I followed the request here to provide at least some testing. My program
makes use of wxAUI extensively, implementing most of its children
window/panes arrangement with it.

Using https://github.com/nhold/wxWidgets.git at commit 7697ea6 of
2015-07-23, until now I found no problems but one: saving a perspective
into a string, then restoring the perspective from the string seems not
to work entirely. For example, in my main window's constructor I use
this code:


// Save the AUI perspective that we set up in this ctor code as the
// "default perspective".
m_AUIDefaultPerspective = m_AUIManager.SavePerspective();

// Load the AUI user perspective (implies a call to
m_AUIManager.Update()).
m_AUIManager.LoadPerspective(
wxConfigBase::Get()->Read("MapEditor_AUIUserPerspective",
m_AUIDefaultPerspective));


This used to work in "old" wxAUI code, but somehow "loses" one of the
child panes in the new wxAUI. It also works normally if the above two
lines are replaced by a simple m_AUIManager.Update(); .

(I think that this or a very similar problem has been mentioned here in
the past, but I'm not able to find the related message again.)

Is there anything I can do to provide some helpful information?
Unfortunately, I'm mostly unfamiliar with the (old or new) wxAUI code.

Best regards,
Carsten

[Paul K]

Hi Carsten,

> This used to work in "old" wxAUI code, but somehow "loses" one of the 
> child panes in the new wxAUI. It also works normally if the above two 
> lines are replaced by a simple  m_AUIManager.Update();  . 

> (I think that this or a very similar problem has been mentioned here in 
> the past, but I'm not able to find the related message again.)

Yes, I noticed the same thing (and described it here: https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ; item #6). I'm periodically re-testing with the new branch, but this (and other) issues are still present.

Some other issues I also mentioned earlier: https://groups.google.com/forum/#!msg/wx-dev/RCLXWP5rRzg/mMcUXeBAn6IJ.

Here is the suggestion I made with the list of events that are produced/handled by the current code, but not by the new one: https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/R2H3AnXgUlgJ; here is the related ticket with a recent discussion on this: https://github.com/nhold/wxWidgets/issues/99. I think it's unfortunate that some of these events got dropped and others have changed the object they are called on (from wxAuiTabCtrl/wxAuiTabContainer to wxAuiNotebook) as this may break existing applications (my included).

Paul.

[Malcolm MacLeod]

The problem remains as before that you have given some very vague
information based on a custom binding of yours, and have acknowledged
yourself that it is quite possible your binding does things that
involve using undocumented parts of AUI in ways that they were never
intended for.

This makes it very difficult for anyone else to actually do anything
about this. Ideally if you could.
1) Open bug reports on the github where we are dealing with this so
that we can actually keep track of the bug properly. If you are paying
attention you will see that the github is quite active with most
legitimate issues being addressed.
2) Try and give some actual information we can work with as opposed to
a very vague list of ones liners.
3) Try and reproduce this using the proper C++ API *or* make your
binding available in an easy to use way with a testcase so that we can
actually have a look at what it is that you are doing that doesn't
work?
4) Contribute a pull request with a fix.

Otherwise I really don't know what can be done.. It is not possible to
handle every single fringe misuse of non public parts of the previous
API especially if the people doing so are not willing to cooperate.

In the meantime the 99% of people who use the public parts of AUI and
don't rely on the undocumented parts must continue to sit with AUI in a
terrible state because all progress remains blocked.

> Hi Carsten,
>
> > This used to work in "old" wxAUI code, but somehow "loses" one of
> the
> > child panes in the new wxAUI. It also works normally if the above
> two
> > lines are replaced by a simple m_AUIManager.Update(); .
>
> > (I think that this or a very similar problem has been mentioned
> here in
> > the past, but I'm not able to find the related message again.)
>
> Yes, I noticed the same thing (and described it here:
> https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ; item
> #6). I'm periodically re-testing with the new branch, but this (and
> other) issues are still present.
>
> Some other issues I also mentioned earlier:
> https://groups.google.com/forum/#!msg/wx-dev/RCLXWP5rRzg/mMcUXeBAn6IJ
> .
>
> Here is the suggestion I made with the list of events that are
> produced/handled by the current code, but not by the new one:
> https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/R2H3AnXgUlgJ; here
> is the related ticket with a recent discussion on this:

> . I think it'sunfortunate that some of these events got dropped and

> others have
> changed the object they are called on (from
> wxAuiTabCtrl/wxAuiTabContainer to wxAuiNotebook) as this may break
> existing applications (my included).
>
> Paul.

[Malcolm MacLeod]

Ideally a bug report on the github branch would be nice.

However, can you possibly provide more details? A testcase? Or at least
more information on the problem?

Is it a specific windows that vanishes every time? Is there something
different about this window? Is it floating, docked, part of a
notebook?

[Paul K]

Hi Malcolm,

> The problem remains as before that you have given some very vague 
> information based on a custom binding of yours, and have acknowledged 
> yourself that it is quite possible your binding does things that 
> involve using undocumented parts of AUI in ways that they were never 
> intended for.

I don't want to sound defensive, but this is not the case. This is not my binding; we are talking about wxlua that has been in use for 10+ years without major issues working with various versions of wxwdigets; I'm not the author or maintainer of it.

What I did mention was that I updated the code to accommodate the changes from wxAuiTabCtrl to wxAuiTabContainer as they are not in the "official" version, but it should have no impact on most of the issues I noted.

> Otherwise I really don't know what can be done.. It is not possible to 
> handle every single fringe misuse of non public parts of the previous 
> API especially if the people doing so are not willing to cooperate. 

This is not the case either. I can't "misuse non public parts" simply because wxlua doesn't provide me with ANY access to non-public API. In fact, I'm in a worse position than C++ developers as you can inherit from a class in wxwidgets and get access to protected methods and I can't; I can only rely on "public" methods.

As the result, any "fringe misuse" is simply not possible in my case.

As to the willingness to cooperate, I thought I provided detailed suggestions (https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/R2H3AnXgUlgJ, https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/7L_3hWdPvkcJ), which didn't get much response, fixes (https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/RjGDwWdJTEsJ) that were incorporated (thanks to Nathan and Laurent!), all the information I had as the results of my testing on Windows and OSX (https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/mMcUXeBAn6IJ) and offered to provide all the code and compiled binaries with debug information for my application (https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ). if it all comes down to opening a ticket on github, that's fine, but previously these changes/issues were discussed on this maillist.

> In the meantime the 99% of people who use the public parts of AUI and 
> don't rely on the undocumented parts must continue to sit with AUI in a 
> terrible state because all progress remains blocked.

I wouldn't be spending time compiling and testing these changes if I wasn't interested in the upgrade. Having said that, I think with all the internal refactoring I'd still expect the public API to be consistent with what's there now (barring the switch from wxAuiTabCtrl to wxAuiTabContainer). Right now many of the events in the upgrade branch are generated differently and with different objects from the current events, which is likely to break some applications. When the app is limited to only using public API calls (as in my case), some of the functionality may be lost (as I described earlier: https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/7L_3hWdPvkcJ).

I think the application I'm working on provides a good test case for several reasons:

1. It uses many wxAUI components (wxAuiNotebook, wxAuiManager, wxAuiToolbar) in various ways (saving/loading perspectives, modifying default art providers, using multiple panes with multi-tab notebooks, and so on), which allows to test for conditions that may not be seen in the default configuration.

2. It only uses public API calls.

3. It's available on Windows/Linux/OSX and provides build scripts that generate all required binaries from the source code (with the exception of changes needed for the upgrade branch).

Paul.

[Malcolm MacLeod]

> I don't want to sound defensive, but this is not the case. This is
> not my binding; we are talking about wxlua that has been in use for
> 10+ years without major issues working with various versions of
> wxwdigets; I'm not the author or maintainer of it.
> What I did mention was that I updated the code to accommodate the
> changes from wxAuiTabCtrl to wxAuiTabContainer as they are not in the
> "official" version, but it should have no impact on most of the
> issues I noted.

wxlua is a fringe case, I mean for starters it isn't the official
library it is a 3rd party binding of the official library, I am willing
to stand corrected but I doubt it has an overly large user base, the
amount of people on top of that who use AUI must be vanishingly small.
This is the very definition of small.

On top of this from what I understand, you are using a modified version
of wxlua because the official one would not compile, I do not have
access to this modified version because you have not made it available.
How can I even begin to look at issues that are only being seen by a
single wxlua user who will neither make the modified binding or the
code he is using available? Nor even a small test case of some kind?

Don't get me wrong, I think we should make this work as far as possible
for everybody, but when the only person complaining about various
things is using a third party binding, and we hear nothing from him or
the author of that binding on any of our bug reports, it starts to
become a big ridiculous.

In previous discussions you said you would participate on the github
bug tickets, we are still waiting. You said you would put up a binary
where we could see a visual demonstration of the issues, I'm also still
waiting.

> > Otherwise I really don't know what can be done.. It is not possible
> to
> > handle every single fringe misuse of non public parts of the
> previous
> > API especially if the people doing so are not willing to cooperate.
> This is not the case either. I can't "misuse non public parts" simply
> because wxlua doesn't provide me with ANY access to non-public API.
> In fact, I'm in a worse position than C++ developers as you can
> inherit from a class in wxwidgets and get access to protected methods
> and I can't; I can only rely on "public" methods.
> As the result, any "fringe misuse" is simply not possible in my case.

You misunderstand what is meant by public.

The original AUI code exposed in its public C++ API a lot of internals
that were not necessarily meant to be tinkered with, these internals
were *undocumented* - in the C++ world it is (unfortunately) relatively
common to do this, by leaving it undocumented it is meant to indicate
to a user that they should mess with these parts of the code *at their
own risk* and that anything they do with it *cannot* be guaranteed to
work forever.

When I say "non public" this is what I am talking about and not
literally which parts are exported as public/private in the headers.

We of course want to maintain backwards compatibility - even for people
using non public parts as far as is practically possible - to the
extent that we have added various backwards compatible methods to help
you

>
> As to the willingness to cooperate, I thought I provided detailed
> suggestions (
> https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/R2H3AnXgUlgJ,
> https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/7L_3hWdPvkcJ),
> which didn't get much response, fixes (

The first probably got lost in the noise, if you had taken the 2
seconds to submit a bug report I'm sure it probably would have been
addressed by now.
Though it is probably not as simple a decision as you seem to think.
You have also not said *why* you need the event to return these
internals, if you include that in the bug report we will be in a much
better position to assist you.

At this point I must *insist* on a bug report from you - my time is
*extremely* limited I should not even be spending it on AUI at all, and
I start to wonder why I convince myself to continue trying here.
I cannot and will not spend my time piecing together various fragmented
mailing list threads of yours, and figuring which parts of them
are/aren't still valid - especially given that many of them may be
specific to your code base.
If you can't make the token effort of at least submitting bug reports
then I'm not willing to make any further effort from my side.

The second one you have had no response because *we can't reproduce it*
and it is entirely possible that its due to *your* changes in wxlua
that you refuse to show us.
A fair amount of time was spent by Laurent trying to reproduce it and
nothing ever came from it. So again the onus is on you to make enough
effort here to actually give us something to work with. (And a bug
report)

> https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/RjGDwWdJTEsJ) that
> were incorporated (thanks to Nathan and Laurent!), all the
> information I had as the results of my testing on Windows and OSX (
> https://groups.google.com/d/msg/wx-dev/RCLXWP5rRzg/mMcUXeBAn6IJ) and
> offered to provide all the code and compiled binaries with debug
> information for my application (

Still waiting.

> https://groups.google.com/d/msg/wx-dev/P_PQptLUdKU/fnnOocd09ooJ). if
> it all comes down to opening a ticket on github, that's fine, but
> previously these changes/issues were discussed on this maillist.

Open bug reports.

> I think the application I'm working on provides a good test case for
> several reasons:
>
> 1. It uses many wxAUI components (wxAuiNotebook, wxAuiManager,
> wxAuiToolbar) in various ways (saving/loading perspectives, modifying
> default art providers, using multiple panes with multi-tab notebooks,
> and so on), which allows to test for conditions that may not be seen
> in the default configuration.

Great.

> 2. It only uses public API calls.

Not entirely true as explained above, but still not a problem, except
we are not getting full details on what it is you are dong in some
cases.

> 3. It's available on Windows/Linux/OSX and provides build scripts
> that generate all required binaries from the source code (with the
> exception of changes needed for the upgrade branch).

Also good. Although without access to the code and with a lack of bug
reports or details on the bugs not as good.

- Malcolm

[Carsten Fuchs]

Hi Malcolm,

many thanks for your reply!

Am 2015-08-12 um 10:41 schrieb Malcolm MacLeod:
> Ideally a bug report on the github branch would be nice.

Ok, done:
https://github.com/nhold/wxWidgets/issues/104

> However, can you possibly provide more details? A testcase? Or at least
> more information on the problem?
>
> Is it a specific windows that vanishes every time? Is there something
> different about this window? Is it floating, docked, part of a
> notebook?

As mentioned in the issue, I'll try to reproduce this in a minimal wxAUI
sample setup.

Best regards,
Carsten

[Malcolm MacLeod]

> > Ideally a bug report on the github branch would be nice.
> Ok, done:
> https://github.com/nhold/wxWidgets/issues/104

Thanks for narrowing it down, it involves having multiple panes without
names which isn't really a great idea, but anyway its definitely a
regression as previously this worked right, I've proposed a fix for
this.

- Malcolm

[Carsten Fuchs]

Hi all,

I possibly found another problem:

It seems that "destroy on close" is now the default, whereas in previous
versions, not destroying on close was the default.

I briefly looked at the code, and it seems that this is because the
wxAuiPaneInfo constructor calls DefaultPane(), which runs

this->state |= optionTopDockable | ... | optionDestroyOnClose;

Is this an intentional change?

Best regards,
Carsten

[Malcolm MacLeod]

No I don't think its intentional, or at least I can't think offhand why
it would be, I'll have a closer look and see what I can find.

[Malcolm MacLeod]

I think this stems from wxAuiNotebook.

Unless I am mistaken, the original wxAuiNotebook deletes pages when it
closes them, this is hardcoded and not controllable with a flag.
While as you correctly state the original wxAuiFrameManager has this
flag 'optionDestroyOnClose' but does *not* set it by default.

So the two have different defaults.
wxAuiNotebook - delete.
wxAuiFrameManager - don't delete.

As you probably know 'wxAuiNotebook' was reimplemented in such a way
that it now uses 'wxAuiFrameManager' to do most the work instead of its
own custom code, I imagine at some point somebody (possibly myself -
doesn't really matter who I guess) noticed that 'wxAuiNotebook' was no
longer backwards compatible and made this change - which now means that
'wxAuiFrameManager' is not backwards compatible.


I'm not 100% sure how best to solve this in a way that is backwards
compatible for both, we could set the flag always when inserting panes
into 'wxAuiNotebook' - but this would frustrate anyone who wants to not
destroy panes on close with 'wxAuiNotebook'.

We could I guess add a new inverse flag 'optionDoNotDestroyOnClose' and
then for wxAuiNotebook only have destroy on close be the default if
'optionDestroyOnClose' is not present, however this makes things a bit
confusing, the documentation will have to explain these flags users
will have to remember the different behavior between the two classes -
and could give erratic behavior in advanced interfaces where
intermanger drags are allowed - if someone were to drag a pane frame a
notebook to a normal manager suddenly the deletion behavior for that
pane changes :(
So this is not 100% ideal in terms of a 'nice, user friendly' API going
forward.

We could also break backwards compatibility here - perhaps for
'wxAuiNotebook' - i.e. don't have deletion be the default behavior
(thats probably less dangerous then deleting things that people weren't
expecting to be deleted) though not without its perils, e.g. what if
theres an important resource held open by the frame like a file handle
that now doesn't close?
Also backwards compatibility seems to be the gospel around here so I'm
hesitant to say that I want to break it...


In summary, I'm not actually sure what to do about this. Any further
thoughts on the above appreciated?

- Malcolm MacLeod

[Carsten Fuchs]

Hi Malcolm,

thanks for providing these details. I hoped that also others would chime in, but so far,
unfortunately none.

Personally, I don't mind if backwards-compatibility gets broken -- as long as it is
clearly documented and/or communicated at compile time (warning or error).

However, *if* a breaking change was made, I was wondering if the API regarding "destroy
on close" could also be improved at that opportunity.

For example, the optionDestroyOnClose could be entirely removed, along with its related
get/set methods. Instead, closing could be handled as with any other windows in
wxWidgets, as described at http://docs.wxwidgets.org/3.0/overview_windowdeletion.html
That is, if a pane's wxWindow vetoes the closing, the wxAuiPane would only be hidden and
the window be kept, otherwise destroyed. Any of these two options might be the new,
common default behavior. The advantage of this change is that it handles a pane's window
exactly like a wxDialog or wxFrame, removing the need for the special-case
destroy-on-close treatment that is now in place.

If this is not an option -- I've never used wxAuiNotebook unfortunately, and thus would
prefer if the default behavior for wxAuiNotebook changed rather than wxAuiFrameManager. ;-)

Best regards,
Carsten

[Malcolm MacLeod]

Thanks, I too was hoping for others to chime in :)

> thanks for providing these details. I hoped that also others would
> chime in, but so far,
> unfortunately none.
>
> Personally, I don't mind if backwards-compatibility gets broken -- as
> long as it is
> clearly documented and/or communicated at compile time (warning or
> error).

Sadly I'm not sure if there is possibly a way to do this that could
warn or error at compile time, due to it being runtime options... I'm
guessing not.

I remain unsure what to say, I can't read minds so I don't even want to

try and assume what it is that the wx developers think is the 'right'
de
cision here. To me it is one of those cases where no decision is
entirely right and it is pretty subjective which is least bad.
Ultimatel
y I hope for this branch to eventually be merged, and if I
make some or
other decision here on mt own it is quite likely become yet another
sticking point that could delay the merge and end up being a mess to
change.

So ultimately I think we are going to need some preemptive direction
from the person making the decisions (regarding the main wx) here -
i.e. vadz, or at least one of the other wx developers, or failing that
at least a consensus from more of the people who are interested in this
branch.

Any input from them or others appreciated :)

> However, *if* a breaking change was made, I was wondering if the API
> regarding "destroy
> on close" could also be improved at that opportunity.
>
> For example, the optionDestroyOnClose could be entirely removed,
> along with its related
> get/set methods. Instead, closing could be handled as with any other
> windows in
> wxWidgets, as described at
> http://docs.wxwidgets.org/3.0/overview_windowdeletion.html
> That is, if a pane's wxWindow vetoes the closing, the wxAuiPane would
> only be hidden and
> the window be kept, otherwise destroyed. Any of these two options
> might be the new,
> common default behavior. The advantage of this change is that it
> handles a pane's window
> exactly like a wxDialog or wxFrame, removing the need for the special
> -case
> destroy-on-close treatment that is now in place.
>
> If this is not an option -- I've never used wxAuiNotebook
> unfortunately, and thus would
> prefer if the default behavior for wxAuiNotebook changed rather than
> wxAuiFrameManager. ;-)

Yes thats a possibility to look into I guess.. Not sure i'm so keen on
it myself but again this is ideally something that should be decided by
or with input from others.

- Malcolm

[Vadim Zeitlin]

On Sat, 15 Aug 2015 18:58:23 +0200 Malcolm MacLeod wrote:

MM> As you probably know 'wxAuiNotebook' was reimplemented in such a way
MM> that it now uses 'wxAuiFrameManager' to do most the work instead of its
MM> own custom code,

Sorry, I don't know this code at all, so maybe there is an obvious reason
it's impossible, but why can't we just set optionDestroyOnClose when adding
panes using wxAuiNotebook method(s)?

MM> I'm not 100% sure how best to solve this in a way that is backwards
MM> compatible for both, we could set the flag always when inserting panes
MM> into 'wxAuiNotebook' - but this would frustrate anyone who wants to not
MM> destroy panes on close with 'wxAuiNotebook'.

This would be incomparably better than getting crashes because of double
deletion when rebuilding an application which worked with wxAUI 3.0 with
3.1.

MM> We could I guess add a new inverse flag 'optionDoNotDestroyOnClose' and
MM> then for wxAuiNotebook only have destroy on close be the default if
MM> 'optionDestroyOnClose' is not present, however this makes things a bit
MM> confusing, the documentation will have to explain these flags users
MM> will have to remember the different behavior between the two classes -
MM> and could give erratic behavior in advanced interfaces where
MM> intermanger drags are allowed - if someone were to drag a pane frame a
MM> notebook to a normal manager suddenly the deletion behavior for that
MM> pane changes :(

I think the deletion flag should be something associated with the pane
(isn't it already?), not the manager. I.e. if it's created with
"optionDoNotDestroyOnClose" it will never be destroyed by wxAUI, wherever
it's dragged later.

However I agree that having both optionDestroyOnClose and
optionDoNotDestroyOnClose is confusing and I'd prefer to avoid introducing
the latter. Notice that while I also agree that having different defaults
for optionDestroyOnClose for the normal panes and the notebook ones is
confusing as well, this seems unavoidable.

MM> Also backwards compatibility seems to be the gospel around here so I'm
MM> hesitant to say that I want to break it...

Philosophical debates aside, silently breaking (and yes, memory leaks
count as breakage too, not only crashes) previously working code is indeed
unacceptable. The only breakage that we can consider is at _compilation_,
not _run_ time.

MM> In summary, I'm not actually sure what to do about this. Any further
MM> thoughts on the above appreciated?

As the first step, we need to make sure that normal panes are not
destroyed if optionDestroyOnClose is not specified while still destroying
those added to wxAuiNotebook. Maybe this is enough and nobody actually
wants to have non-destroy-on-close notebook pages. But this seems unlikely,
so we need to provide a way to allow this as well. I like Carsten's idea of
adding wxAuiManagerEvent::DontDestroy() which could be used in
wxEVT_AUI_PANE_CLOSE handler to prevent the pane from being destroyed.

Regards,
VZ

[Malcolm MacLeod]

> MM> As you probably know 'wxAuiNotebook' was reimplemented in such a
> way
> MM> that it now uses 'wxAuiFrameManager' to do most the work instead
> of its
> MM> own custom code,
>
> Sorry, I don't know this code at all, so maybe there is an obvious
> reason
> it's impossible, but why can't we just set optionDestroyOnClose when
> adding
> panes using wxAuiNotebook method(s)?

The reason this isn't ideal is that it removes the ability of people to
turn the behaviour of destroying panes off for wxAuiNotebook.
If I create a pane, ensure 'optionDestroyOnClose' is not set on it and
then add the pane to a wxAuiNotebook its a reasonable expectation that
it doesn't suddenly get destroyed on close.
Further if I have the code remove a pane from a wxAuiFrameManager and
add it to a wxAuiNotebook, and then at some point do the reverse, its
also a reasonable expectation that the closing behaviour of the pane
hasn't magically changed behind the scenes.
We could of course document this, but at the end of the day it leaves
people vunerable to a potential problem, so basically its not great API
design.

This doesn't mean we can't do it of course - just that it isn't ideal.

Yes the flag is associated with the pane, but I am talking above about
the behaviour when the flag is *not* present.
i.e. If we have a pane with "optionDoNotDestroyOnClose" - when the flag
*is* present obviously it is never destroyed anywhere.
What I am getting at is that we could in theory 'play' with the
behaviour of what happens when it *isn't* present so that its absense
does not always imply the opposite - i.e. if no flag is set it could be
interpreted differently by wxAuiNotebook (do destroy on close) and
wxAuiFrameManager (Still don't destroy on close).

However (apart from other possible objections) this falls apart because
a pane can move between a wxAuiNotebook and a wxAuiFrameManager in some
situations, and having pane deletion affected in such an instance is
not likely a good idea.

- Malcolm

[Malcolm MacLeod]

Anyway, I have a proposed 'fix' at
https://github.com/nhold/wxWidgets/pull/107
If you could try it out when convenient and let me know if it works for
you it would be appreciated.

- Malcolm

[Malcolm MacLeod]

I would just like to note that we are sitting with an almost empty
issue list at https://github.com/nhold/wxWidgets/issues?q=is%3Aopen+is%
3Aissue+milestone%3Aformerge

If interested parties could try to test their respective codebase's and
file issues now rather than later it would be appreciated. I would very
much like to have this merge over with in the near future.

- Malcolm


> Just to hijack a bit here based on the endorsement of nhold branch by
> Michael.
>
> Is there something in particular stopping a merge of the AUI code
> base
> at this point?
>
> While unfortunately I've personally been rather absent for the last
> year, there seems to still be activity and contributions on the fork
> from others, people seem to be generally happy with it, the issue
> list
> has a lot of issues but these are almost all feature enhancements
> and/or
> things that are wrong with the mainline AUI as well.
>
> In short there seems enough active support for it, that I don't think
> concerns of the code being 'dumped' on wx are valid.
>
>
> Before all these features start getting implemented and the code base
> diverges even further from mainstream, would now not be a good time
> to
> go ahead with the merge?
> This would finally allow people to start working on other
> improvements
> (like better drop hints etc.) that a lot have been itching for etc.
> as
> well.
>
> I suspect there is a lot of AUI development that people would like to
> do
> but are not, because they are a bit reserved about whether this merge
> is
> ever going to take place or not.
>
> My availability is currently a bit better, so if we do go ahead with
> the
> merge I can make myself available for any high priority issues that
> crop
> up.
>
> Regards,
> Malcolm MacLeod
>
>
>
>
>
> > Yes, the first ticket applies. I didn't see it before when I
> > looked. I
> > don't think their suggestion would work in my case but I had no
> > idea
> > that holding a key could do that. I added my own ideas.
> >
> > The second ticket, I'm not able to reproduce the problem using the
> > nhold code so I assume it has or will be fixed if and when that
> > stream
> > gets merged in. I'm quite happy with the stability of the nhold
> > series
> > of code. It has yet to let me down and I've been testing and
> > application quite extensively for at least 10h solid. I'll be
> > spending
> > most of the day today still working with it. As I get more time in
> > on
> > this thing I think I'd like to spend a day or so and write up some
> > proper documentation - something aui has been a little sparse on
> > from
> > the beginning.
> >
> > -Michael
> >
> > On Friday, January 2, 2015 3:46:09 AM UTC-5, Kinaou Herve wrote:
> > Hello,
> >
> >
> > Look at this trac which talk about a similar issue and with
> > some ideas to resolve it:
> > http://trac.wxwidgets.org/ticket/15906
> >
> >
> > And this one which seems to say that the gripper issue is
> > (almost) resolved:
> > http://trac.wxwidgets.org/ticket/13177
> >
> >
> >
> > Regards,
> > KH
> >
> >
> > Le vendredi 2 janvier 2015 01:42:32 UTC+1, Michael Richards
> > a
> > écrit :
> > Hi,
> >
> > I've been using the nhold branch in GIT so I'm not
> > sure how to mention bugs and problems.
> >
> > If I should create a trac ticket I can.
> >
> > Here is the problem. If you have a pane that is
> > both
> > center dockable and floatable you can't manage to
> > manipulate it as a floating window or the
> > windowmanager will always try to dock it.
> >
> > I believe QT overcomes this problem by displaying
> > an
> > icon indicating where to dock it and you have to
> > actually dock it on that icon to have it dock.
> > Another application I use forces you to grab the
> > window by the gripper not the titlebar. I think
> > this
> > would be a very worthwhile change, allow a flag
> > that
> > allows docking only to occur if you grabbed a
> > window
> > by its gripper (assuming it has one).
> >
> > Barring that, is there any realistic way to do this
> > using the existing interface?
> >
> > thanks
> >
> > -Michael

[Teodor Petrov]

On 08/19/2015 08:53 AM, Malcolm MacLeod wrote:
> I would just like to note that we are sitting with an almost empty
> issue list at https://github.com/nhold/wxWidgets/issues?q=is%3Aopen+is%
> 3Aissue+milestone%3Aformerge
>
> If interested parties could try to test their respective codebase's and
> file issues now rather than later it would be appreciated. I would very
> much like to have this merge over with in the near future.
>
> - Malcolm
>

Hi,

Is there any macro which can be used to detect that the wx lib which
is used has the new wxaui stuff in it?

I need this in order to make our code base support the new and the
old wxaui versions. We're still supporting wx28.

Best regards,
Teodor

[Malcolm MacLeod]

I don't think there is anything official currently, you could maybe
check if 'EVT_AUI_PANE_DOCK_OVER' is defined, but it isn't really
ideal.

I will add a wxHAS_AUI_DYNAMIC_NOTEBOOK define that you can use.

- Malcolm

[Teodor Petrov]

On 08/19/2015 10:29 AM, Malcolm MacLeod wrote:

> I will add a wxHAS_AUI_DYNAMIC_NOTEBOOK define that you can use.
>

Thank you.

[Tom Kulaga]

Hi,

I've been following the thread for a little bit but haven't posted. I'm wanting to use aui in my codebase so I thought I'd contribute.



I'm running the latest nHold branch and I've noticed that when I dock in a panel, running the dynamic aui sample,the whole frame flickers monetarily.not sure if that is an issue that needs to be looked at?

I've also noticed that there are times when I undock a panel,then hover above a tab portion to tabify that panel, the hint rectangle at times draws in the wrong spot.

This is in Windows 7 with Vs2015.
Regards
Tom

[Nathan Hold]

Hi,

Does this issue look similar to what you are experiencing? 

Cheers, Nathan

[Vadim Zeitlin]

On Tue, 18 Aug 2015 20:46:59 +0200 Malcolm MacLeod wrote:

MM> The reason this isn't ideal is that it removes the ability of people to
MM> turn the behaviour of destroying panes off for wxAuiNotebook.

If it's a real concern, I still think allowing to prevent destruction from
happening when handling wxEVT_AUI_PANE_CLOSE is a better idea than adding
more flags.

MM> If I create a pane, ensure 'optionDestroyOnClose' is not set on it and
MM> then add the pane to a wxAuiNotebook its a reasonable expectation that
MM> it doesn't suddenly get destroyed on close.

It's reasonable but we'll have to clearly document that this is not what
happens because of backwards compatibility. And, again, eventually we'll
get rid of this inconsistency because we'll use a different mechanism for
preventing the pane destruction on close (or allowing it, depending on what
will be the default, I don't know what is more appropriate here).

MM> Further if I have the code remove a pane from a wxAuiFrameManager and
MM> add it to a wxAuiNotebook, and then at some point do the reverse, its
MM> also a reasonable expectation that the closing behaviour of the pane
MM> hasn't magically changed behind the scenes.

It shouldn't, the behaviour should only depend on the manager to which the
pane had been added initially.

MM> We could of course document this, but at the end of the day it leaves
MM> people vunerable to a potential problem, so basically its not great API
MM> design.
MM>
MM> This doesn't mean we can't do it of course - just that it isn't ideal.

No, but it's not too bad and I don't see anything better.

MM> Yes the flag is associated with the pane, but I am talking above about
MM> the behaviour when the flag is not present. i.e. If we have a pane with
MM> "optionDoNotDestroyOnClose" - when the flag is present obviously it is
MM> never destroyed anywhere. What I am getting at is that we could in
MM> theory 'play' with the behaviour of what happens when it isn't present
MM> so that its absense does not always imply the opposite - i.e. if no
MM> flag is set it could be interpreted differently by wxAuiNotebook (do
MM> destroy on close) and wxAuiFrameManager (Still don't destroy on close).

Yes, this is the same thing as I propose, isn't it?

MM> However (apart from other possible objections) this falls apart because
MM> a pane can move between a wxAuiNotebook and a wxAuiFrameManager in some
MM> situations, and having pane deletion affected in such an instance is
MM> not likely a good idea.

Just to be perfectly clear: my proposal is to determine the "destroy on
close" behaviour from the initial container of the pane. Once it's set, it
is never going to change even if the pane is moved around. This is good
enough for compatibility purposes because the panes couldn't be moved
out from the notebooks at all before and is much less surprising than the
alternative.

Regards,
VZ

[Malcolm MacLeod]

> > I will add a wxHAS_AUI_DYNAMIC_NOTEBOOK define that you can use.
> >
>
> Thank you.

This has now been added in the latest pull request.

[Malcolm MacLeod]

> Just to be perfectly clear: my proposal is to determine the "destroy
> on
> close" behaviour from the initial container of the pane. Once it's
> set, it
> is never going to change even if the pane is moved around. This is
> good
> enough for compatibility purposes because the panes couldn't be moved
> out from the notebooks at all before and is much less surprising than
> the
> alternative.

Yes, this is basically what has been done now.

- Malcolm

[Tom Kulaga]

Hi Nathan,

Unfortunately not, I see the hint being drawn in a different area not exactly under the panel. I'll try and get a screen record and post it with some (hopefully ) steps to reproduce.

I've also seen the panel itself flicker on the other side of the main frame between the moment I release the panel to dock and it docking. I'll try and get a record of that and post.

I saw u had some fresh commits, I'll try them and see if I can get these things appearing.

-tom

[Malcolm MacLeod]

> I've been following the thread for a little bit but haven't posted.
> I'm wanting to use aui in my codebase so I thought I'd contribute.
>
> I'm running the latest nHold branch and I've noticed that when I dock
> in a panel, running the dynamic aui sample,the whole frame flickers
> monetarily.not sure if that is an issue that needs to be looked at?

To an extent yes, I mean all issues should be looked at, and any bug
reports with additional info etc. are great, if there is something that
can be easily fixed then we should fix it.

However the question is really how badly is it flickering? Is this
really something to hold up merging the code base for?
Or is it minor enough that we can look at it *after* we have merged the
code base.

I can definitely get the original AUI also to flicker in certain
circumstances, so there is that to consider as well.

> I've also noticed that there are times when I undock a panel,then
> hover above a tab portion to tabify that panel, the hint rectangle at
> times draws in the wrong spot.

There are I think a few known instances where the hinting goes wrong
sometimes, I think it is acknowledged by most of us at this point that
the entire hint system needs a bit of a cleanup and reworking - but
nobody really wants to do that pre-merge.

If you can provide a bit more info, a video or something of where it is
going wrong for you I can have a look and see if its something that can
be fixed now already.

- Malcolm

[Tom Kulaga]

Yup will definitely try and get some concrete vidoes. I thought I'd intoesuce myself.

In the commits I saw that the new dynamic macro says 'since 3.1'. Is the metge happening for the 3.1 release ?

Thanks
Tom

[Malcolm MacLeod]

> Yup will definitely try and get some concrete vidoes. I thought I'd
> intoesuce myself.

Well welcome ;)

> In the commits I saw that the new dynamic macro says 'since 3.1'. Is
> the metge happening for the 3.1 release ?

It is the current working assumption of the branch (i.e. we have to put
something in places like that) - if it doesn't happen before 3.1
somebody will just change all of that to 3.2 or whatever.

I don't know what the 3.1 time frame looks like at this point and/or
what major issues may still come up if/when more people test and chime
in so I guess we will have to see, final decision is in the hands of
vadz.

- Malcolm

[Malcolm MacLeod]

Hi Jens,

Any chance you could have a peek at
https://github.com/nhold/wxWidgets/issues/110 as you did quite a bit of
the artwork stuff it would be best to get your comment there.

Thanks!

- Malcolm

> >
> > MR> I can work with the example app to validate that it continues
> > to
> > work.
> >
> > This would be most welcome. Testing CodeBlocks would be very much
> > so
> > too.
> I can (and for sure will do) this tests.
> And the update will for sure break parts of Code::Blocks, because we
> use an own class derived from wxAuiNotebook. Not everything does
> work,
> if I tried the last time (if I remember correctly), but C::B is still
> not fully compatible with wx3 and is build against 2.8.12 on almost
> all
> platforms (except my debian nightlies).
> I will update my wxAui-repo and test it as soon as possible (my last
> workday for the next three weeks is tomorrow, so I should find some
> time).
> > And I think there are other wx IDEs (CodeLite?) using AUI as well.
> > If
> > no
> > regressions are found in at a couple of big applications using AUI,
> > it
> > would help my confidence in the new code compatibility
> > tremendously.
> >
> > MR> The other point is that few people are actually using AUI.
> > Possibly because
> > MR> of documentation and lack of how-to type info. If there are
> > going
> > to be any
> > MR> API additions or deprecations it would be ideal to do so sooner
> > rather than
> > MR> later. Once these things are settled I can definitely
> > contribute
> > to the
> > MR> docs since I have enough hundreds of hours to understand it at
> > a
> > reasonable
> > MR> level.
> >
> > This would, again, be great, of course. But I'm intentionally
> > setting the
> > bar as low as possible for the merge: I know that current AUI docs
> > are
> > pretty bad, but the only thing I'd like to ensure is that they
> > don't
> > get
> > even worse, e.g. refer to things that have changed in the new code.
> >
> > Regards,
> > VZ
> --
>
> Jens Lody
>
> Code::Blocks core developer
> http://www.codeblocks.org/
>
> (Un-)official debian-repository for Code::Blocks:
> http://apt.jenslody.de/
>
> (Un-)official Fedora- and RedHat/CentOS-repository for Code::Blocks
> and Fedora-repository of my gnome-shell-extensions:
> http://rpm.jenslody.de/
>
> Developer of OpenWeather and Panel OSD gnome-shell extensions:
> https://extensions.gnome.org/extension/750/openweather/
> https://extensions.gnome.org/extension/708/panel-osd/
>
> |\ _,,,---,,_
> /,`.-'`' -. ;-;;,_
> <|,4- ) )-,_..;\ ( `'-'
> '---''(_/--' `-'\_)
>
>

[Carsten Fuchs]

Hi Malcolm,

Am 2015-08-19 um 07:49 schrieb Malcolm MacLeod:
> Anyway, I have a proposed 'fix' at
> https://github.com/nhold/wxWidgets/pull/107

Thanks, that works very well!

By the way, the notes that you added to the documentation make it sound
as if it were the wxAuiManager and the wxAuiNotebook that are making the
decision to destroy a pane. For both classes, I would like to suggest
something like this instead:

-------
A new pane that is initially added to the wxAuiManager via
wxAuiManager::AddPane() or wxAuiManager::InsertPane() will by default be
hidden when its close button is clicked. The default can be changed by
using the wxAuiPaneInfo::DestroyOnClose() option.

A new pane that is initially added to the wxAuiNotebook via
wxAuiNotebook::AddPage() or wxAuiNotebook::InsertPage() will by default
be destroyed when its close button is clicked.

The so determined close behaviour of a pane is preserved even if the
pane is later moved from the wxAuiManager into a wxAuiNotebook, or vice
versa.
-------


And an unrelated question, out of curiosity: Why are sometimes "test"
instances of wxAuiPaneInfos created? E.g. in
wxAuiPaneInfo::DefaultPane(), why not just write
wxCHECK_MSG(IsValid(), *this, "...");
?


Best regards,
Carsten

[Tom Kulaga]

Hi Guys,

I've got together an (ugly) but functional exmaple of one of the bugs i mentioned

code below in a single CPP file

http://codepad.org/3bOhBSbk

Procedure for repeat of the wrong hint location:

1) as soon as it loads up, itll be a smaller size, but once you click, it'll expand to a larger size.

2) Grab the "Floatable 1" window from the bottom left

3) Try to dock it onto the "Moveable" window in the top left.

4) The hint will be drawn incorrectly over the toolbars, but still dock in the right place.

5) If you then undock it, and try to redock it again in the same place, it'll draw the hint correctly.

Also when moving and dock them around, I see a flicker of the entire frame.

thanks

Tom

[Paul K]

Hi Malcolm,

I'd like to start by clarifying one thing, in case it wasn't clearly expressed in my earlier messages: I'm excited by these changes and would like to see them working and merged into the master branch. I've been waiting for something like "Movable" for the long time and many of the changes make the code simpler and more straightforward to use and maintain. Having said that, I think there has to be some bug-parity with the current branch, so the new one can be used almost as the "drop in" replacement for the current version.

How can I even begin to look at issues that are only being seen by a
single wxlua user who will neither make the modified binding or the
code he is using available? Nor even a small test case of some kind?

I've reproduced most of the issue without using wxlua, so there is less dependency on it now. There are still two issues I'm working on reproducing, which may still require wxlua usage.

 

In previous discussions you said you would participate on the github
bug tickets, we are still waiting. You said you would put up a binary
where we could see a visual demonstration of the issues, I'm also still
waiting. 

 

The diff with the few changes I made to wxlua to make it work for the dynamic branch is now available here: https://gist.github.com/pkulchenko/5d145f48018221acc0ed

The binary compiled using that diff with the current dynamic branch (commit a7976ec) is available here: https://download.zerobrane.com/wx-aui-dynamic-win32-a7976ec.zip

 

Open bug reports.

As you've seen, I've opened a number of tickets on github: https://github.com/nhold/wxWidgets/issues

Paul

[Malcolm MacLeod]

Thanks,

I will try work through the reports when I can free up some time, or of
course (as always) if somebody else wants to take a look and/or submit
patches I won't complain.

The below isn't to do with your reports per se - which I agree mostly
are legitimate concerns - but just a general comment.

In terms of 'bug parity' I do agree, though one must also remember (and
it is something that tends to be forgotten with all the focus being on
what is *wrong* with the branch) that there are potentially cases where
the master branch has bugs that have being fixed in the fork..

Also (as we saw in a recent bug a fixed) many of these issues get
introduced when merging other changes from the master branch - so it is
a constant game of catch up.
Further we are seeing lots of bug reports for things that are *also*
broken in the master branch and just figuring out which these are is a
constant time cost, though not completely wasted as this should lead to
an improved master AUI in the long term.
So there is a lot of extra time cost to having this in a fork, time
that could rather be spent improving wx for everybody with everyone
working to improve a single codebase.

While something like a hint drawing incorrectly may seem like a big
thing (and I don't want to downplay it) it's not such a train smash
that it can't (in theory) be fixed after a merge - and certainly I
would imagine there would be a period post-merge before any actual wx
releases are done so likely it would be fixed pre-release anyway, that
it gets merged with that bug doesn't mean that the bug will ever be
seen in a release.

Anyway I'm not saying we shouldn't try fix most these things post-merge
but rather just that we should remain cognisant of the fact that no
code is bug free - and certainly not AUI in wx master branch - so we
should not put the bar at a level that is too high to ever reach.

- Malcolm

[Vadim Zeitlin]

On Fri, 21 Aug 2015 13:34:48 +0200 Malcolm MacLeod wrote:

MM> In terms of 'bug parity' I do agree, though one must also remember (and
MM> it is something that tends to be forgotten with all the focus being on
MM> what is wrong with the branch) that there are potentially cases where
MM> the master branch has bugs that have being fixed in the fork..

Yes, but we can't just replace one set of bugs with another one as we're
not even sure if we advance in the right direction if we do this. There
really shouldn't be any regressions (of course I realize that there will
probably still be some because our testing is not exhaustive, but this
should at least be the goal).

MM> Also (as we saw in a recent bug a fixed) many of these issues get
MM> introduced when merging other changes from the master branch - so it is
MM> a constant game of catch up.

For a very long time (at least a year) I was postponing any patches to AUI
code because I didn't want to introduce more divergence between the version
in the trunk and the dynamic notebooks branch. As the merge kept being
postponed, I stopped doing this and started applying at least the obviously
correct patches. I'd be perfectly willing to freeze wxAUI again for any
reasonable (i.e. months, not years) amount of time again if this could
help.

MM> So there is a lot of extra time cost to having this in a fork, time
MM> that could rather be spent improving wx for everybody with everyone
MM> working to improve a single codebase.

This is clearly not ideal but I don't see what can be done about it. There
are too many changes (including many non critical ones) in the dynamic
notebook branch to really contemplate merging the 2 branches, the only way
to "merge" them is to replace the current version with the new one, so we
just can't apply the same patches to both branches, for example.

FWIW I still believe that it was a very bad idea to diverge that branch
from the mainline so much due to all these insignificant changes (I'm
thinking of all the renamings). But, again, I don't know what could be done
about it now.

MM> Anyway I'm not saying we shouldn't try fix most these things post-merge
MM> but rather just that we should remain cognisant of the fact that no
MM> code is bug free - and certainly not AUI in wx master branch - so we
MM> should not put the bar at a level that is too high to ever reach.

I really think that "no regressions" is as low as it can be. If this is
impossible to achieve, we'll just have to admit that we can't merge this
work into wx and that we'll have 2 versions of AUI: one bundled into wx and
another, not perfectly compatible one, distributed separately. This would
be unfortunate but continuing discussing this merge for literally years
without achieving it is not great neither.

Regards,
VZ