wxAui dynamic notebook branch reintegration

[Laurent Poujoulat]

Hi Vadim,

we have made lately with Nathan Hold a lot of work on the wxAui dynamic
branch to make it (almost) backward compatible with the current wxAui
behaviour. We have no show stopper bug left. It would be nice to merge
it back in the main tree now, so everyone could test it and have a
single place to track issues; Could you check it and tell us what's
missing to do this ?

The main visible changes for the code using wxAui are:
- Deprecation of direct access to the wxAuiPaneInfo fields
- Renaming of the wxAuiPaneInfo methods to a more consistent Set<option
name> scheme. Previous methods are still there, but are deprecated.
- Perspectives save format has changed

The code is at:

https://github.com/nhold/wxWidgets

regards,
Laurent Poujoulat

[Vadim Zeitlin]

On Thu, 20 Mar 2014 09:38:12 +0100 Laurent Poujoulat wrote:

LP> we have made lately with Nathan Hold a lot of work on the wxAui dynamic
LP> branch to make it (almost) backward compatible with the current wxAui
LP> behaviour.

Great, thanks a lot!

LP> We have no show stopper bug left. It would be nice to merge
LP> it back in the main tree now, so everyone could test it and have a
LP> single place to track issues; Could you check it and tell us what's
LP> missing to do this ?

I won't have time to test it exhaustively, especially right now with all
the extra GSoC-related things going on. So I'd like to ask people with
applications using wxAUI to test it with this version and report their
findings here. It would be great to have at least a few (which is precisely
more than a couple) testers!

LP> The main visible changes for the code using wxAui are:
LP> - Deprecation of direct access to the wxAuiPaneInfo fields
LP> - Renaming of the wxAuiPaneInfo methods to a more consistent Set<option
LP> name> scheme. Previous methods are still there, but are deprecated.
LP> - Perspectives save format has changed

What happens when the application tries to load data in the existing
format?

Also, what are the new features? We need to document them somewhere.

LP> The code is at:
LP>
LP> https://github.com/nhold/wxWidgets

I'll have a look at the changes at the code level but, again, I won't have
time to do any kind of meaningful review, so the most important thing is to
test the new code as much as possible.

Thanks in advance for your help with this!
VZ

[Laurent Poujoulat]

Le 20/03/2014 14:34, Vadim Zeitlin a écrit :
> On Thu, 20 Mar 2014 09:38:12 +0100 Laurent Poujoulat wrote:
>
> LP> we have made lately with Nathan Hold a lot of work on the wxAui dynamic
> LP> branch to make it (almost) backward compatible with the current wxAui
> LP> behaviour.
>
> Great, thanks a lot!
>
> LP> We have no show stopper bug left. It would be nice to merge
> LP> it back in the main tree now, so everyone could test it and have a
> LP> single place to track issues; Could you check it and tell us what's
> LP> missing to do this ?
>
> I won't have time to test it exhaustively, especially right now with all
> the extra GSoC-related things going on. So I'd like to ask people with
> applications using wxAUI to test it with this version and report their
> findings here. It would be great to have at least a few (which is precisely
> more than a couple) testers!

I beg for that :) ! Any volunteers ? Issues can be reported on the
github repository until the branch is merged.

>
> LP> The main visible changes for the code using wxAui are:
> LP> - Deprecation of direct access to the wxAuiPaneInfo fields
> LP> - Renaming of the wxAuiPaneInfo methods to a more consistent Set<option
> LP> name> scheme. Previous methods are still there, but are deprecated.
> LP> - Perspectives save format has changed
>
> What happens when the application tries to load data in the existing
> format?

They should just start with a default layout because there is a new
format version indicator. I'll check anyway.

>
> Also, what are the new features? We need to document them somewhere.

The only actual new feature is the ability to freely stack panes one
onto another (even if not in a wxAuiNotebook) and to reliably save the
layout. When a pane may be stacked onto another, a new event
(wxEVT_AUI_PANE_DOCK_OVER) is triggered to accept or reject the stack
creation. If rejected, the pane docks as before. If accepted, the pane
is set "over" the previous one, creating a new notebook if needed. By
default, the event request is rejected to be backward compatible. A new
pane API wxAuiPaneInfo::MoveOver() allows to create stacks by program.
An option is also present to force a pane to always be in a notebook,
even when not stacked over another pane (it then always appears inside a
tab, excepted when floating).

All documentation is still to do. I'll go into that and update the
interfaces ASAP.

[Kinaou Herve]

Le jeudi 20 mars 2014 14:54:32 UTC+1, lpoujoulat a écrit :

Le 20/03/2014 14:34, Vadim Zeitlin a écrit :
> On Thu, 20 Mar 2014 09:38:12 +0100 Laurent Poujoulat wrote:
>
> It would be great to have at least a few (which is precisely
> more than a couple) testers!
I beg for that :) !  Any volunteers ? Issues can be reported on the
github repository until the branch is merged.

If there is not too emergency, I volunteer :)

[Laurent Poujoulat]

You are always welcome !

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

[Roberto Perpuly]

Hi,

Had a little free time and performed some testing of the wxAui branch.  Found a couple of things

EVT_AUINOTEBOOK_TAB_RIGHT_UP event not being propagated
https://github.com/nhold/wxWidgets/issues/35

wxAuiNotebook - behavior differences when deleting tabs
https://github.com/nhold/wxWidgets/issues/34

wxAuiNotebook fails to draw the tabs when the notebook has 1 page
https://github.com/nhold/wxWidgets/issues/33

[Laurent Poujoulat]

Le 21/03/2014 08:27, Roberto Perpuly a écrit :

Hi,

Had a little free time and performed some testing of the wxAui branch.  Found a couple of things

EVT_AUINOTEBOOK_TAB_RIGHT_UP event not being propagated
https://github.com/nhold/wxWidgets/issues/35

wxAuiNotebook - behavior differences when deleting tabs
https://github.com/nhold/wxWidgets/issues/34

wxAuiNotebook fails to draw the tabs when the notebook has 1 page
https://github.com/nhold/wxWidgets/issues/33

Thanks for the time you take. I'll have a look at this and try to fix them quickly.
Regards
Laurent

On Thursday, March 20, 2014 1:38:12 AM UTC-7, lpoujoulat wrote:

Hi Vadim,

we have made lately with Nathan Hold a lot of work on the wxAui dynamic
branch to make it (almost) backward compatible with the current wxAui
behaviour. We have no show stopper bug left. It would be nice to merge
it back in the main tree now, so everyone could test it and have a
single place to track issues; Could you check it and tell us what's
missing to do this ?

The main visible changes for the code using wxAui are:
- Deprecation of direct access to the wxAuiPaneInfo fields
- Renaming of the wxAuiPaneInfo methods to a more consistent Set<option
name> scheme. Previous methods are still there, but are deprecated.
- Perspectives save format has changed

The code is at:

https://github.com/nhold/wxWidgets

regards,
Laurent Poujoulat

[Paul K]

Hi Laurent,

 

Thank you for working on all these changes!

 

> - Deprecation of direct access to the wxAuiPaneInfo fields

Can you elaborate on access to what fields has been deprecated and why that decision was made? The reason I'm asking is that some SDKs can only work through the public methods/fields (as in my case through what wxlua provides) and if a field becomes private/protected, I can't access it through the API. I do use some of the fields (for example "window") and would like to make sure I'll continue to have access to those.

 

> - Perspectives save format has changed

 

Would loading the"old" format throw an error or be silently ignored?

Paul.

 

[Laurent Poujoulat]

Le 27/03/2014 05:11, Paul K a écrit :
> Hi Laurent,
Hi Paul,

> Thank you for working on all these changes!
> > - Deprecation of direct access to the wxAuiPaneInfo fields
> Can you elaborate on access to what fields has been deprecated and why
> that decision was made? The reason I'm asking is that some SDKs can
> only work through the public methods/fields (as in my case through
> what wxlua provides) and if a field becomes private/protected, I can't
> access it through the API. I do use some of the fields (for example
> "window") and would like to make sure I'll continue to have access to
> those.

The idea of deprecating direct access to wxAuiPaneInfo fields is from
Malcom (the original aui branch author) and I agree as it's a good C++
practice to only give access to fields through methods because it's
safer and allows "smooth" refactoring when needed. Which fields are
hidden behind get/set ? The answer is simple: all. Can you tell me more
on how it is used inside wxLua ? Is wxAuiPaneInfo mapped on a table ?
Could it be then possible to access them through function fields ?

Extra question for all concerned: is there any other script bindings
having the same problem ?

> > - Perspectives save format has changed
> Would loading the"old" format throw an error or be silently ignored?

In fact, I just checked again, and it seems that the format did not
changed after all (It's still "layout2"). I can't understand why I was
sure it had ... So, I'm sorry for the false alarm. I will however do
some more tests about this to be sure it actually work.

> Paul.
Laurent

[Vadim Zeitlin]

On Thu, 27 Mar 2014 09:33:57 +0100 Laurent Poujoulat wrote:

LP> > Thank you for working on all these changes!
LP> > > - Deprecation of direct access to the wxAuiPaneInfo fields
LP> > Can you elaborate on access to what fields has been deprecated and why
LP> > that decision was made? The reason I'm asking is that some SDKs can
LP> > only work through the public methods/fields (as in my case through
LP> > what wxlua provides) and if a field becomes private/protected, I can't
LP> > access it through the API. I do use some of the fields (for example
LP> > "window") and would like to make sure I'll continue to have access to
LP> > those.
LP> The idea of deprecating direct access to wxAuiPaneInfo fields is from
LP> Malcom (the original aui branch author) and I agree as it's a good C++
LP> practice

I definitely agree with this but I can't help wondering if it's really so
beneficial as to justify breaking backwards compatibility and (probably)
vastly increasing the size of the patch. I don't want to sound ungrateful,
but the original patches from Malcom probably could have been applied 3
years ago if only he had refrained from doing "insignificant" changes like
this as well as even more insignificant renaming of the existing
identifiers to correspond to the naming convention.

I understand the desire to improve things, but sometimes it may be
preferable sacrifice the high ideals on the altar of low practicality.
Personally I believe that we should just leave the fields alone because
while this certainly isn't the "best practice", changing this doesn't have
any tangible benefits.

Regards,
VZ

[Laurent Poujoulat]

The problem with the pane info, is that people are encouraged to deal
with these fields assuming they work as they imagine, although they are
in fact part of implementation and not interfaces. Anyway, at the
moment, all these fields and methods are still there, but just marked as
deprecated, so it's not an immediate problem. Deprecation will let some
times to fix out the problems on applications and binding side I think.
If it proves to be a real problem to the majority of people, we could
still cancel deprecation.

Regards
Laurent

[Vadim Zeitlin]

On Thu, 27 Mar 2014 13:04:27 +0100 Laurent Poujoulat wrote:

LP> The problem with the pane info, is that people are encouraged to deal
LP> with these fields assuming they work as they imagine, although they are
LP> in fact part of implementation and not interfaces. Anyway, at the
LP> moment, all these fields and methods are still there, but just marked as
LP> deprecated, so it's not an immediate problem. Deprecation will let some
LP> times to fix out the problems on applications and binding side I think.
LP> If it proves to be a real problem to the majority of people, we could
LP> still cancel deprecation.

In practice, deprecating something used in just about all code using wxAUI
(please correct me if I'm wrong...) means that it really will have to be
fixed immediately, it's not like you could live with builds generating
hundreds of warnings. Also, the fact that it's deprecated and not removed
immediately doesn't change the fact that it will presumably be removed
later, so exactly the same considerations should really be applied to
deprecating something as to removing it, the fact that it will happen in a
few years doesn't make it less real.


I'm afraid this could be the same thing as with wxPENSTYLE_XXX and related
changes. It definitely stems from good intentions, but I am pretty sure by
now that deprecating the old constants was a big mistake, I've lost _days_
by getting rid of hundreds if not thousands of warnings in the different
code I'm working on without any real benefit.

It may not seem like a big deal to just fix the code to use
wxBRUSHSTYLE_SOLID instead of wxSOLID. But now multiply this by the number
of occurrences of wxSOLID in the code. And then multiply this again by the
number of wxWidgets programs/users. And you come to the realization that
this change, which probably costed a couple of days to Francesco to make
(and about the same for me to fix various compilation problems it resulted
in back then) could cost decades to deal with globally.

Is it worth doing the same thing for AUI? Just think about slowdown to the
world economy due to the extra time spent on fixing these warnings (without
mentioning the increased global warming due to all the time spent
recompiling this code!).

Regards,
VZ

[Laurent Poujoulat]

My bad, I had not thought to ecological impact :-) Seriously, I see your
point, and I propose to deprecate the **direct ** use of fields (because
it will be a problem for future maintenance to not be able to change
implementation of an already complex code) , and to definitely restore
the original name of the access methods to avoid useless refactoring. Do
you think it is a possible move ?

>
> Regards,
> VZ
Regards,
Laurent

[Vadim Zeitlin]

On Thu, 27 Mar 2014 13:25:23 +0100 Laurent Poujoulat wrote:

LP> My bad, I had not thought to ecological impact :-)

If it can change the results of Paris elections, why not wxAUI API, right?

LP> Seriously, I see your point, and I propose to deprecate the **direct **
LP> use of fields (because it will be a problem for future maintenance to
LP> not be able to change implementation of an already complex code) ,

I'd just add accessors and leave the fields alone (well, with a comment
saying "DO NOT USE DIRECTLY"). Only the accessors would be documented and
if we ever do need to refactor anything and get rid of some fields, then we
could always deprecate those specific fields. Of course, if you already do
really need to get rid of some fields, you should do it now. I just don't
understand why should we break things proactively.

LP> and to definitely restore the original name of the access methods to
LP> avoid useless refactoring.

I'd definitely like to avoid renamings.

LP> Do you think it is a possible move ?

I had already agreed to accept Malcolm's changes once, with renamings and
all. So it is, of course, possible -- even not doing anything is possible
too. But if we can avoid semantically meaningless renamings, I'd be
happier. And if we could avoid breaking people code without good reason
(and after all, it's not _their_ fault that they didn't use the accessors
which didn't exist when their code was written), I'd be even happier. But
it's up to you to decide.

TIA,
VZ

[Laurent Poujoulat]

Le 27/03/2014 23:18, Vadim Zeitlin a écrit :
> On Thu, 27 Mar 2014 13:25:23 +0100 Laurent Poujoulat wrote:
>
> LP> My bad, I had not thought to ecological impact :-)
>
> If it can change the results of Paris elections, why not wxAUI API, right?

If any Open Source API could change election results, we would be
largely sponsored !

>
> LP> Seriously, I see your point, and I propose to deprecate the **direct **
> LP> use of fields (because it will be a problem for future maintenance to
> LP> not be able to change implementation of an already complex code) ,
>
> I'd just add accessors and leave the fields alone (well, with a comment
> saying "DO NOT USE DIRECTLY"). Only the accessors would be documented and
> if we ever do need to refactor anything and get rid of some fields, then we
> could always deprecate those specific fields. Of course, if you already do
> really need to get rid of some fields, you should do it now. I just don't
> understand why should we break things proactively.
>
> LP> and to definitely restore the original name of the access methods to
> LP> avoid useless refactoring.
>
> I'd definitely like to avoid renamings.
>
> LP> Do you think it is a possible move ?
>
> I had already agreed to accept Malcolm's changes once, with renamings and
> all. So it is, of course, possible -- even not doing anything is possible
> too. But if we can avoid semantically meaningless renamings, I'd be
> happier. And if we could avoid breaking people code without good reason
> (and after all, it's not _their_ fault that they didn't use the accessors
> which didn't exist when their code was written), I'd be even happier. But
> it's up to you to decide.

The goal is to have a good, maintanable, wxAui, not to ennoy the users,
so I will follow your wisdom, unless someone has better arguments:
- Old setters name will be restored and make sure that all fields have
getters/setters.
- Remove deprecation indicators on fields to avoid spamming warnings on
innocents,
- Remove the fields from API documentation and strongly warn against
their use being not supported in the long term
- New fields (if any) will be added in private section.

>
> TIA,
> VZ
Regards,
Laurent

[Vadim Zeitlin]

On Fri, 28 Mar 2014 09:12:13 +0100 Laurent Poujoulat wrote:

LP> The goal is to have a good, maintanable, wxAui, not to ennoy the users,
LP> so I will follow your wisdom, unless someone has better arguments:
LP> - Old setters name will be restored and make sure that all fields have
LP> getters/setters.
LP> - Remove deprecation indicators on fields to avoid spamming warnings on
LP> innocents,
LP> - Remove the fields from API documentation and strongly warn against
LP> their use being not supported in the long term
LP> - New fields (if any) will be added in private section.

Even if you probably already know this, this plan looks perfect to me.

TIA!
VZ

[Laurent Poujoulat]

No problem if it can save the rainforest :)

[Malcolm MacLeod]

Hi all,

Have finally resurfaced again and thought I'd check up what has become
in the end with the branch cleanup in anticipation of possibly working
on it again when and if time allows - unfortunately I had to drop 'off
the grid' halfway through the discussions last summer.

I'm pleasantly surprised to see the amount of work that has gone into
keeping it alive and trying to get it to a point where it is finally
accepted - thank you Laurent, Nathan and anyone else involved for this!

I'm still not quite in a position to contribute too much time, though
hopefully I might be soon. However I do see there are some unanswered
questions about the code. So I just wanted to volunteer to the people
who are working on it - if there is anything specific you want to ask
let me know and I will do my best to answer - anything to finally get
this thing sorted out as it bugs me at the back of my mind to know that
this branch is still outstanding.

I also hang around in #wxwidgets on freenode - so if you have IRC we can
maybe discuss things there if you think that will help at all.

- Malcolm MacLeod

[Laurent Poujoulat]

Le 01/05/2014 21:58, Malcolm MacLeod a écrit :
> Hi all,
>
> Have finally resurfaced again and thought I'd check up what has become
> in the end with the branch cleanup in anticipation of possibly working
> on it again when and if time allows - unfortunately I had to drop 'off
> the grid' halfway through the discussions last summer.

Hi Malcom, I'm very pleased you come back :-)

>
> I'm pleasantly surprised to see the amount of work that has gone into
> keeping it alive and trying to get it to a point where it is finally
> accepted - thank you Laurent, Nathan and anyone else involved for this!
>
> I'm still not quite in a position to contribute too much time, though
> hopefully I might be soon. However I do see there are some unanswered
> questions about the code. So I just wanted to volunteer to the people
> who are working on it - if there is anything specific you want to ask
> let me know and I will do my best to answer - anything to finally get
> this thing sorted out as it bugs me at the back of my mind to know that
> this branch is still outstanding.

It's not a problem for me as I have been granted time to work on it; but
it's very cool if you are there to answer some questions. At the moment,
we have cleared almost all backward compatibility issues raised by Vadim
and there are still a couple of bugs on Linux reported that I have to
clear out. I hoped to do that this week-end, but finally I think it will
be next one ...

You'll be pleased to know that I use it in my beta software with very
good feedback from our test customers. They just say that a missing
feature is the ability to dock several panes in floating windows (yes
Nathan, you were right), so if you have some idea on how to achieve this
... But there is no emergency as the priority is to clear out bugs and
merge it back "as is" before adding new feature.

>
> I also hang around in #wxwidgets on freenode - so if you have IRC we can
> maybe discuss things there if you think that will help at all.
>
> - Malcolm MacLeod
>
>
>> No problem if it can save the rainforest :)
>>
>> Le 28/03/2014 13:56, Vadim Zeitlin a écrit :
>>> On Fri, 28 Mar 2014 09:12:13 +0100 Laurent Poujoulat wrote:
>>>
>>> LP> The goal is to have a good, maintanable, wxAui, not to ennoy the users,
>>> LP> so I will follow your wisdom, unless someone has better arguments:
>>> LP> - Old setters name will be restored and make sure that all fields have
>>> LP> getters/setters.
>>> LP> - Remove deprecation indicators on fields to avoid spamming warnings on
>>> LP> innocents,
>>> LP> - Remove the fields from API documentation and strongly warn against
>>> LP> their use being not supported in the long term
>>> LP> - New fields (if any) will be added in private section.
>>>
>>> Even if you probably already know this, this plan looks perfect to me.
>>>
>>> TIA!
>>> VZ

Regards,
Laurent

[Malcolm MacLeod]

> > I'm still not quite in a position to contribute too much time, though
> > hopefully I might be soon. However I do see there are some unanswered
> > questions about the code. So I just wanted to volunteer to the people
> > who are working on it - if there is anything specific you want to ask
> > let me know and I will do my best to answer - anything to finally get
> > this thing sorted out as it bugs me at the back of my mind to know that
> > this branch is still outstanding.
> It's not a problem for me as I have been granted time to work on it; but
> it's very cool if you are there to answer some questions. At the moment,
> we have cleared almost all backward compatibility issues raised by Vadim
> and there are still a couple of bugs on Linux reported that I have to
> clear out. I hoped to do that this week-end, but finally I think it will
> be next one ...
>
> You'll be pleased to know that I use it in my beta software with very
> good feedback from our test customers.

That is great to hear.

> They just say that a missing
> feature is the ability to dock several panes in floating windows (yes
> Nathan, you were right), so if you have some idea on how to achieve this
> ... But there is no emergency as the priority is to clear out bugs and
> merge it back "as is" before adding new feature.

Off the top of my head I can think of two ways to go hear.

1) Thanks to the new wxAUI_MGR_ALLOW_EXTERNAL_MOVE flag (which is an
extension of the ability that wxAuiNotebook always had) it it possible
to drag panes between managers - so one could simply give the floating
panes their own managers (under certain conditions) and use this flag to
allow the panes to be dragged between the managers. The main problem to
be solved here then would be to get 'multi manager serialization'
working properly so that serialization works properly when panes change
between managers (it doesn't currently) - Some function that restores
all the managers at the same time, instead of one at a time, could
probably detect the movement and handle things right.

2) Handle everything like we are now with the dynamic notebooks in one
manager.
The key parts that would have to be edited are the 'Layout' code and
'DoDrop' - both of these are rather complex/finicky already though - it
might be a good idea to first do a 'cleanup' on these parts of the code
to make them easier to follow.
I think there would definitely be more code to do it this way, but there
may be some benefits as well.


Either way I agree that the key thing is to first get the current code
base merged before looking at adding more stuff.

- Malcolm

[Laurent Poujoulat]

This is probably the way to go, as I saw that floating panes already
have a hidden manager ...

[Malcolm MacLeod]

> > <snip>

> > 1) Thanks to the new wxAUI_MGR_ALLOW_EXTERNAL_MOVE flag (which is an
> > extension of the ability that wxAuiNotebook always had) it it possible
> > to drag panes between managers - so one could simply give the floating
> > panes their own managers (under certain conditions) and use this flag to
> > allow the panes to be dragged between the managers. The main problem to
> > be solved here then would be to get 'multi manager serialization'
> > working properly so that serialization works properly when panes change
> > between managers (it doesn't currently) - Some function that restores
> > all the managers at the same time, instead of one at a time, could
> > probably detect the movement and handle things right.
> This is probably the way to go, as I saw that floating panes already
> have a hidden manager ...

That would make it even easier to go that route then yes.


Just to let everyone know, I've had a scan over all the changes that
have been made in your branch and they all look good to me, did not spot
anything that looked problematic, all the key things that I still
thought needed to be done seem to have been done.
Just one thing, are you 100% sure that you have got all the
wxAuiNotebook events right?
The one 'large' thing that I still needed to do was go over
wxAuiNotebook and ensure that all the events that were previously
present have been added back in and behaved in a backwards compatible
manner - I see you have added some events back in, and made some fixes
there, just want to make sure that they have all been checked.


The only thing I can't really agree with personally is the dropping of
the deprecation, while I agree that it doesn't need to be deprecated
immediately (the 2.8 compat was just a placeholder until an appropriate
point was decided) or possibly not even for a long time to come.
I do think the *option* should be there in future, so that 12 years from
now when people do decide to deprecate it is possible to do so, by not
having the replacement functions available *now* we are cementing the
use of the 'worse' API as more and more people will use it, and
essentially ensuring that deprecation will *never* be a viable option.

I personally think that actual deprecation could be turned off for now,
but kept available, and all deprecated members marked as such in
documentation (or hidden from documentation) to encourage users to use
the newer versions - I can't see any harm in this route and it seems
better than just doing nothing about it and leaving an inconsistent API
forever - having an inconsistent API means that internally we have to
use that API which makes working on the AUI code less pleasurable, at
least with the deprecation (even if turned off) the better API can be
used internally.

Anyway I can see the other side of the argument as well, especially that
it is complicating the merge, so I am fine to leave it out for now. It
is certainly no reason to stop the merge for now, deprecation can always
be revisited/discussed again later, just thought I would weigh in on
that subject.

- Malcolm

[Laurent Poujoulat]

Le 09/05/2014 10:12, Malcolm MacLeod a écrit :
>>> <snip>
>>> 1) Thanks to the new wxAUI_MGR_ALLOW_EXTERNAL_MOVE flag (which is an
>>> extension of the ability that wxAuiNotebook always had) it it possible
>>> to drag panes between managers - so one could simply give the floating
>>> panes their own managers (under certain conditions) and use this flag to
>>> allow the panes to be dragged between the managers. The main problem to
>>> be solved here then would be to get 'multi manager serialization'
>>> working properly so that serialization works properly when panes change
>>> between managers (it doesn't currently) - Some function that restores
>>> all the managers at the same time, instead of one at a time, could
>>> probably detect the movement and handle things right.
>> This is probably the way to go, as I saw that floating panes already
>> have a hidden manager ...
> That would make it even easier to go that route then yes.
>
>
> Just to let everyone know, I've had a scan over all the changes that
> have been made in your branch and they all look good to me, did not spot
> anything that looked problematic, all the key things that I still
> thought needed to be done seem to have been done.
> Just one thing, are you 100% sure that you have got all the
> wxAuiNotebook events right?

I'm not actually sure of that :) I had a hell of work to get the
wxAuiNotebook behave like it used to do. The funniest thing is that I
think they are not too useful now, as they are more or less
pre-configured frames now.

> The one 'large' thing that I still needed to do was go over
> wxAuiNotebook and ensure that all the events that were previously
> present have been added back in and behaved in a backwards compatible
> manner - I see you have added some events back in, and made some fixes
> there, just want to make sure that they have all been checked.

I made some recent fixes regarding wxAuiNotebook events handling and I'm
currently looking at a reported issue regarding these events. But I
still have to check them all individually.

>
>
> The only thing I can't really agree with personally is the dropping of
> the deprecation, while I agree that it doesn't need to be deprecated
> immediately (the 2.8 compat was just a placeholder until an appropriate
> point was decided) or possibly not even for a long time to come.
> I do think the *option* should be there in future, so that 12 years from
> now when people do decide to deprecate it is possible to do so, by not
> having the replacement functions available *now* we are cementing the
> use of the 'worse' API as more and more people will use it, and
> essentially ensuring that deprecation will *never* be a viable option.
>
> I personally think that actual deprecation could be turned off for now,
> but kept available, and all deprecated members marked as such in
> documentation (or hidden from documentation) to encourage users to use
> the newer versions - I can't see any harm in this route and it seems
> better than just doing nothing about it and leaving an inconsistent API
> forever - having an inconsistent API means that internally we have to
> use that API which makes working on the AUI code less pleasurable, at
> least with the deprecation (even if turned off) the better API can be
> used internally.
>
> Anyway I can see the other side of the argument as well, especially that
> it is complicating the merge, so I am fine to leave it out for now. It
> is certainly no reason to stop the merge for now, deprecation can always
> be revisited/discussed again later, just thought I would weigh in on
> that subject.

It's a perfect summary of all the discussion we had with Vadim about that.

A last word on things to check: there are a number of small graphical
glitches in the tab rendering of the dynamic branch: if you or someone
can have a look at them. I noticed small errors in simple tab art under
Windows and gtk tab art under Linux. I suspect bad offsets somewhere.
>
> - Malcolm
>
Laurent

[Jens Lody]

I can see if I find time to look into the graphical issues.
The gtk-tabart is based on patches of me and one of my co-developers in
the C::B team.
Are the simple tabs only "broken" in windows or also in gtk ?
On windows I need to work in VM's, because I only use windows on real
machines at work, but I do not have the time to work on it there. That
sometimes can lead to graphical issues.

Jens
> >
> > - Malcolm
> >
> Laurent
>


--

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:
http://rpm.jenslody.de/


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

[Malcolm MacLeod]

> > > <snip>

> > > Just one thing, are you 100% sure that you have got all the
> > > wxAuiNotebook events right?
> > I'm not actually sure of that :) I had a hell of work to get the
> > wxAuiNotebook behave like it used to do. The funniest thing is that I
> > think they are not too useful now, as they are more or less
> > pre-configured frames now.

They still have a bit of a use in that they implement a 'notebook'
interface - so they can be used where you want to drop AUI in place of
e.g. a normal notebook (or even switch between the two) - but agree they
are basically just a glorified wrapper now - which is good, much less
code to maintain in the long run.


> > <snip>

> > A last word on things to check: there are a number of small graphical
> > glitches in the tab rendering of the dynamic branch: if you or someone
> > can have a look at them. I noticed small errors in simple tab art under
> > Windows and gtk tab art under Linux. I suspect bad offsets somewhere.
>
> I can see if I find time to look into the graphical issues.
> The gtk-tabart is based on patches of me and one of my co-developers in
> the C::B team.
> Are the simple tabs only "broken" in windows or also in gtk ?
> On windows I need to work in VM's, because I only use windows on real
> machines at work, but I do not have the time to work on it there. That
> sometimes can lead to graphical issues.

Jens (I think) knows more about that part of the code than me at this
point, so if he is volunteering it is probably better for him to look, I
will try check the branch out this side over the weekend and give it a
bit of a run though to see if there is anything obvious and/or if I can
fix any of the outstanding issues.

One other issue (sorry if it has already been discussed and I just
missed it) - but it needs to be decided what will happen with the sample
apps, i.e. should both the legacy and auinew sample apps be kept around,
or should there just be one new sample app? auinew was a bit hacky as I
just used that as a test bed - a proper sample of how to use the new
stuff is probably required, but maybe the sample has already been
handled I will check the branch out and have a look.

- Malcolm MacLeod

[Vadim Zeitlin]

On Fri, 09 May 2014 20:36:33 +0200 Malcolm MacLeod wrote:

MM> One other issue (sorry if it has already been discussed and I just
MM> missed it) - but it needs to be decided what will happen with the sample
MM> apps, i.e. should both the legacy and auinew sample apps be kept around,
MM> or should there just be one new sample app?

I don't remember if this was discussed, but I really don't see why would
we want to have 2 samples. There should be only one.

Regards,
VZ

[Laurent Poujoulat]

I don't think this has been discussed, but I agree there should be only
one sample to demonstrate all possibilities in a single place. It's
easier for those who look for a component that fit their need to find
out this way.

Laurent

>
> Regards,
> VZ

[Laurent Poujoulat]

Hi Jens and thanks for helping. I entered a new issue with some
screenshots of the problem in Nathan github repository where the dynamic
branch is currently hosted (it's issue #46). The problem is not
depending on the platform it seems, so it should be easier to fix it.
https://github.com/nhold/wxWidgets/issues/46


>
> Jens
>>> - Malcolm
>>>
>> Laurent
>>
>
Laurent

[Malcolm MacLeod]

> Jens (I think) knows more about that part of the code than me at this
> point, so if he is volunteering it is probably better for him to look, I
> will try check the branch out this side over the weekend and give it a
> bit of a run though to see if there is anything obvious and/or if I can
> fix any of the outstanding issues.

Found (and fixed) a crash bug this side, should I send pull requests to
your branch or to the nhold branch?

[Malcolm MacLeod]

The problem is that currently the 'aui' sample doesn't really make use
of the new features at all, other than the wxAuiNotebook that it has, so
it is difficult to test/see what the new features are.
The 'aui' sample should be replaced with the 'auinew' one or updated so
that it has all the new features.

- Malcolm MacLeod

[Laurent Poujoulat]

Good ! To nhold please.

[Laurent Poujoulat]

Updating the current sample should not be hard: we have mostly to
implement the new "magic" event and put a conditional veto in it to
allow/disallow tabbing. I don't know if we should go deeper than that.

[Malcolm MacLeod]

> <snip>

> Hi Jens and thanks for helping. I entered a new issue with some
> screenshots of the problem in Nathan github repository where the dynamic
> branch is currently hosted (it's issue #46). The problem is not
> depending on the platform it seems, so it should be easier to fix it.
> https://github.com/nhold/wxWidgets/issues/46

Ensuring that wxBORDER_NONE is passed as the wxAuiNotebook style flag (I
hard coded it in wxAuiNotebook::Init() and wxAuiNotebook::Create() -
makes the black border go away.

I am not sure however if this is then an actual bug in wxAUI - or if it
is just a problem with the sample?

As AUI draws its own borders should it be stripping borders from all
panes that are added to it?
If so I'm a bit worried about how to manage that, what happens if the
pane is then removed from AUI, should the border then get added back
again? I'm not sure if it is worth adding all that complexity or if it
is just reasonable to assume that panes passed to AUI will not have
border styles set?

- Malcolm MacLeod

[Laurent Poujoulat]

I think the later is the best option. There is no need here to add
complexity inside the panes management. Moreover, nobody reported any
issue with in panes borders with the new branch, so I tend to say it's
good "as is".

>
> - Malcolm MacLeod
>
Laurent

[Malcolm MacLeod]

The old wxAuiNotebook seems to have had a child frame which it created
with the hardcoded style wxNO_BORDER|wxWANTS_CHARS.
As the new wxAuiNotebook has no child frame I guess this means (to be
100% backwards compatible) we would have to force these styles and strip
other border style flags (for wxAuiNotebook only)

- Malcolm MacLeod

[Laurent Poujoulat]

This seems the best option. Another word: I checked if all wxAuiNotebook
event are generated, and I found them all implemented.
>
> - Malcolm MacLeod
>

[Malcolm MacLeod]

Okay, I've gone ahead and implemented a basic fix for the black border
issue - if someone can just sanity check it - the other issues I think
maybe would be better for Jens to look at, although honestly I'm not
sure they are major enough that they can't wait for post merge.

Other than the pending patches - and with the news that the events are
all okay - I think generally everything seems in good shape and ready to
merge. I think it should happen sooner rather than later.

The only thing really I think that is missing is if someone
(Unfortunately I'm out of time for now) could update the sample with
some items to enable/disable dynamic notebooks and the other new
features so that it is easier for people to give the code a final
'stress test' pre-merge, then I think it is basically good to go. Are
there any major pending issues that you know of that are preventing a
merge?

- Malcolm MacLeod

[Malcolm MacLeod]

> Okay, I've gone ahead and implemented a basic fix for the black border
> issue - if someone can just sanity check it - the other issues I think
> maybe would be better for Jens to look at, although honestly I'm not
> sure they are major enough that they can't wait for post merge.
>
> Other than the pending patches - and with the news that the events are
> all okay - I think generally everything seems in good shape and ready to
> merge. I think it should happen sooner rather than later.
>
> The only thing really I think that is missing is if someone
> (Unfortunately I'm out of time for now) could update the sample with
> some items to enable/disable dynamic notebooks and the other new
> features so that it is easier for people to give the code a final
> 'stress test' pre-merge, then I think it is basically good to go. Are
> there any major pending issues that you know of that are preventing a
> merge?

Just a note on the "CanDockOver" change - I personally think that this
is slightly problematic.
I understand that from a backwards compatibility perspective people
might want dynamic notebooks off by default, however I think most new
users (and many of the old ones) are likely going to want it on, I think
on is probably going to be the more used state. So it should be easy to
at least turn this on, we should not be making new users do non-obvious
stuff to get basic functionality up and running and also features should
be easy to 'discover'.

The event - while powerful and a great addition - does not seem the
right 'default' way to handle this to me, people who don't want to do
powerful things like allow/deny based on specific panes should simply be
able to call a method or pass a style - and have all "CanDockOver"
events default to true.

I think that CanDockOver should of course stay - but that instead of
checking for wxAuiNotebook to set the default it should check either for
a style or a member bool - wxAuiNotebook can set this style/bool
automatically and users of wxAuiManager can then easily also set it
(instead of being forced to handle unnecessary events)

- Malcolm

[Laurent Poujoulat]

Laurent POUJOULAT
Ingénieur Système / System Engineer

Tél: +33 (0)1 53 66 39 89
Fax: +33 (0)1 43 76 91 25

ART Technology
Le Chanzy
18 avenue Winston Churchill
94220 CHARENTON LE PONT
FRANCE

I honestly think handling the event is not a big deal, but I'm not
against adding a flag to the manager to control out the default behavior
of the event.
>
> - Malcolm
>

[Malcolm MacLeod]

> > Just a note on the "CanDockOver" change - I personally think that this
> > is slightly problematic.
> > I understand that from a backwards compatibility perspective people
> > might want dynamic notebooks off by default, however I think most new
> > users (and many of the old ones) are likely going to want it on, I think
> > on is probably going to be the more used state. So it should be easy to
> > at least turn this on, we should not be making new users do non-obvious
> > stuff to get basic functionality up and running and also features should
> > be easy to 'discover'.
> >
> > The event - while powerful and a great addition - does not seem the
> > right 'default' way to handle this to me, people who don't want to do
> > powerful things like allow/deny based on specific panes should simply be
> > able to call a method or pass a style - and have all "CanDockOver"
> > events default to true.
> >
> > I think that CanDockOver should of course stay - but that instead of
> > checking for wxAuiNotebook to set the default it should check either for
> > a style or a member bool - wxAuiNotebook can set this style/bool
> > automatically and users of wxAuiManager can then easily also set it
> > (instead of being forced to handle unnecessary events)
> I honestly think handling the event is not a big deal, but I'm not
> against adding a flag to the manager to control out the default behavior
> of the event.

I know adding an event handler seems small - and it is - but I think a
lot of beginners are going to expect it to work 'out the box' without an
event - as it is a 'non-intuitive' way of enabling the functionality.
In many cases they may just assume dynamic notebooks are broken instead
of searching further - no matter how good the documentation is. I know
my initial reaction when trying this side was "oh no dynamic notebooks
aren't working" - before I remembered this change and looked at it
closer...
(This is just my experience from some of the support queries we see on
e.g. IRC and the forums sometimes)
Also it will make things harder for e.g. stuff like XRC/wxSmith etc. if
they need to add event handlers instead of just a simple flag.

So I think we should have a flag for this also - however that is just my
opinion, I'm not going to push it if others don't agree as mostly I'm
just interested in getting this merged and having an API that works for
everyone, so perhaps other interested parties should say whether they
agree/disagree - it is a pretty small change so I think we should sort
it out now if we are going to do it.

- Malcolm

[Laurent Poujoulat]

The XRC argument alone is enough to add this flag :) I'll do it as soon
as Nathan have merged your latest pull request, or if you have time, you
can add it. The only thing is the default has to be backward compatible.


>
> - Malcolm
>
Regards
Laurent

[Nathan Hold]

Hey guys,

Been busy for a while, my wife is pregnant and we just had a baby moon (It's a girl!).

Anyway, I'm back and ready to tackle the rest of this to get it into the main repo.

I added a "formerge" milestone on the issues I think we need to finish before merging.

I think I found 5 all up, 2 of those are duplicates (If I am reading them right!) 

and I am still able to repro them.

I am also going to merge master in again to make sure there are no outstanding problems

for Vadz to fix when merging.

Cheers, Nathan

[Malcolm MacLeod]

> Been busy for a while, my wife is pregnant and we just had a baby moon
> (It's a girl!).

Congratulations!

>
> Anyway, I'm back and ready to tackle the rest of this to get it into
> the main repo.
> I added a "formerge" milestone on the issues I think we need to finish
> before merging.
> I think I found 5 all up, 2 of those are duplicates (If I am reading
> them right!)
> and I am still able to repro them.

I've sent a pull request now for - what I think - was the most complex
of the remaining issues, it needs some independent verification that it
works okay but I think it should work.
The remaining issues after that should be relatively trivial, and are
actually quite minor, so I think we are almost there!

Unfortunately I think I've burnt through pretty much all the time I have
available for the next while, so I probably won't be able to help much
more for the coming week, but we will see, will try keep an eye out at
least.

Thanks,
Malcolm MacLeod

[Laurent Poujoulat]

Le 12/05/2014 23:23, Malcolm MacLeod a écrit :
>> Been busy for a while, my wife is pregnant and we just had a baby moon
>> (It's a girl!).
> Congratulations!

Félicitations ! and best wishes to your family !

>> Anyway, I'm back and ready to tackle the rest of this to get it into
>> the main repo.
>> I added a "formerge" milestone on the issues I think we need to finish
>> before merging.
>> I think I found 5 all up, 2 of those are duplicates (If I am reading
>> them right!)
>> and I am still able to repro them.
> I've sent a pull request now for - what I think - was the most complex
> of the remaining issues, it needs some independent verification that it
> works okay but I think it should work.
> The remaining issues after that should be relatively trivial, and are
> actually quite minor, so I think we are almost there!

I'm testing it with my applications right now, so I will see if
something is going wrong quickly

> Unfortunately I think I've burnt through pretty much all the time I have
> available for the next while, so I probably won't be able to help much
> more for the coming week, but we will see, will try keep an eye out at
> least.

Thanks a lot for the time you already spent. I still have a little time,
so I will use it for the style flag to enable dynamic notebooks easily
and I will also try to fix the remaining bugs marked by Nathan.

> Thanks,
> Malcolm MacLeod
>
>
Regards
Laurent

[Jens Lody]

Am Freitag, den 09.05.2014, 18:49 +0200 schrieb Jens Lody:
> I can see if I find time to look into the graphical issues.
> The gtk-tabart is based on patches of me and one of my co-developers in
> the C::B team.
> Are the simple tabs only "broken" in windows or also in gtk ?
> On windows I need to work in VM's, because I only use windows on real
> machines at work, but I do not have the time to work on it there. That
> sometimes can lead to graphical issues.
>
> Jens

It took a little longer to seriously look into the issues, sorry.
Things have happened in real life I can not influence. And these things
are more important than other things and take more power (and time) as I
thought.
Nevertheless:
the most issues seem to be fixed, but I found another small graphical
glitch, see: https://github.com/nhold/wxWidgets/pull/66

Jens

[Malcolm MacLeod]

> > I can see if I find time to look into the graphical issues.
> > The gtk-tabart is based on patches of me and one of my co-developers in
> > the C::B team.
> > Are the simple tabs only "broken" in windows or also in gtk ?
> > On windows I need to work in VM's, because I only use windows on real
> > machines at work, but I do not have the time to work on it there. That
> > sometimes can lead to graphical issues.
> >
> > Jens
>
> It took a little longer to seriously look into the issues, sorry.
> Things have happened in real life I can not influence. And these things
> are more important than other things and take more power (and time) as I
> thought.

Understand completely!

> Nevertheless:
> the most issues seem to be fixed, but I found another small graphical
> glitch, see: https://github.com/nhold/wxWidgets/pull/66

Thanks very much for the fix, and glad that everything else with the
artwork seems okay to you now.


For everyone else, the remaining issue list on the branch has become
very small (and the issues very tiny) - I think it will be time for a
merge request very soon.
If anyone wants to assist with further testing and/or contributing to
some of the smaller remaining issues (there are ones e.g. documentation
and improving the sample that anyone can contribute to without being an
AUI savant) then it would be appreciated.

Current issue list is at:
https://github.com/nhold/wxWidgets/issues?state=open
(NB! Only for issues to do with the new branch not AUI issues in general
- there will be plenty of time to handle those in future)

- Malcolm MacLeod

[Paul K]

Hi Malcolm,

 

> For everyone else, the remaining issue list on the branch has become
> very small (and the issues very tiny) - I think it will be time for a
> merge request very soon.
> If anyone wants to assist with further testing and/or contributing to
> some of the smaller remaining issues (there are ones e.g. documentation
> and improving the sample that anyone can contribute to without being an
> AUI savant) then it would be appreciated.

I'm excited about the changes as well and compiled the branch to test it with my application. Unfortunately I ran into several serious issues that indicate that more fixes may be required. I need to add a disclaimer that in order for me to work with the updated API I made several changes to the lua binding I use and it's possible that I introduced errors that caused crashes, but (1) some of the issues are not related to the crashes I saw and (2) the binding overall have been very stable with no known crashes running on 2.9.5 on Windows/OSX/Linux.

 

1. When my application starts, it has to panes hidden by default, one with wxListCtrl and another with wxTreeCtrl. For some reason, wxListCtrl header (1) is drawn on the screen, even though the pane itself is hidden and not shown. I can include a screenshot.

 

2. When the pane with wxListCtrl is made visible, the content of the pane is drawn somewhere else on the screen, but the pane itself shows the window underneath it. It looks like the background is not erased, or maybe erased in a different location.

 

3. The pane that includes wxTreeCtrl is drawn incorrectly in some cases. It has an area at the bottom of the pane that is not being redrawn and shows the content under the window (similar to #2).

 

4. I handle wxEVT_COMMAND_AUINOTEBOOK_BG_DCLICK event on wxAuiNotebook. The event is not triggered.

 

5. I handle wxEVT_COMMAND_AUINOTEBOOK_TAB_RIGHT_UP event on wxAuiNotebook. The event is triggered, but the application crashes. This is one of the events that involves casting to wxAuiTabCtrl, so it's possible that the crash is related to my binding updates.

 

6. I use saving and restoring perspectives in my application and some of the notebook tabs are not restored in the correct positions (for example, they are restored as split when they were originally together).

 

7. The application crashes when closed. I need to compile with the debug information to see where it crashesm but it's possible that this is also related to my binding update.

 

All the testing has been done on Windows. I plan to recompile on OSX as well later today to get stack traces for the crashes if I can reproduce them there.

 

Would you like me to open tickets on github for these issues? I'll provide more details and screenshots for the tickets I submit. Ideally, I'd test on aui or auinew examples, but none of them include AUINOTEBOOK_TAB_RIGHT_UP or AUINOTEBOOK_BG_DCLICK events.

 

BTW, I do have my application with binaries for various platforms available here (http://studio.zerobrane.com) and I can provide updated binaries for this branch if someone is interested in seeing the issues first hand.

 

Paul.

[Malcolm MacLeod]

If you can yes, although it may be difficult to look into some of these
things as the fact that you are using a lua binding (and also doing some
relatively non standard stuff) adds an extra level of
difficulty/indirection.

In terms of the aui sample - one of the remaining things to do is
actually to improve it to use all functionality so we can better test.
So perhaps we can add those and then test from there. (Contributions are
of course welcome if anyone wants to help build a better sample)

> BTW, I do have my application with binaries for various platforms
> available here (http://studio.zerobrane.com) and I can provide updated
> binaries for this branch if someone is interested in seeing the issues
> first hand.

This might be relatively useful, although not as useful as actually
being able to reproduce the issues in code that people can see of
course.

Thanks,
Malcolm