search

nhold / wxWidgets

Read-only mirror of the wxWidgets SVN repo (automatically updated). Report issues here: http://trac.wxwidgets.org/
http://www.wxwidgets.org/
1 stars 3 forks source link

wxAuiFrameManger now defaults to destroying panes on close which is a departure from the original behaviour of not doing so #106

Closed mjmacleod closed 9 years ago

mjmacleod commented 9 years ago

Quoting from mailing list:

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

nhold commented 9 years ago

I think it's best to do the backwards compatibility thing, it's what vadz wants and he won't accept the PR unless we have done all possible to make it backwards compatible (Or documented it heavily). Better yet we should ask him what he wants (But I bet it would be "It would be better to be backwards compatible") . I think the first option is easiest and add documentation then we can push for breaking backwards compatibility and fixing up the API afterwards (Which I really want to do).

mjmacleod commented 9 years ago

Yes indeed, the mailing list discussion is ongoing.

And indeed the mantra is still "I have absolutely no idea how the API works and haven't bothered to even look at the code or properly understand the situation, and in fact know almost nothing about AUI in general, but backwards compatibility at all cost even if it means a shitty API" - no big surprise there. Anyway it is not worth worrying about the things I can't control so will just have to do it.

"we can push for breaking backwards compatibility and fixing up the API afterwards (Which I really want to do)." Good luck with that, I honestly believe you will be wasting your time as long as the current crowd and especially vadz remains in control of wx. The man is an absolute burden to any meaningful API improvements. It is like the entire project is still stuck in the 80s and has not realized that the rest of the world (even Microsoft) have moved on since then in terms of what is considered acceptable levels of backwards compat.

The big question then is how to remain backwards compat in the way that is the least damaging to the API in general. I'll have a closer look and try formulate a pull request.