I was not able to post those fixes as separate patches at one time, because there were too many changes. If I could get fast enough response at the tracker, I would continue to post the patches. However, my #9976 and #9984 are left for 5 months.tierra wrote:Of everything here, I'm most suprised by jjn, who while he's linked to the specific tracker issues he's fixed, he didn't actually post the patches into the tracker for each of the issues. Most of these patches would have already been applied if this was done.
wxAUI Improvements
Hey jjn,
could you take a look at my thread http://forums.wxwidgets.org/viewtopic.p ... highlight= and see if you might be able to help?
Have you done any more work on these patches? Improved wxAui any more?
regards
Mal
could you take a look at my thread http://forums.wxwidgets.org/viewtopic.p ... highlight= and see if you might be able to help?
Have you done any more work on these patches? Improved wxAui any more?
regards
Mal
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/
Sorry I'm less interested in wxWidgets now. I'll come back someday, probably when someone fixes #10008 officially...NinjaNL wrote:could you take a look at my thread http://forums.wxwidgets.org/viewtopic.p ... highlight= and see if you might be able to help?
I did some small fixes but I don't remember the details of them.NinjaNL wrote:Have you done any more work on these patches? Improved wxAui any more?
- tierra
- Site Admin
- Posts: 1355
- Joined: Sun Aug 29, 2004 7:14 pm
- Location: Salt Lake City, Utah, USA
- Contact:
No, what I said is true, and now I've wasted more time explaining this than actually looking into applying these patches myself, but again, these patches *still* aren't in the official tracker and *still* haven't been broken out into separate patches.NinjaNL wrote:Actually that is not quite true. Before we had the trac and only used the SF tracker, I posted a couple of fixes on the Kirix forum, where they were supposed to be posted, and have since posted at least one fix on the trac (http://trac.wxwidgets.org/ticket/10185 - 3 months ago). It looks as though no-one looks at these patches/fixes at all and as a result no-one feels as though any effort they make will be recognised. (And by recognised I don't mean a pat on the back, but simply that their patch appears in the source code - or at least that it has been examined by the developers)
wxAUI was integrated into the wxWidgets mainline trunk officially back in June 2006. Now while Kirix failed to really update their own site (and still hasn't), they were still advising people to start posting patches/bugs on the official wxWidgets tracker - SF.net at the time. Their wxAUI forums still exist as an archive of all the old discussion before wxAUI was officially added to wxWidgets, and should *only* be used for that purpose now. I can understand some confusion on this part, but it seems pretty obvious to me that if you're creating a patch against a wxWidgets SVN checkout, then you discuss and submit issues in the official wxWidgets communication channels; not on Kirix's forums where none of the official wxWidgets developers are going to see it.
You created this thread in Sept 2008, being well after the switch to Trac, and even mention the tracker issues the patches posted here address. So lets review...
Issues supposedly fixed by patches here as yourself and jjn mentioned earlier in this thread:
#3516 - No patch attached.
#3562 - No patch attached.
#3597 - No patch attached.
#3908 - No patch attached.
#4066 - Patch attached, awaiting review.
#4325 - No patch attached.
#4361 - No patch attached.
#4518 - Patch attached, awaiting review.
#4547 - No patch attached.
#4567 - No patch attached.
#4599 - No patch attached.
#9724 - No patch attached.
#9773 - No patch attached.
#9911 - No patch attached.
See what I mean? No patches available in these tickets to even look at reviewing to be applied to SVN trunk except for two tickets. Yet you and jjn claim that all of these issues have been resolved in your patches posted here. We do have an official process for getting patches applied to wxWidgets:
http://trac.wxwidgets.org/wiki/HowToSubmitPatches
This isn't entirely true. When you use the official channels, every official wxWidgets developer (including myself) sees these patches, and if it's simple enough and strait forward, other official developers will apply these patches (and I have done a few myself). We certainly rely on Ben to approve of larger, major patches as they often can affect/break other features of wxAUI that we aren't all familiar with, but nothing is stopping any official devs from taking the time to really look at even the biggest patches if they have the time. This is why you are encouraged to use the official tracker, not Kirix's forums.NinjaNL wrote:This might be all well and good, but Ben is the one who applies the suggested patches, and must OK them before they are applied.
Again, other official devs do see these tickets, especially when they already have a patch attached since it usually means much less work to take care of. Even when these patches aren't commented on right away, they are usually seen by at least a couple official developers, and many are filed away in their todo list even if they don't get around to them right away.NinjaNL wrote:Unfortunately opening trac items doesn't guarantee that they will be examined by Ben, or applied or even commented upon.
OK I'll concede much of what you say, but lets take a look at this patch.tierra wrote:#4066 - Patch attached, awaiting review.
All it is doing is changing a single line in the code
line 1122 is changed from "if (!p.IsToolbar())" to "if (!p.IsToolbar() && !p.IsFloating())"
A simple change, no? This patch was generated 22 months ago.
I am aware that even as simple a change as this can have repercussions, but come on....
The other which you mention as having a patch
Yet another "simple change", this one added 15 months ago.To make it work add at line 3500 in auibook.cpp
if (!evt.IsAllowed()) // event is no longer allowed after handler
return m_curpage;
I don't want to get into any sort of argument, as I have said repeatedly I am grateful for all the work that has gone into wxAui (as well as all of wxWidgets) and I do wish my coding skills were better so that I could help out more, but you must admit that if so simple a patch as these don't get any attention then what encouragement have we to pursue the matter? It does unfortunately generate a sort of apathetic reaction.
Still I will take what you say to heart and will generate patches for bugs I can solve, and report bugs to the trac in future. I must only admit that I don't have a great deal of expectation that these patches will be applied in the foreseeable future.
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/
- tierra
- Site Admin
- Posts: 1355
- Joined: Sun Aug 29, 2004 7:14 pm
- Location: Salt Lake City, Utah, USA
- Contact:
In the defense of wxWidgets here, neither of these two tracker issues were even properly marked as having patches (which I've now done, so if I don't get around to them soon, someone else probably will).NinjaNL wrote:I don't want to get into any sort of argument, as I have said repeatedly I am grateful for all the work that has gone into wxAui (as well as all of wxWidgets) and I do wish my coding skills were better so that I could help out more, but you must admit that if so simple a patch as these don't get any attention then what encouragement have we to pursue the matter? It does unfortunately generate a sort of apathetic reaction.
I know that. tierra, don't you understand what I said? One patch depends on other patches, so it is impossible to separate them. The following cycle is indispensable:tierra wrote:See what I mean? No patches available in these tickets to even look at reviewing to be applied to SVN trunk except for two tickets. Yet you and jjn claim that all of these issues have been resolved in your patches posted here. We do have an official process for getting patches applied to wxWidgets:
http://trac.wxwidgets.org/wiki/HowToSubmitPatches
post some patches -> apply them -> post some patches -> apply them -> ...
Maybe this is the right thread to ask:
Anyone knows a fix for this:
http://forums.wxwidgets.org/viewtopic.php?p=99055#99055
?
Windows XP, wx2.8.9
phlox
Anyone knows a fix for this:
http://forums.wxwidgets.org/viewtopic.php?p=99055#99055
?
Windows XP, wx2.8.9
phlox
I must say that I think the development of wxAUI needs a shake up. I submitted a patch for auto-notebooks about 2 years ago http://sourceforge.net/tracker/index.ph ... tid=309863, but it got rejected on ideallistic grounds. Which would be fair enough is something else was in the works, but not much has changed in that time.
I think there needs to be a period of expansion where functionality is increased significantly, perhaps at the expense of stability, otherwise this project will stagnate.
I think there needs to be a period of expansion where functionality is increased significantly, perhaps at the expense of stability, otherwise this project will stagnate.
I agree. I notice that the current state of wxAui is being commented upon.
Perhaps we should organise a wxAui bug/improvement week as was done previously with wxWidgets, and hope that Ben can make some time free to participate. Unfortunately I don't think that much will be done without his input.
Perhaps we should organise a wxAui bug/improvement week as was done previously with wxWidgets, and hope that Ben can make some time free to participate. Unfortunately I don't think that much will be done without his input.
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/
I meant "I can't imagine me not using it".tierra wrote:That's funny considering wxWidgets has a 16 year history before wxAUI was added. There were certainly tons of applications that used it without wxAUI.jacmoe wrote:wxAui is IMO an essential part of wxWidgets. I can't imagine not using it.
16 years?! Wow, that's a long time.
I use wxAui because it allows me to create good looking user interface with very little code.
Besides, wxAuiToolBar doesn't flicker, like wxToolBar does.
(Maybe it's me, but that's my experience).
- red_team316
- In need of some credit
- Posts: 1
- Joined: Sun Mar 08, 2009 3:29 am
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.
#3516 - Confirmed Defect, No patch attached, but linked to Kirix forum which contains it. patch needs made and patch needs to be set.
#4066 - Closed defect, fixed 2/13/2009
#4361 - Closed Defect, fixed 2/24/2009
#4518 - Patch attached, awaiting review.
#4567 - Confirmed Defect, No patch attached, but patch should be set. The explanation of the problem itself should suffice.
See what I mean? No patches available in these tickets to even look at reviewing to be applied to SVN trunk except for two tickets. Yet you and jjn claim that all of these issues have been resolved in your patches posted here. We do have an official process for getting patches applied to wxWidgets:
http://trac.wxwidgets.org/wiki/HowToSubmitPatches
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. 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?...
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 overrides
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?