wxAUI evaluation

[mandrav]

Well folks, in order to evaluate wxAUI, I created a branch named "aui_test".
It was an easy drop-in replacement instead of wxDockit and works just fine
Additionally, I implemented saving of view layouts and switching between them. It was a breeze to do this with wxAUI.
I 've been using/testing it all afternoon and it works flawlessly. Not to mention we 're not using binary data to save the layouts anymore .

So, if anyone wants to test-drive it before merging it to HEAD, here's your chance. Just switch your working copy to /branches/aui_test instead of /trunk and build it.

[Ceniza]

Ok, I'll do

[Ceniza]

Ok, I built it and looks promising, but it isn't saving or loading any layout (you said you implemented that, so where did you hid it?).

The second problem is the toolbars are a bit bigger than the space assigned for them when icons are 32x32, and smaller when 16x16. In the first case it's painting a few extra pixels, in the second case it isn't painting all pixels (the ones at the bottom), and, also for 16x16, the space for the toolbar is larger than needed.

I suppose those are wxAUI problems, right?

[attachment deleted by admin]

[280Z28]

I'll try this out. The wxAUI sample app worked great. That's cool that it was easy to integrate!

[thomas]

The toolbars flicker like crazy while being dragged, and I can confirm Ceniza's spacing issue.
As a sidenote, the grey dock window titles are a bit boring (but that is certainly tunable).

Apart from these few issues, there is only one word to describe it... great
Very intuitive, and the blending effect when dragging is quite cool.

[280Z28]

I get some flicker, but I only "noticed" it once I was looking for it (after seeing your post). I guess it would bother me if I moved toolbars more, but I don't (just once to set them up).

[takeshimiya]

A new SVN C::B branch can be created for testing wxAUI in the meantime.

As for wxAUI, it's good that we'll can (with relative easyness), solve any of it's glitches ourselves, because I can't call it a "library", being only a h/cpp (hey, even tinyxml is more bigger ).

Going to test now.

[mandrav]

The flickering is a C::B problem and is probably happening because of the UI update handlers.

[280Z28]

Do you think we will end up switching to wxAUI in the trunk?

I've already fixed some bugs in my local copy and implemented active/inactive windows.

[mandrav]

Do you think we will end up switching to wxAUI in the trunk?

Quite possibly, yes.

I've already fixed some bugs in my local copy and implemented active/inactive windows.

Do you care to explain?

[takeshimiya]

Just for the record, the next version (1.0) will address:
    * Add "chevron" button support for toolbars that become partially hidden off screen
    * Add hide/show control for docked panes
    * Fix minimum/maximum size issues
    * Optimize frame docking hint locations and mouse drop locations
    * Streamline the "feel" of frame and toolbar dragging
    * Fix various drawing glitches and toolbar instability

[280Z28]

Do you think we will end up switching to wxAUI in the trunk?

Quite possibly, yes.

I've already fixed some bugs in my local copy and implemented active/inactive windows.

Do you care to explain?

If you click the close button with your left mouse button, then move off the button before letting the mouse button up, the close button will not be highlighted but the pane still closes. I fixed that.

I made the default caption colors for inactive panes wxSYS_COLOUR_INACTIVECAPTION and for the active pane wxSYS_COLOUR_ACTIVECAPTION. Nothing too special about that part.

[280Z28]

Just for the record, the next version (1.0) will address:
    * Add "chevron" button support for toolbars that become partially hidden off screen
    * Add hide/show control for docked panes
    * Fix minimum/maximum size issues
    * Optimize frame docking hint locations and mouse drop locations
    * Streamline the "feel" of frame and toolbar dragging
    * Fix various drawing glitches and toolbar instability

I really hope 1.0 comes along quickly. It's kinda hard to tell how that project is developing. The source for 0.9 is available, but the forum is empty and there is no svn access (that I saw).

I'll post over there and see about some things I have questions about. I expect C::B to keep using their code, but if for some reason we need to change it in the future it wouldn't be too hard.


I'm going to switch back to trunk for now. I really liked what I saw in wxAUI, and the "feel" was excellent (pane positioning and movable toolbars especially). I hope to see it merged soon. 

[mandrav]

Ok, I built it and looks promising, but it isn't saving or loading any layout (you said you implemented that, so where did you hid it?).

Lol, I 've hidden it in "View->Layouts"
(although I noticed a little glitch and I 'll fix it soon)

The second problem is the toolbars are a bit bigger than the space assigned for them when icons are 32x32, and smaller when 16x16. In the first case it's painting a few extra pixels, in the second case it isn't painting all pixels (the ones at the bottom), and, also for 16x16, the space for the toolbar is larger than needed.

I suppose those are wxAUI problems, right?

This problem already appears with wxDockit. It is probably a C::B issue, specifically because we 're loading the toolbars from XRC. Somehow it seems the bitmap size is not correct. When using the 16x16 bitmaps, if you edit the toolbars' XRCs <bitmapsize> and make it 16,14 instead of 16,16 everything is ok then. Except that some icons are clipped...

[takeshimiya]

Reporting in.

Noticed all the problems with the toolbars. Can't we just not load them from XRC?

I'd suggest adding settings for: Allow Floating, Transparent Hint, Transparent Hint Fade-in, and Transparent Drag, somewhere in Settings->Environment.

I would also like to have the ability to set-up Pane Border Size, Gripper Color, etc but a dialog (GUI) for those others is rather worthless.

As I don't like having any hard-coded settings in C::B, here's when my idea comes:
What about those settings (among a lot others) which doesn't deserve a GUI, being setteable from an about:config like in Firefox?
Which of course can be implemented as a tree/listbox in a dialog that haves all the settings of the xml default.conf.