BuschnicK wrote:Why aren't these patches part of the official trunk?
Because none of the original developers that wrote these patches bothered to post them to their relevant tracker issues they fixed, nor broke the new features up into separate patches that could be applied easily where they could each be tested.
No-one here that has re-posted these patches bothered to do this either.
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)
Ben Williams has recently stated on the Dev-List IIRC that his time on wxWIdgets related matters comes in fits and spurts, which is understandable considering his companies other project, and sometimes he has a five month wait between "wxwidgets periods".
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.
I would be happy with simply someone from Kirix monitoring the trac system and at least looking at patches/bugs when they are reported, offering some sort of answer within a week. Waiting months before we hear anything
doesn't create any sort of warm fuzzy feeling wrt our suggestions/bugs/improvements.
Unfortunately waiting 5 months before I know if my patch is good enough or not is a bit of a long wait.
I know I am not as good a coder as others, but I managed to solve the first big bug (maximize problem with upper and lower panes), have managed to implement a simple pane minimize process (does't work with centre panes but all other (floating) panes seem to work OK, managed to offer a patch to cater for toolbar orientation switching), and offered several other patches .
What jjn did was combine several patches from the Kirix forum into a single "unofficial" implementation. (Again, Kirix wanted the patches suggested on their forum - not the official SF tracker or the Trac system), and to an extent should be commended for it.
What I would like to see is a second "development" AUI branch where someone other than the Kirix staff have write access, where a more experienced wxWidgets developer could apply the patches and we as a user group could download and use/debug.
I know that we can maintain a local copy of the aui library (using e.g. the jjn package) but offering an official wxAui development branch would IMO speed up the development of wxAui and increase it's usability. (how many applications offering a docking system maintain toolbar switching? Does wxAui offer this? Should it?)
I think offering a development wxAui branch would benefit everyone. Someone other than Ben could investigate and apply patches, Ben could, when he has "wxWidgets time", then examine the current state of development wxAui decide which patches have been applied to the development branch that he wants to apply to the release branch, we as developers would see "improvements" in wxAui after patching and can test and debug what has happened, so the patches would be more vigorously tested than they are now etc.
Unfortunately opening trac items doesn't guarantee that they will be examined by Ben, or applied or even commented
I do understand Ben's desire to maintain the code, and keep a tight hold on the rains so that it doesn't become another wxFL, and should be commended for it. Unfortunately it also means that because he doesn't seem to have the time to investigate the suggestions/patches, the rest of us (and more so those who are just busy developing their own projects USING wxAui) feel that wxAui development seems stagnant.
What is worse IMO is that I personally get the impression that we are ignored
by Kirix because of the long delay and non response. I know that this is not the case and that the Kirix developers and Ben are busy, but unfortunately the delay in responding to suggestions/bugs/patches does cultivate this feeling.