Author Topic: wxAUI (Read 33535 times)

sethjackson · « **on:** January 10, 2006, 08:25:19 pm »

Hey guys new release of wxAUI.

http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html

Just a heads up.

yop · « **Reply #1 on:** January 10, 2006, 08:31:41 pm »

Quote

wxAUI version 0.9.1 adds:

* Support for MDI frames
* Gradient captions option
* Active/Inactive panes option
* Fix for screen artifacts/paint problems
* Fix for hiding/showing floated window problem
* Fix for floating pane sizing problem
* Fix for drop position problem when dragging around center pane margins
* Fix for 64-bit compilation
* LF-only text file formatting for source code

Since they are in 0.9.x there are more to expect when they release 1.0?

Edit: OK I continued reading the roadmap, spoke too early :oops:

mandrav · « **Reply #2 on:** January 10, 2006, 08:41:44 pm »

0.91 doesn't behave nice in linux. I 'm still looking into it...

sethjackson · « **Reply #3 on:** January 10, 2006, 08:45:25 pm »

Quote from: mandrav on January 10, 2006, 08:41:44 pm

0.91 doesn't behave nice in linux. I 'm still looking into it...

That isn't too good. :?

280Z28 · « **Reply #4 on:** January 10, 2006, 09:54:23 pm »

https://sourceforge.net/tracker/index.php?func=detail&aid=1402085&group_id=126998&atid=707418

killerbot · « **Reply #5 on:** January 10, 2006, 09:58:22 pm »

that was fast Sam !!! :shock:

280Z28 · « **Reply #6 on:** January 10, 2006, 10:03:43 pm »

Small goof. I didn't try to change the colors.

This has to be added to the event table for EnvironmentSettingsDlg (in addition to that patch).

Code

    EVT_BUTTON(XRCID("btnAuiActiveCaptionColor"), EnvironmentSettingsDlg::OnChooseColor)
    EVT_BUTTON(XRCID("btnAuiActiveCaptionGradientColor"), EnvironmentSettingsDlg::OnChooseColor)
    EVT_BUTTON(XRCID("btnAuiActiveCaptionTextColor"), EnvironmentSettingsDlg::OnChooseColor)
    EVT_BUTTON(XRCID("btnAuiInactiveCaptionColor"), EnvironmentSettingsDlg::OnChooseColor)
    EVT_BUTTON(XRCID("btnAuiInaCaptionGradientColor"), EnvironmentSettingsDlg::OnChooseColor)
    EVT_BUTTON(XRCID("btnAuiInaCaptionTextColor"), EnvironmentSettingsDlg::OnChooseColor)

280Z28 · « **Reply #7 on:** January 10, 2006, 10:06:28 pm »

Screenshot

[attachment deleted by admin]

mandrav · « **Reply #8 on:** January 10, 2006, 10:09:35 pm »

So it was you Sam, the "nobody" who posted this patch at SF.
Afraid to say it but it doesn't apply to the current SVN HEAD...

Quote from: ubuntu

patching file src/environmentsettingsdlg.cpp patching file src/main.cpp Hunk #1 succeeded at 1228 (offset -1 lines). patching file src/resources/env_settings.xrc patching file src/wxAUI/manager.cpp Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file src/wxAUI/manager.cpp.rej patching file src/wxAUI/manager.h Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file src/wxAUI/manager.h.rej

280Z28 · « **Reply #9 on:** January 10, 2006, 10:12:01 pm »

Quote from: mandrav on January 10, 2006, 10:09:35 pm

So it was you Sam, the "nobody" who posted this patch at SF.
Afraid to say it but it doesn't apply to the current SVN HEAD...

It's a patch on 1701. Do you want me to make one on 1703?

280Z28 · « **Reply #10 on:** January 10, 2006, 10:17:52 pm »

Here you go.

If I included main.h in the previous patch, I shouldn't have.

This includes the fix from a couple posts up too.

I can't post this on SF because I'm not logged in and can't modify a "nobody" post

[attachment deleted by admin]

mandrav · « **Reply #11 on:** January 10, 2006, 10:38:30 pm »

LOL, this is even worse. Never mind, I 'll fix your original patch.

Quote from: ubuntu

(Stripping trailing CRs from patch.) patching file src/environmentsettingsdlg.cpp (Stripping trailing CRs from patch.) patching file src/main.cpp (Stripping trailing CRs from patch.) patching file src/resources/env_settings.xrc (Stripping trailing CRs from patch.) patching file src/wxAUI/manager.cpp Hunk #1 FAILED at 18. Hunk #2 FAILED at 40. Hunk #3 FAILED at 145. Hunk #4 FAILED at 156. Hunk #5 FAILED at 168. Hunk #6 FAILED at 184. Hunk #7 FAILED at 193. Hunk #8 FAILED at 213. Hunk #9 FAILED at 260. Hunk #10 FAILED at 268. Hunk #11 FAILED at 293. Hunk #12 FAILED at 351. Hunk #13 FAILED at 381. Hunk #14 FAILED at 395. Hunk #15 FAILED at 415. Hunk #16 FAILED at 492. Hunk #17 FAILED at 602. Hunk #18 FAILED at 647. Hunk #19 FAILED at 742. Hunk #20 FAILED at 922. Hunk #21 FAILED at 957. Hunk #22 FAILED at 1024. Hunk #23 FAILED at 1038. Hunk #24 FAILED at 1072. Hunk #25 FAILED at 1100. Hunk #26 FAILED at 1625. Hunk #27 FAILED at 1651. Hunk #28 FAILED at 1676. Hunk #29 FAILED at 2303. Hunk #30 FAILED at 2359. Hunk #31 FAILED at 2449. Hunk #32 FAILED at 2503. Hunk #33 FAILED at 2591. Hunk #34 FAILED at 2751. Hunk #35 FAILED at 2800. Hunk #36 FAILED at 2850. Hunk #37 FAILED at 2868. Hunk #38 FAILED at 2990. Hunk #39 FAILED at 3084. Hunk #40 FAILED at 3216. Hunk #41 FAILED at 3254. Hunk #42 FAILED at 3281. Hunk #43 FAILED at 3307. Hunk #44 FAILED at 3348. Hunk #45 FAILED at 3410. Hunk #46 FAILED at 3483. Hunk #47 FAILED at 3529. Hunk #48 FAILED at 3605. Hunk #49 FAILED at 3947. 49 out of 49 hunks FAILED -- saving rejects to file src/wxAUI/manager.cpp.rej (Stripping trailing CRs from patch.) patching file src/wxAUI/manager.h Hunk #1 FAILED at 26. Hunk #2 FAILED at 45. Hunk #3 FAILED at 81. Hunk #4 FAILED at 142. Hunk #5 FAILED at 163. Hunk #6 FAILED at 208. Hunk #7 FAILED at 294. Hunk #8 FAILED at 328. Hunk #9 FAILED at 413. Hunk #10 FAILED at 445. Hunk #11 FAILED at 551. Hunk #12 FAILED at 597. 12 out of 12 hunks FAILED -- saving rejects to file src/wxAUI/manager.h.rej

280Z28 · « **Reply #12 on:** January 10, 2006, 10:40:32 pm »

Only TortoiseSVN can apply patches created by TortoiseSVN

Although I wrote a Perl script to apply them without TSVN.

Edit: this is it. It'd have to be modified to use with another directory structure but you get the idea.

Code

# fix line endings
perl -pi -e 's/\r\n/\n/;' *.c *.h *.patch testing/*.c testing/*.h testing/Makefile

# prepare the checkout
perl -pi -e 's/\$Id[^\$]+\$/\$Id\$/;' *.c *.h testing/*.c testing/*.h testing/Makefile

# apply the patch
patch -p0 -N < library.patch

Der Meister · « **Reply #13 on:** January 10, 2006, 10:47:51 pm »

Quote from: 280Z28 on January 10, 2006, 10:40:32 pm

Only TortoiseSVN can apply patches created by TortoiseSVN

I don't use TortoiseSVN but the plain svn can create patches (i.e. diff-files) that can be applied using the linux/unix tool 'patch'. Just run 'svn diff <the file you want to create the patch from> > yourpatchfile' (This produces a normal svn diff and saves the output in the file named 'yourpatchfile' - works on linux but should work also on Windows). To apply the patch just run 'patch -p yourpatchfile' (iirc).

280Z28 · « **Reply #14 on:** January 10, 2006, 10:55:23 pm »

0.9.1 doesn't detect a pane losing focus. The only way a pane become inactive is if another pane in the same FrameManager becomes active. Here's the idea of the fix:

Edit: removed until I find a better solution

bwilliams · « **Reply #15 on:** January 11, 2006, 06:26:17 am »

Gotcha. Maybe we should intercept a wxActivateEvent for frame deactivation. This would then mark any active panes as inactive. Is that workable?

I'd be interested in your solution, too.

Best,
Ben

280Z28 · « **Reply #16 on:** January 11, 2006, 06:33:30 am »

Can we re-write the Init and UnInit functions to use m_frame->Connect() for just the events we want to listen to?

Code::Blocks does that to listen to wxScintilla events.

wxEvtHandler::Disconnect() seems monstrously more powerful and less error prone than PopEventHandler()

If you've tried this and it didn't work, then I'll just leave it be, but I'd be willing to try to rewrite it and see how things go.

bwilliams · « **Reply #17 on:** January 11, 2006, 07:17:39 am »

Quote

Can we re-write the Init and UnInit functions to use m_frame->Connect() for just the events we want to listen to?

Code::Blocks does that to listen to wxScintilla events.

wxEvtHandler::Disconnect() seems monstrously more powerful and less error prone than PopEventHandler()

If you've tried this and it didn't work, then I'll just leave it be, but I'd be willing to try to rewrite it and see how things go.

I think that's a great idea. Would you be willing to post a patch here or on our forums? I'd love to try it out. PopEventHandler() is a tricky thing, and can cause problems in more complicated wxWidgets scenarios.

Thanks,
Ben

280Z28 · « **Reply #18 on:** January 11, 2006, 07:20:21 am »

It also could cause problems in a situation like this:

wxAUI pushes
wxSomethingElse pushes

wxAUI::UnInit pops, but pops the wxSomethingElse handler. wxAUI is still on the event stack :shock:

I'll do that and post a patch.

280Z28 · « **Reply #19 on:** January 11, 2006, 07:57:53 am »

It's not working for me on the first try. I'll work on it again later.

Pecan · « **Reply #20 on:** January 11, 2006, 01:58:41 pm »

I haven't read the code, but I've run into this problem with
two other modules.

wxWindows::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

thanks
pecan

280Z28 · « **Reply #21 on:** January 11, 2006, 02:06:17 pm »

Quote from: Pecan on January 11, 2006, 01:58:41 pm

I haven't read the code, but I've run into this problem with
two other modules.

wxWindow::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

thanks
pecan

I think that's just what I'm looking for.

Pecan · « **Reply #22 on:** January 11, 2006, 06:30:40 pm »

I've noticed that undocked windows are "alway-on-top" so that
it hides the main CB window and editor.

?Is there an option that can make the undocks more friendly?
I hate my editor code hidden. Like a pin/tack/clippy/nail/40 aught?

thanks
pecan

280Z28 · « **Reply #23 on:** January 11, 2006, 08:42:24 pm »

Quote from: Pecan on January 11, 2006, 06:30:40 pm

I've noticed that undocked windows are "alway-on-top" so that
it hides the main CB window and editor.

?Is there an option that can make the undocks more friendly?
I hate my editor code hidden. Like a pin/tack/clippy/nail/40 aught?

thanks
pecan

Then you couldn't find them cause they don't show up on the task bar.

bwilliams · « **Reply #24 on:** January 12, 2006, 07:21:16 am »

Quote from: Pecan on January 11, 2006, 01:58:41 pm

I haven't read the code, but I've run into this problem with
two other modules.

wxWindows::RemoveEventHandler() is a much safer way
of removing event handlers than PopEventHandler.

I dont think PopEventHandler should be used in a multi-module
program. How can you know it's the right event handler??

Hi pecan,

Good idea. We'll use RemoveEventHanlder() from now on. Works like a charm.

Best,
Ben

Pecan · « **Reply #25 on:** January 12, 2006, 06:38:07 pm »

you might also consider the following code. wxWindow::RemoveEventHandler()
depends on a valid window pointer. My experience says that stowed window
pointers become invalid quickly as CB opens/closes/destorys/deletes frames,
panels, list/tree ctrls etc...

I had to use if (winExists(p)) before calling p->RemoveEventHandler(thisorthat)
because "*p" may have disappeared along with its EventHanders.
If so, just do the delete thisorthat.

thanks
pecan

Code

// ----------------------------------------------------------------------------
wxWindow* wxKeyBinder::FindWindowRecursively(const wxWindow* parent, const wxWindow* handle)
// ----------------------------------------------------------------------------
{//+v0.4.4
    if ( parent )
    {
        // see if this is the one we're looking for
        if ( parent == handle )
            return (wxWindow *)parent;

        // It wasn't, so check all its children
        for ( wxWindowList::compatibility_iterator node = parent->GetChildren().GetFirst();
              node;
              node = node->GetNext() )
        {
            // recursively check each child
            wxWindow *win = (wxWindow *)node->GetData();
            wxWindow *retwin = FindWindowRecursively(win, handle);
            if (retwin)
                return retwin;
        }
    }

    // Not found
    return NULL;
}
// ----------------------------------------------------------------------------
wxWindow* wxKeyBinder::winExists(wxWindow *parent)
// ----------------------------------------------------------------------------
{ //+v0.4.4

    if ( !parent )
    {
        return NULL;
    }

    // start at very top of wx's windows
    for ( wxWindowList::compatibility_iterator node = wxTopLevelWindows.GetFirst();
          node;
          node = node->GetNext() )
    {
        // recursively check each window & its children
        wxWindow* win = node->GetData();
        wxWindow* retwin = FindWindowRecursively(win, parent);
        if (retwin)
            return retwin;
    }

    return NULL;
}
// ----------------------------------------------------------------------------

280Z28 · « **Reply #26 on:** January 12, 2006, 06:56:14 pm »

There are several sections of wxAUI where recursive searching for windows might be good, but I haven't thought through them enough to be sure of myself in saying so. If you can say for sure that the parent window's ID is unique, then you could store the frame's ID and call the following in UnInit():

Code

//static wxWindow* FindWindowById(long id, wxWindow* parent = NULL)

wxWindow window = wxWindow::FindWindowById(m_frameid);
if ( window )
    window->RemoveEventHandler(this);

And your findWindowRecursively function might look like this. It would work right for:

1) Any window with a unique ID.
2) Any child window with a unique ID up to parent's scope.

This is the key. If you can scope your calls or (if it's one of the main frames of the app) know that it's unique, this is good.

Code

wxWindow* FindWindowRecursively(wxWindow* parent, wxWindow* child)
{
    if ( !parent || !child )
        return NULL;
    return wxWindow::FindWindowById(child->GetId(), parent);
}

wxWindow* wxKeyBinder::winExists(wxWindow *parent)
{
    if ( !parent )
        return NULL;
    return wxWindow::FindWindowById(parent->GetId());
}

Pecan · « **Reply #27 on:** January 12, 2006, 07:28:49 pm »

When your *pointerToWindow has disappeared, you
cannot use it to do FindWindowById or any any FindXXX
calls to the wxWindow code. It'll get a segfault.

If you have stowd locally the address of the windows/frames
etc, my experience says it is unique. Its like a MSwnd handle.

The window id is unique also, according to the docs, but to
use it requires a valid wxWindow ptr, which, in many CB
situations is not the case. Especially for plugins that have
stowed windowPtrs in a local array.
I have had SO MANY stale window ptrs.

In order to Remove the EvtHandler and delete the instance,
ya gotta do it by wxWindow ptr. If the window is gone,
ya better find out before hand (before using the ptr.)
and just do the delete.

thanks
pecan

280Z28 · « **Reply #28 on:** January 12, 2006, 08:45:16 pm »

Quote from: Pecan on January 12, 2006, 07:28:49 pm

When your *pointerToWindow has disappeared, you
cannot use it to do FindWindowById or any any FindXXX
calls to the wxWindow code. It'll get a segfault.

If you have stowd locally the address of the windows/frames
etc, my experience says it is unique. Its like a MSwnd handle.

The window id is unique also, according to the docs, but to
use it requires a valid wxWindow ptr, which, in many CB
situations is not the case. Especially for plugins that have
stowed windowPtrs in a local array.
I have had SO MANY stale window ptrs.

In order to Remove the EvtHandler and delete the instance,
ya gotta do it by wxWindow ptr. If the window is gone,
ya better find out before hand (before using the ptr.)
and just do the delete.

thanks
pecan

Why don't you just store an array of their IDs, and maybe the ID of a parent? So you can find the parent by ID, and then find children by ID. If you have the ID, it won't crash.

Michael · « **Reply #29 on:** March 01, 2006, 12:52:39 pm »

Hello,

Just for info. It seems that soon wxAUI version 0.9.2 will be available

. From bwilliams:

Quote

Next week I plan to put in a solid week and hopefully get 0.9.2 out by the end of next week. That is an optimistic estimate, because there are a few new features I'd like to code. Normally we prefer to do monthly, but I was distracted by another pressing need.

Best wishes,
Michael

sethjackson · « **Reply #30 on:** April 20, 2006, 12:59:58 am »

Quote from: Michael on March 01, 2006, 12:52:39 pm

Hello,

Just for info. It seems that soon wxAUI version 0.9.2 will be available . From bwilliams:

Quote
Next week I plan to put in a solid week and hopefully get 0.9.2 out by the end of next week. That is an optimistic estimate, because there are a few new features I'd like to code. Normally we prefer to do monthly, but I was distracted by another pressing need.

Best wishes,
Michael

It is finally out.

http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html

Check this out.

"wxAUI now supports wxMac!"

Michael · « **Reply #31 on:** April 20, 2006, 01:17:20 am »

Quote from: sethjackson on April 20, 2006, 12:59:58 am

Quote from: Michael on March 01, 2006, 12:52:39 pm
Hello,

Just for info. It seems that soon wxAUI version 0.9.2 will be available . From bwilliams:

Quote
Next week I plan to put in a solid week and hopefully get 0.9.2 out by the end of next week. That is an optimistic estimate, because there are a few new features I'd like to code. Normally we prefer to do monthly, but I was distracted by another pressing need.

Best wishes,
Michael

It is finally out.

http://www.kirix.com/en/community/opensource/wxaui/about_wxaui.html

Check this out.

"wxAUI now supports wxMac!"

Finally

.

Best wishes,
Michael

mandrav · « **Reply #32 on:** April 20, 2006, 09:16:13 am »

Updated to v0.9.2 in HEAD (with the extra community patches).

killerbot · « **Reply #33 on:** April 20, 2006, 10:02:09 am »

build errors :
src\wxAUI\manager.cpp:1187: error: definition of static data member 'wxFrameManager::sm_eventTable' of dllimport'd class.
src\wxAUI\manager.cpp:1187: error: definition of static data member 'wxFrameManager::sm_eventHashTable' of dllimport'd class.
src\wxAUI\manager.cpp:1187: error: definition of static data member 'wxFrameManager::sm_eventTableEntries' of dllimport'd class.

mandrav · « **Reply #34 on:** April 20, 2006, 11:57:24 am »

Sorry, but I mainly use and test with linux.
Fixed now.

News:

Author Topic: wxAUI (Read 33535 times)

sethjackson

sethjackson

bwilliams

bwilliams

bwilliams

sethjackson