Collaborative development environment

[280Z28]

I noticed that there is not currently an open development space for wxAUI. I really like the way wxAUI is headed and would love to contribute to the project. I think public Subversion access to the development version of wxAUI would be a big step forward.

May I suggest using Trac to give users easy access to bug reports, feature requests, user guides (wiki), and a copy of the sourcecode you can browse on the web? Since wxAUI is so new, now is the perfect time to start using Trac before you are stuck in another less attractive system.

I have Trac and Subversion set up right now, and could host the project with an initial checkin of wxAUI 0.9. Here is another open source project I am hosting on the Trac server (in a different directory), so you can see it work.

Without access to the latest development version of wxAUI, I won't know if the changes I make to it are just interferring with items you've already done. For example, I fixed a very simple bug where clicking the close button for a pane always closes the pane, even if you move the mouse away before releasing. You probably already fixed this yourself, but I don't know. I also added support for different active/inactive caption bar colors.

I'd like to help on the HUD feature as well. And auto-hide and overlapping window panes support.

BTW: We are now using wxAUI in Code::Blocks, because it is great!

[tenmon]

I think that a SVN repository would be good.

It may seem an overkill just for such little files, but it's a lot easier to create patches, because the patches will be against head, instead of a stable version.

[280Z28]

I think that a SVN repository would be good.

It may seem an overkill just for such little files, but it's a lot easier to create patches, because the patches will be against head, instead of a stable version.

Version control is never overkill. I use it for a project that's 1/10 the size of wxAUI.

I also think that the development version of wxAUI should be split up into multiple files by functionality that are easier to work with. Public releases can be collapsed into a "lite version" that only uses wxaui.cpp and wxaui.h and a full version that has all the individual files. These are all issues for after it's in svn though, not before.

[abligh]

Yes, SVN would be really nice. I already have 5 or 6 local patches here (sending them to Ben by email, then scraping his patches from a bulletin board system is not great).

Alex

[280Z28]

I'm going to set up a copy of Trac today with a mirror of my Subversion repository for wxAUI that will be available from over the web. You can use it at your option. If you don't use it, I guess I'll merge patches from here whenever I see them.

I'm also talking with "eranif" about incorporating his wxFlatNotebook project into wxAUI as the tab interface for stackable panes.

abligh, you'll be able to easily send your patches using the Trac interface. I also have instructions for how to do it on one of my other Tracs. You can find that here. Don't submit wxAUI patches to my LS2FireMod project by accident. I'll post the link to a wxAUI Trac home later today.

http://djss.dynalias.net/trac/LS2FireMo ... rsionRules

[280Z28]

http://djss.dynalias.net/trac/wxAUI

svn://djss.dynalias.net/wxAUI/trunk

I've made some small changes to the code in the trunk compared to the 0.9 tag (which is exactly 0.9 as downloaded from here).

[janknepper]

I think that a SVN repository would be good.

It may seem an overkill just for such little files, but it's a lot easier to create patches, because the patches will be against head, instead of a stable version.

Version control is never overkill. I use it for a project that's 1/10 the size of wxAUI.

I also think that the development version of wxAUI should be split up into multiple files by functionality that are easier to work with. Public releases can be collapsed into a "lite version" that only uses wxaui.cpp and wxaui.h and a full version that has all the individual files. These are all issues for after it's in svn though, not before.

Since wxWidgets/wxWindows which is the base for wxAUI is on sourceforge I doubt if it is truly a good idea to go anywhere else but sourceforge.

I agree SCC is always good for anything like this.

I agree wxAUI's classes probably should be separated into several files to make SCC maintenance easier.

[280Z28]

wxWidgets may be the base for it, but SourceForge is a pain and doesn't offer Subversion (which is unquestionably better than CVS). Trac is a clean system but not perfect. I'm going to keep my copy up and merge in changes as they appear elsewhere (like the 0.9.1 changes that are about to be released). I have some new stuff in the works though that you won't find anywhere else.

[Ben]

I agree wxAUI's classes probably should be separated into several files to make SCC maintenance easier.

For the frame docking stuff, probably not. The idea of wxAUI is to have a bunch of very independent user interface classes which can be used together. For instance, when we do have a nicer toolbar control, programmers will be able to use them independently of the docking stuff, and vice-versa.

Please keep in mind that the frame docking code is not even 4500 lines of code (header and cpp file). Compare that to wx's grid component, which is 12,000 lines of code, in just a CPP and a header.

Because wxAUI may someday be integrated into wxWidgets itself, we don't want to make that integration more complicated than necessary.

[Infinity77]

For the frame docking stuff, probably not. The idea of wxAUI is to have a bunch of very independent user interface classes which can be used together. For instance, when we do have a nicer toolbar control, programmers will be able to use them independently of the docking stuff, and vice-versa.

Please keep in mind that the frame docking code is not even 4500 lines of code (header and cpp file). Compare that to wx's grid component, which is 12,000 lines of code, in just a CPP and a header.

Because wxAUI may someday be integrated into wxWidgets itself, we don't want to make that integration more complicated than necessary.

I perfectly agree with Ben. Splitting it in separate files will only increase problems when you need to modify things and finding bugs.

Just my 2c.

Andrea.

[janknepper]

wxWidgets may be the base for it, but SourceForge is a pain and doesn't offer Subversion (which is unquestionably better than CVS). Trac is a clean system but not perfect. I'm going to keep my copy up and merge in changes as they appear elsewhere (like the 0.9.1 changes that are about to be released). I have some new stuff in the works though that you won't find anywhere else.

CVS v.s. Subversion is personal opinion.
Just do a search on the internet and you will find about gnuarch which is supposed to beat all... http://wiki.gnuarch.org/SubVersionAndCvsComparison

Anyone can keep a copy of Open Source anywhere. That's the great thing about it.

The reality is however since wxWidgets currently is in CVS you would lower threshold by placing wxWidgets extension source in the same SCC. Just my opinion.

[janknepper]

I agree wxAUI's classes probably should be separated into several files to make SCC maintenance easier.

For the frame docking stuff, probably not. The idea of wxAUI is to have a bunch of very independent user interface classes which can be used together. For instance, when we do have a nicer toolbar control, programmers will be able to use them independently of the docking stuff, and vice-versa.

Please keep in mind that the frame docking code is not even 4500 lines of code (header and cpp file). Compare that to wx's grid component, which is 12,000 lines of code, in just a CPP and a header.

Because wxAUI may someday be integrated into wxWidgets itself, we don't want to make that integration more complicated than necessary.

I thought I wrote wxAUI classes... (please read!) Which I suspect in the future will be a LOT more than the frame docking stuff that now exists in one header and one source file. Stuff that works interdependent probably should be in the same header+source, unless it contains common code used by other parts of wxAUI. Just my opinion.
If it works well and stays stable I will use it anyways... Otherwise... well will have to go somewhere else...

Integration into wxWidgets probably means integrated into the contrib directory where FL currently exists for example.

[Ben]

I thought I wrote wxAUI classes... (please read!) Which I suspect in the future will be a LOT more than the frame docking stuff that now exists in one header and one source file.

Probably my misinterpretation. Right now wxAUI == frame docking, so I can see how I read it that way. When toolbars get written, they will undoubtedly be placed in a separate file.

All the best,
Ben

[janknepper]

Probably my misinterpretation. Right now wxAUI == frame docking, so I can see how I read it that way. When toolbars get written, they will undoubtedly be placed in a separate file.

NP... I noticed I hit quote button in the wrong message...
Sorry about that...