wxAUI 0.9.2 released - docking/toolbar library for wxWidgets

[bwilliams]

Hi all,

I'd like to announce the availability of wxAUI 0.9.2 for download.

wxAUI is an Advanced User Interface library that aims to implement
"cutting-edge" interface usability and design features so developers can
quickly and easily create beautiful and usable application interfaces.
The centerpiece of the library is a docking manager which allows windows
to be floated/docked onto a frame.

This is our third release of the library. The first two releases, version 0.9 and 0.9.1, provide support for native, dockable floating frames, toolbars incorporating

[upCASE]

Great stuff!
This should definitely be added to the normal distribution or as a contrib.

[phlox81]

Please use namespaces, when setting up such a library.
For Example one of your classes is named wxFrameManager,
this could lead to a naming Conflict, even if their is today no
wxClass named like this.

phlox

[SnakeChomp]

Although wxFL, wxIFM and wxDockIt each offer their own advantages, some quite significant, neither wxFL nor wxIFM supported native floating windows, so they were not adequate for our needs.

It is unfortunate that you considered this point as enough to start another docking library, and while I was trying to think of something to say to prove this point false, I see that I cannot as I realize what you mean when you say "native floating windows" now. There was nothing stopping wxIFM from supporting them as you do, so I am disapointed that you instead chose to rewrite the wheel (again) instead of giving an existing one another spoke.

Criticisms

Docking as tabs? Why not? Tabs are an indespensible resource for interface management and any advanced docking library should be able to handle them IMO.

Docking feedback: Highlighting the entire container blue to signify that you will dock into a brand new row is extremely counter intuitive. The alpha blue box thing should be drawn in the position that the new row will occupy. I played around with the demo app for win32 more and I now see why I am having such trouble with this. Open the demo, switch to the all panes perspective. Trag the "Tree Pane" from the left underneath the "pane caption" which is at the top. The entire "pane caption" is highlighted blue. Release mouse. What happens? "Tree Pane" is above the "pane catpion". I didnt want it above it! I had the mouse below the pane caption, I wanted the component to be below the pane caption. It gets worse: drag the "client size" pane on the right underneath the "Pane Caption". Now the entire "Tree Pane" is highlighted blue, and releasing the mouse puts the "client size" pane against the top of the frame where the "Tree pane" was. This is completely not what I expect to be happening. It should have placed the client size pane beneath the existing panes, not above them.

Bugs

Switch to all panes perspective. Resize the "Client Size Reporter" by dragging the resize grip down as far as you can go, as in drag the mouse right to the bottom of the screen area. The panel is now so tall that you can't even see the "Tree Pane" anymore, and the resize grip for the client size reporter is off of the screen so its impossible to make the client size reporter smaller.

There is also a display artifact underneath the toolbar which has "item 1 | item 2 | item 3 | item 4 ...". The "Test Button" toolbar is making the row taller than the "item n" toolbar and there is residue left underneath the "item n" toolbar because its shorter than the "test button" toolbar.

Stuff I like...

The alpha blended fade in out blue preview boxes look nice. Not sure how you did them (didn't look at source yet) but if they are done in wxWidgets API and function the same under linux I would be impressed.

...and stuff I don't

The alpha blended fade in out blue preview boxes still require me to blindly move the mouse around until I manage to get it located in the hidden "magical spot" that does what I want. This is no better than dragging around XOR rectangles, it just has a different coat of paint. I believe microsoft is headed in the right direction with its "drop target" buttons (my terminology) which wxIFM faithfully duplicated.

It is clear to me that you have many more resources than I do to be able to come up with this system in far less time than it has taken wxIFM to do so. You probably have a team of payed coders on this project, which would explain its rapid development and professional appearance. I consider myself highly interested in interface design, and the "good interface design" side of me highly respects your work. I am saddened however, as if the necessary omitted features are added (tabs) this docking library will most likely replace wxIFM (as if wxIFM was already in widespread use ). It is both a disapointment and a relief for me to say it, but I know when I've been beat. Good work guys.

[buildere]

It is unfortunate that you considered this point as enough to start another docking library, and while I was trying to think of something to say to prove this point false, I see that I cannot as I realize what you mean when you say "native floating windows" now. There was nothing stopping wxIFM from supporting them as you do, so I am disapointed that you instead chose to rewrite the wheel (again) instead of giving an existing one another spoke.

Arrrrrgh!!!! That's what I don't understand about open source.... You have the sources, the idea is anyone can contribute.... why this happens again and again and again?

Anyway, wxAUI looks good.

[ABX]

Arrrrrgh!!!! That's what I don't understand about open source.... You have the sources, the idea is anyone can contribute.... why this happens again and again and again?

You could say exactly the same about wxFL, why wxIFM was started if wxFL existed and could just be contributed with lots of patches? And why wxDockIt then? Lots of reasonable explanations come to my mind, from "not being able to have patches applied" through "I need it for own project and license does not fit" to "I need it quickly in form which doesn't exist for own project, will develop further later". I don't think any is catastrophe which deserves "Arrrrrgh". Looking on the bright side, it's nice to have a choice.

ABX

[upCASE]

Arrrrrgh!!!! That's what I don't understand about open source.... You have the sources, the idea is anyone can contribute.... why this happens again and again and again?

Because it's a "can", not a "must".
True, the general idea and ideal world would be, that all coders unite in creating a unique new thing where everyone contributes the best of his knowledge to it. But the thruth is, that
1. not everything can be unique
2. not everyone likes to team up
3. not everyone likes to do work on only one part of the whole thing
4. the challenge in creating such a thing and the reward lead to splitting projects or new projects

In addition there are things of more "personal" nature. Not everyone will spend an equal amount of time, like the coding style etc. Then again a problem is, that with existing projects it can be hard to join.
1. The coding rules are set
2. The goal is set
3. The code base is allready there
4. The code base might allready be so huge that you can't get it in a few moments.

So before reading and modifying the source, one may start his own project, just because he has something similar, but not the same in mind. Look at the amount of GUI editors for wxWidgets. If they would all team up, there would be something fast. But: The general idea, layout, etc. of each editor is different. You can't simply merge all the good things. I myself started work on an editor, just because the source of the others and their "idea" didn't suit my needs. I wanted something different. True, it is a "bad" idea considering the time and critisism ("Editor blah allready has that, why don't you use it?"). But the result will be what you expected.

I like to have a choice in what I do and what I do it with. One may find wxDockit more convenient, the other wxAUI, the next wxIFM. What'S so bad about that? The only drawback I see, is that it is sometimes hard to find what you need. Not everything is listed in wxCode, or is in the contribs.

My point of view: It's not about "being better" or "showing others how to do it right", but to do it the way one needs it and publish it, so that everyone can benefit from it.

And if someone creates a new project, one shouldn't take that personal.

[buildere]

You could say exactly the same about wxFL, why wxIFM was started if wxFL existed and could just be contributed with lots of patches? And why wxDockIt then?

Yeah, that's my point. See, thats why I wrote "again and again and AGAIN. I realize this would happen, but why SO MANY TIMES?

I don't think any is catastrophe which deserves "Arrrrrgh". Looking on the bright side, it's nice to have a choice.

I love to have choice, but to me, in open source the excess of options sometimes turns into clutter. That hurts both open source projects and users (specially newbie ones), for the following reasons:

- Look at the general view about open source projects: you'll find that in most instances, the "boost" in terms of amount of time spent in the project happens in the initial stagest of it. After some time, the tendency of almost all projects is to be left abandoned, with the exception of big succesfull projects. So the equation is simple: More new duplicated projects instead of co-work on old ones = less chances that a single project turns succesful. And the winner is: not open source software, not the users.

- People will always try a couple of choices, and will likely stay with the first one the feel comfortable with. People doesn't like to waste time triying too many different things. That's a marketing reality most companies know well, but they can overcome this by using advertising when introducing new products, something OSS can't do. So, more options = less attention to your project, wich ultimately is the fuel that powers most OSS projects. Who wants to spend time tunning a program that nobody uses?

- Look at SnakeChomp's case for instance. How much time and effort has he spent on his project? Now as he said, there is a chance that all that work turns wasted, simply because wxAUI looks better and may take away a lot of attention form it. Will SnakeChomp feel as entusiast about contributing to the OSS scene in a future project? I don't think so. How would wxIFM looked like if all the work spent on wxAUI would be used to improve wxIFM? As you said, maybe the same can be said about wxIFM.

The thing is, I love open source, I like choices, and I realize there will always be duplication of work, that's inevitable. I also know there are good reasons for this to happen, like the ones upCASE described (I even joined a project -wxdevcpp- that was not the first one of its class). But there are also bad reasons for this to happen:

1- The autor of the new project is just too ego-centric to work in teams.
2- The autor is just lazy, and didn't want to spend a couple of minutes learning about an old project and contacting its creators, so he prefered to reinvent the weel, clutter the options space with a new project that will divert attention from others and "probably" end abandoned anyway after some time because its laziness and lack of social skills to delegate work and communicate with its users.
3- The current project owner is a moron, and doesn't like new ideas that differ from his view, so every one prefers to start its own project instead of joining him.

I think duplication of projects is good when there are good reasons for it. For instance, wxdevcpp is arguably the best wxIDE so far, but I think an IDE written in C++ like code::blocks, must have a RAD tool also, because that's the native wxWidgets language, because it can be multiplatform, etc. The problem I see is when the reason is just "well, I just prefered to start my own project". Happily, there is freedom for people to start 10000 projects that do the same thing, I recognize everyone is free to spend their time in the way they want, but in the meantime, I will spend mine ranting about that.

[bwilliams]

SnakeChomp,

Thanks for your feedback. You raise some good points about wxAUI version 0.9, particularly that it doesn't support tabs or HUD drop targets, both of which wxIFM supports. Although we don't know for certain all the features we'll implement, we've put together a project roadmap that presents features we would very much like to add: http://www.kirix.com/en/community/opens ... admap.html

That said, we're very sympathetic to your real concern: why did we create wxAUI when we could have contributed to wxIFM? As we've already mentioned, we wanted our applications to have native floating windows. For example, take a look at a one of our software products, Kirix Strata, at http://www.kirix.com/en/products/strata ... index.html and click on the "Relationship Result" screenshot. You can see an example of a dockable, floating window using wxFL that is not native. Personally, we just prefer how native floating windows look in cross-platform apps. We also desired some other functionality, including better toolbar behavior with "rebar" functionality and "chevron" support.

Furthermore, after debugging wxFL and creating patches for several years, we were still having significant difficulty working with its API and plug-in architecture, raising the important issues of library scope and design. For our own applications, we required interface features others might consider beyond the scope of a frame-docking library, and we needed a design that 1) did not use a plug-in architecture so we could avoid code complexities and related debugging issues and 2) exposed functionality with a clear API to allow rapid, easy use of the library.

Perhaps we could have extended wxFL, or for that matter wxIFM, to support these features and design. However, based on our experience, we believed our best alternative was to implement a new library that encompassed all of these things from day one. Hopefully, giving wxAUI back to the community may help others who have similar needs.

All the best,
Benjamin I. Williams
Kirix Corporation

[ABX]

Look at SnakeChomp's case for instance. How much time and effort has he spent on his project? Now as he said, there is a chance that all that work turns wasted, simply because wxAUI looks better and may take away a lot of attention form it. Will SnakeChomp feel as entusiast about contributing to the OSS scene in a future project? I don't think so.

Well, let me tell you some other story: since more than ten years there are well known two open sourced multiplatform C++ GUI libraries with large code base, lots of testers/users, many bugs fixed, hundreds of patches/improvements applied and... some day small group of programmers decided to create completly new GUI library. Why? Because they say about existing libraries:
1) API is not easy to use
2) templates and namespaces are not used
3) own solutions are used instead of reusing things like boost
4) ports are in different states of implementation and has different interface
5)binary backward compatibility is not supported

One could wonder why these developers started writing own GUI library rather than help wxWidgets to change this situation and:

ad 1) point where API is not easy
ad 2) participate discussion and development of wxTNG (wxWidgets The Next Generation aka 3.0 based on modern C++)
ad 3) provide boost wrappers within wxCode for some wxWidgets components to easy transition
ad 4) list all interface differences and help complete them
ad 5) point binary compatibility problems (which is supposed to work with 2.6.X AFAIK)

Do you think wxWidgets core developers should take it personally and be irritated? Do you think that knowing bad sides of wxWidgets should force wxWidgets developers to stop their development because new library will be better?

Or

Do you think authors of new library should stop their work and only contribute to wxWidgets? Do they waste their time? Do they duplicate effort? Should wxWidgets developers take personally the fact of new library creation? Try to find developers of OMGUI (they are close) and ask them. I do not have need for it. That's their choice and their freedom.

Sorry for so long off-topic. Hopefully you see similarities in situation.

ABX

[buildere]

Personally, I don't see a problem with people making an improved version of a well stablished project. In this case, I see wxWidgets as a mature toolkit, so any new project that mimic its goal can do no harm to it. The only way wxWidgets could be threatened is if the new project turns out to be better than it, but at that point, the final user is not affected since now he has better options, and also, wxWidgets was used enough to make all the work worth the effort. In the other hand, I find annoying having like 10 different beta projects that try to reach the same goal, everyone half done due to the lack of support of enough developers, and yet seing a new project born with the same goal again.

Ok, as I said, this is just me ranting a little, I anyway wish the wxAUI devels and SnakeChomp the best luck with their projects, and I thank them for their hard work.

[SnakeChomp]

ABX: I have split my reply to your post into this new thread: http://forums.wxwidgets.org/viewtopic.php?p=26026#26026

[Ryan Norton]

[this is bit of rambling ]

In response to buildere, the fork thing is sort of a problem with OSS in general is that there are no "owners" of the code, or rather it's owned by a lot of people who will never be tracked down. So, in turn you have a lot of people writing code from scratch due to licences etc..

It's the same thing with existing APIs in that modifying someone else's code is inheritly a difficult thing to do. That's why there are all these docking/interface libs, for instance. Sure, the API's themselves are imperfect (and I'm sure the authors would agree), but it takes something special to design a lib with a new paradigm that a lot of people will like. It's more of a "whichever gets less complaints is better" kind of thing. I think CoreFoundation by Apple is a popular one, for instance, but that is relatively limited in scope and the implementation might turn off some people.

People like things that they already know, that's why many people who use MFC and wx a lot of times don't find the "deficiencies" that a lot of other people do because the wx API is a lot like the MFC API (which some percieve as "bad").

So, in the guise of that I would point out that I really don't like these "manager" classes that both wxIFM and wxAUI have AFAIK - I'd really like to just used a derived wxFrame or some kind of sizer thing. Manager classes are generally best used for os-specific things IMHO.

[bwilliams]

So, in the guise of that I would point out that I really don't like these "manager" classes that both wxIFM and wxAUI have AFAIK - I'd really like to just used a derived wxFrame or some kind of sizer thing. Manager classes are generally best used for os-specific things IMHO.

The reason the wxFrameManager class exists is simple: To do all pane management in a wxFrame-derived class would make the functionality difficult or impossible to use with a wxMDIParentFrame class.

If the functionality is implemented in a separate wxFrameManager, as it is, then the functionality can be completely contained there, and applied to any wxFrame or wxMDIParentFrame (or any other type of wxFrame-derived frame, like wxMiniFrame).

As a general rule, object composition should be preferred over class inheritence, because this makes the functionality much more mobile.

That said, we are considering including some convienience classes in a future release, maybe calling them something like wxDockFrame and wxMDIParentDockFrame (these names probably won't stick-- they are just here for example). These two classes would contain the wxFrameManager functionality (via composition), so the programmer doesn't have to bother with it.

If what you are saying is true, why does wxWidgets have a separate wxSizer class instead of including that directly in wxFrame? I think there are good reasons for this separation. wxAUI's wxFrameManager class is very analogous to wxSizer, and for this reason the present design was chosen.

All the best,
Ben

[metalogic]

I'm afraid this post won't add anything new other than to voice my opinion that I'm also on the "colaborate, don't rewrite" camp.

There are some good opinions in this thread about why you should rewrite and I can't say I fully disagree. I think when there is a fundamental reason why changing is not feasible (someone mentioned Code::Blocks vs. wxDevCpp as the later is written in Delphi) then I have to agree that a rewrite is needed.

But wxIFM is fresh out of the oven. Certainly it can't be so bad that a few patches couldn't add the native floating Window? So in a case like this, I find it hard to justify a new project.

Someone also said they liked the options given by multiple projects. I think that's a fallacy. Sure, I have 37 different libraries to choose from, but is that really choice? If each of the 37 libraries has something that the others don't have but at the same time is missing something that the others do have then it's not so much a choice as a compromise. I would much prefer having 1 or maybe a (very) few choices where a larger pool of developers contributes and thus that library gets all of the features and I don't have to compromise.

Lastly, I have to agree that SnakeChomp is guilty of the sin he is accusing wxAUI of

Now that I said all that, just want to add that anyone releasing a new library for wxWidgets has all my appreciation whether the library fills a gap or reinvents the wheel (OK... the reinvent the wheel guys just get slightly less love )