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

wxEVT_COMMAND_AUINOTEBOOK_XX events are not sent #99

Open Kinaou opened 9 years ago

Kinaou commented 9 years ago

In framemanager.cpp, all the wxEVT_COMMAND_AUINOTEBOOK_XX events are sent only if the managed window is of type wxAuiNotebook. But the notebooks managed internally are 'logical'. There is no 'physical' wxAuiNotebook class created, thus the events are never sent. This prevents, for example, to catch wxEVT_COMMAND_AUINOTEBOOK_TAB_RIGHT_UP event to display a context menu on right clicking on a tab.

mjmacleod commented 9 years ago

This is intentional - the AUINOTEBOOK events are only intended for backwards compatibility for people using wxAuiNotebook directly - not for people using the new dynamic notebooks. i.e. they are only for the AUINOTEBOOK class.

Some of these events may or may not also make sense in the dynamic context, but if so they should be done using manager specific events and possibly new events should be added - any events added here should take the greater 'AUI' context into account, including e.g. future other controls that may be added to AUI.

Kinaou commented 9 years ago

I see... But I think most (if not all) of previous AUINOTEBOOK events are also useful in the new AUI context. Do you mean all these events should be sent in parallel (at the same place in the code) of the current ones, but with a different ID like wxEVT_AUI_PANE_XX?

Specifically, I would like to have a contextual menu when I right click on a tab or on the title bar of a pane.

mjmacleod commented 9 years ago

"Do you mean all these events should be sent in parallel (at the same place in the code) of the current ones, but with a different ID like wxEVT_AUI_PANE_XX?"

Yes basically, but only if/when they make sense and they should try share with the rest of the existing manager events in a generic way where possible. There should probably be one 'title right clicked' event that can be handled for any pane, whether it is in a virtual notebook or not, the event handler can then be responsible for checking if its a notebook and handling it specially if that is what they want... This would make it easier to add other more advanced controls (e.g. maybe a collapsible tool bar as an example) without ending up with hundreds of special events for each thing.

I'm not against adding the more obvious ones now, however I am a bit concerned with any more adding of new functionality pre merge - it would be nice to try and get the merge done so that everyone involved can then discuss design decisions like this, if we make a decision here and then somebody else doesn't like it, it just creates yet another obstacle to getting the merge done.

mjmacleod commented 9 years ago

Thanks, patch looks great to me, I have no problem with it and would love to add it.

However I remain greatly concerned that someone else might have a problem with it, even if it is something minor like the names of the events or something else, and that this in turn will then make merging even harder. The last thing we need is to have the merge further delayed because vadz insists we remove these events or something banal like that, which sadly based on what I've seen so far I would not be greatly surprised...

I would really love to reach a point where the merge does happen, otherwise we risk this fork reaching a point where it is a separate project forever.

So I have to unfortunately ask, how badly do you need this? Can you hold out a bit longer? As always any help with the few remaining issues marked as 'formerge' would be appreciated - I think if we can close all of those off I can hopefully apply enough pressure to get the merge to happen, thanks again for all the work so far!

Kinaou commented 9 years ago

I understand your concern and I totally agree with you, we all have an interest to see this branch integrated as quickly as possible in the wx trunk and I try as much as possible to work in this direction. But I also have to respect the priorities defined by my managers. I transmit all my modifications by trying to reconcile the needs and expectations of wx and of my development team, not always in the wished order, from one side or the other :wink:.

I need these events to allow an identical behavior of the interface of our software solution between the 'old' and the 'new' aui (creation of a panel on db click, display of a context menu on right click, etc.).

Anyway we have an internal branch of wx with our own modifications, pending 'formal' implementation. If this patch is not applied right now or else in another form in the future, my implementation remains usable for our own needs in the meantime.

mjmacleod commented 9 years ago

Okay, thats good to know, and thanks for the contributions so far!

Kinaou commented 9 years ago

I wonder about the relevance of sending the same kind of event twice, for notebook and for pane in the following situations:

Shouldn't they be in an if/else, the PANE events being not sent if the AUINOTEBOOK was already been?

mjmacleod commented 9 years ago

I think there may be cases (people using new AUI) where they want to handle manager events instead of notebook specific events (sharing an event handler between a wxAuiManager and a wxAuiNotebook for instance)

So I think it is necessary to have both.