Ok, I 'm confused now because wxFNB works with (shift-)ctrl-tab just fine?!?
And every other app on linux uses ctrl-tab for tabs navigation so I don't really get what you mean by "get's eaten by GTK"...
Pressing Ctrl+Tab indeed switches the tabs - but it does not work as accelerator to open the dialog. It just switches to the next tab.
I have no idea how wxFNB handles this. I looked at its code as well as at the code of wxAuiNotebook but that didn't help much. I saw some basic handling for this in wxAuiNotebook but as far I unterstood it would generate an event that would allow custom handling. However, I wasn't able to handle this event because I simply didn't get it. Neither in the app nor in the editormanager. The next thing is that the example in the kirix forum (where I got the class for this dialog from) mentions the same issue and provides the same workaround as I implemented.
I am confused about this whole issue, too, but didn't find a solution yet.Edit: After a second look at the source of wxAuiNotebook things are more clear to me. wxAuiNotebook already handles the wxNavigationKeyEvent which is generated when pressing Ctrl+Tab and it just switches to the next tab. However, according to the kirix forum post I linked a few posts ago this should be different on windows - but I could not check this. Morten, did you test the patch on Windows?
I don't see an easy way to get Ctrl+Tab to show the switching dialog at the moment as wxAuiNotebook seems to consume the corresponding event and Ctrl+Tab doesn't seem to work as accelerator for menus on wxGTK. Has anyone an idea to get around this issue?
Besides this: The switch algorithm is not very intuitive. If I initiate "CTRL+TAB" the tab that is currently active is selected. Usually the next tab or (even better) the previous active one would be selected. Other wise the first "CTRL+TAB" has no function.
I didn't notice that, but I guess you're right. I think fixing this shouldn't be too difficult, at least selecting the next tab. Selecting the last active one could be more difficult and is actually already handled by the BrowseTracker-plugin. I don't think this needs to be duplicated.
The only thing missing is an update of the project file(s) as the files switcherdlg.{cpp/h} have been added.
Yes, I know. But I still don't use the project-file to build Code::Blocks therefore I didn't update it. But I updated the autotools-files
Ctrl+ is normally used to increase the font
The key combination is Ctrl+, and not Ctrl++