wxAUI Improvements

Do you like to promote your wxWidgets based application or component!? Post it here and let's see what the critics have to say. Also, if you found that ONE wx component the world needs to know about, put it here for future reference.
madnut.ua
Knows some wx things
Knows some wx things
Posts: 31
Joined: Fri Dec 08, 2006 10:49 pm
Location: Ukraine
Contact:

Post by madnut.ua » Fri Oct 10, 2008 8:34 pm

jjn wrote:This is the third test release.
Thanks for this.
I've made a little changes for compiling with mingw/gcc 4.x
Find patch file attached.

Also I've found a bug with resizing frame by splitter when main window is not on the top/not focused (e.g. other window or modeless dialog appears in front of this one). Application crashes when try to move splitter of main window.
Workaround patch file attached
Attachments
aui_patches.zip
mingw/gcc 4.x compilation fixes + workaround patch for splitter bug
(1.73 KiB) Downloaded 139 times

jjn
Earned a small fee
Earned a small fee
Posts: 21
Joined: Tue Sep 30, 2008 11:31 am

Post by jjn » Sat Oct 11, 2008 2:02 am

madnut.ua wrote:
jjn wrote:This is the third test release.
Thanks for this.
I've made a little changes for compiling with mingw/gcc 4.x
Find patch file attached.

Also I've found a bug with resizing frame by splitter when main window is not on the top/not focused (e.g. other window or modeless dialog appears in front of this one). Application crashes when try to move splitter of main window.
Workaround patch file attached
Applied. Thanks for the patches.

jjn
Earned a small fee
Earned a small fee
Posts: 21
Joined: Tue Sep 30, 2008 11:31 am

Post by jjn » Mon Oct 20, 2008 2:39 am

I cannot solve this problem. Can anyone help with this?
http://trac.wxwidgets.org/ticket/10008

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Wed Nov 12, 2008 12:59 pm

I have implemented a simple minimize pane system.

This is built upon the AUDemo3 sources, but it should be implementable against 2.8.9 or whatever. A little time with WinMerge or something like it will result in usable code.

I also changed the wxArtProvider source, by adding a new bitmap, and references to it.

Hopefully this will help others and perhaps they can expand upon it.

I don't think I missed anything, but if there is a file missing let me know.

Mal
Attachments
AUITest3.rar
(136.01 KiB) Downloaded 168 times
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

jjn
Earned a small fee
Earned a small fee
Posts: 21
Joined: Tue Sep 30, 2008 11:31 am

Post by jjn » Fri Nov 14, 2008 2:53 am

NinjaNL wrote:I have implemented a simple minimize pane system.

This is built upon the AUDemo3 sources, but it should be implementable against 2.8.9 or whatever. A little time with WinMerge or something like it will result in usable code.

I also changed the wxArtProvider source, by adding a new bitmap, and references to it.
Hmm... It seems not to be usable with 2.9.0.
I do not recommend that you change the code outside of wxAUI, because that makes the problem of the version compatibility more serious.
(For the same reason, I cannot change the code of sizer.cpp to fix #10008.)

Anyway, thanks for your work.

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Fri Nov 14, 2008 4:17 am

jjn wrote:
NinjaNL wrote:I have implemented a simple minimize pane system.

This is built upon the AUDemo3 sources, but it should be implementable against 2.8.9 or whatever. A little time with WinMerge or something like it will result in usable code.

I also changed the wxArtProvider source, by adding a new bitmap, and references to it.
Hmm... It seems not to be usable with 2.9.0.
I'll look into this.

jjn wrote:I do not recommend that you change the code outside of wxAUI, because that makes the problem of the version compatibility more serious.
(For the same reason, I cannot change the code of sizer.cpp to fix #10008.)

Anyway, thanks for your work.
All I am doing is adding a bitmap to wxArtProvider.

Any other method of adding a bitmap to the toolbar should also work.
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Fri Nov 14, 2008 3:47 pm

jjn wrote:
NinjaNL wrote:I have implemented a simple minimize pane system.

This is built upon the AUDemo3 sources, but it should be implementable against 2.8.9 or whatever. A little time with WinMerge or something like it will result in usable code.

I also changed the wxArtProvider source, by adding a new bitmap, and references to it.
Hmm... It seems not to be usable with 2.9.0.
For some reason building a default svn HEAD build (note that this means unicode is turned on) seems to result in losing any wxAuiPaneInfo.name or wxAuiPaneInfo.caption data.

I rely on this information for the working of the minimize code.

Anybody got any ideas why this is?
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Fri Nov 14, 2008 8:55 pm

I seem to have it working again, this time with pure SVN HEAD, not with jjn's enhancements, also without needing wxArtProvider changes.

You also need the xmp, save it to include/wx/aui/restore.xpm

Code: Select all

/* XPM */
static char * restore_xpm[] = {
"16 15 3 1",
" 	c None",
".	c #000000",
"+	c #FFFFFF",
"                ",
"     .......... ",
"     .++++++++. ",
"     .......... ",
"     .++++++++. ",
" ..........+++. ",
" .++++++++.+++. ",
" ..........+++. ",
" .++++++++..... ",
" .++++++++.     ",
" .++++++++.     ",
" .++++++++.     ",
" .++++++++.     ",
" ..........     ",
"                "};
See if this works for you now.
Attachments
minimizepatch.rar
(4.47 KiB) Downloaded 127 times
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

orbitcowboy
I live to help wx-kind
I live to help wx-kind
Posts: 178
Joined: Mon Jul 23, 2007 9:01 am

Post by orbitcowboy » Sat Nov 15, 2008 10:11 am

Hi,

what are the key features of your AUI improvements? Or containts it still bug fixes ?

Orbitcowboy

BuschnicK
Experienced Solver
Experienced Solver
Posts: 80
Joined: Thu Oct 13, 2005 1:30 pm
Contact:

Post by BuschnicK » Fri Feb 06, 2009 8:11 pm

Why aren't these patches part of the official trunk?

Any plans on implementing layout persistence for AuiNotebooks? How about ripping notebook pages out and making them their own AuiPanels (I'm very interested in this feature in order to tear notebook pages off and move them onto another monitor, something that isn't possible currently)?

cheers,

Sören

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Post by tierra » Fri Feb 06, 2009 9:24 pm

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.

None of the official developers have time to go through forum posts like this or even wx-dev mailing list posts and do the work of breaking up and applying these patches when there's an official process to how these are supposed to be submitted and applied.

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.

Infinity_77
Experienced Solver
Experienced Solver
Posts: 89
Joined: Tue Oct 03, 2006 6:30 pm
Location: London, UK
Contact:

Post by Infinity_77 » Fri Feb 06, 2009 11:06 pm

tierra wrote:
BuschnicK wrote:Why aren't these patches part of the official trunk?
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.
Sometimes it doesn't look like this, unfortunately:

http://trac.wxwidgets.org/ticket/10466

But I agree with tierra, I very deeply strongly emphatically encourage everyone of you to submit your useful patches to the wxWidgets trac. The wxPython community will be more than grateful for this.

Andrea.
"Imagination Is The Only Weapon In The War Against Reality."

http://xoomer.alice.it/infinity77/

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Sat Feb 07, 2009 9:39 am

tierra wrote:
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 upon.

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.
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

BuschnicK
Experienced Solver
Experienced Solver
Posts: 80
Joined: Thu Oct 13, 2005 1:30 pm
Contact:

Post by BuschnicK » Sat Feb 07, 2009 11:29 am

Amen brother. I'm using wxWidgets for paid consulting work and thus have a limited amount of time I can spend on improving the library instead of the actual projects I'm working on. As a tentative test for how the patch system works I committed a small patch to trac which took 4 months to be accepted. So the patch review process is very laggy and dragged out.

I understand this is an open source project and depends on voluntary time committments but nevertheless - this state of affairs is bad. It sucks away the motivation to contribute. I think an all out, "lets clean up wxTrac and do nothing else" patch week would be in order.

My local wxWidgets checkout is deviating from trunk more and more because of this. I often don't bother committing patches because it'll simply take too long.

Question is: How can this be improved? Is it because of a lack of time of the primary maintainers? Would money help (i.e. paid work on wxWidgets?)?

sorry for the rant - don't get me wrong - wxWidgets is great and my project would not have been possible without it. I am really grateful for all the work volunteered to it.

cheers,

Sören

NinjaNL
Moderator
Moderator
Posts: 899
Joined: Sun Oct 03, 2004 10:33 am
Location: Oosterwolde, Netherlands

Post by NinjaNL » Sat Feb 07, 2009 12:43 pm

BuschnicK wrote:Question is: How can this be improved? Is it because of a lack of time of the primary maintainers? Would money help (i.e. paid work on wxWidgets?)?

sorry for the rant - don't get me wrong - wxWidgets is great and my project would not have been possible without it. I am really grateful for all the work volunteered to it.
As am I, and perhaps a wxWidgets BugWeek, as has previously been done, would be a starting point.

Unfortunately I don't think that this would help AFA wxAui goes since the one who currently has write access and is "godfather" to wxAui may not have the time to spend on wxAui/wxWidgets when the bugweek runs.

What I think might help is as I stated above a development wxAui branch, then we as users/developers could maintain a developers wxAui library which would be tested and improved.

Once a patch has been applied to the development branch and has been tested (I assume there would be several wxWidgets developers who would be nominated for this) and approved by the wxWidgets wxAui testers, that either the patch would be sent to Ben Williams for a simple (dis-) approval or that another wxWidgets senior developer (Vadim/Julian/???) would take it upon themselves to look into and apply the patch.

I do hope that something happens wrt the development of wxAui, either that Kirix appoint another developer to investigate the patches and apply as necessary maintaining a "constant" improvement of the library, or that the wxWidgets developers implement some other system whereby Ben maintains his authority over the "official" wxAui library, but also allows a speedier responce time wrt patches/suggestions/improvements/bug fixes.
Follow the development of my screenplay authoring program at http://wxscreenplaywriter.blogspot.com/

Post Reply