I have added other patches. One implements a sort of minimize function for frames http://trac.wxwidgets.org/ticket/10185red_team316 wrote:NinjaNL and jjn, I have to agree with tierra for the most part about the patches. They really should be put on Trac. I did see NinjaNL added something about 6 days ago, so right on. If the patches are on Trac, as well as Kirix, then nobody can come back and point fingers.
Unfortunately, although I think this is a subtle improvement, there has been no comment/reaction even just to say thanks but no thanks. This is why I despair a little of wxAUI. I am aware that Ben is very busy, as are all the wxWidgets developers. Even a comment of "looks nice but it doesn't fullfill our desires" would be welcome. Anything. I understand eveyones comments about submitting to trac and will do so again, but the lack of any sort of feedback is depressing. (Note that I am really only commenting on wxAui feedback here - I don't believe that I can complain about other aspects of wxWidgets)
You are probably correct there, I'll look into it.red_team316 wrote:NinjaNL, I have been testing a variation your ToolBar Orientation Horizontal/Vertical patch on wxGTK that does not modify the framemanager files and I must say, your patch is very clean looking and straight-forward other than the gripper comment possibly. I do not see it on Trac, I would like to see it there as this is one of the main reasons I decided to use wxWidgets rather than something else for my project. The only thing that seems a little odd about it is that when undocking a vertical toolbar, I think it should switch to a horizontal float.
This does make sense.red_team316 wrote:I don't think there is any problem with the way it is now, but it is odd since the caption cannot be read and that I have never used a program that undocks to a vertical floating toolbar. Possibly add a optional flag that forces the floating toolbar to be horizontal?...
If it works, then by all means use it. You could either generate the patch yourself, or post your code here (if it effectively becomes a derived class of wxAuiToolbar).red_team316 wrote:Also since my variation of your patch doesn't modify wxAUI, I think it might be able to be encapsulated into a derived class(such as wxAUISmartToolBar) that overridesand in the overrrided function, call the DOCK/FLOATING events from there. My code uses wxIdleEvents at the moment since I traced back the actual dock/floating switch point is actually triggered at an IDLE event. The one thing that your toolbar patch shows is that these types of events are really needed.Code: Select all
wxAuiManager::ProcessDockResult bool ProcessDockResult(wxAuiPaneInfo& target, const wxAuiPaneInfo& new_pos) ProcessDockResult() is a protected member of the wxAUI layout manager. It can be overridden by derived classes to provide custom docking calculations.
What are your thoughts on a derived class that doesn't modify current wxAUI code?
However I think that this sort of functionality SHOULD be contained within the standard wxAui system. So if you get to the point where you can get my code to do everything you want, then consider making a patch for the actual source of wxAui and of course submit a patch to trac.
Good luck.