agw.aui refresh problem on OS X
Rob McMullen
MSW. It's nice work, Andrea. I needed zero API changes to my code to
get it to work, and in fact even got to drop a few hacks needed with
the native AUI. And the native AUI would crash on GTK trying to drag
tabs around.
I did notice a strange issue on OS X as shown in the attached
screenshot. After starting the AUI.py demo application and hitting
the button to pop up the AUI frame, the frame appears to get drawn
correctly, but immediately erases itself and only a few bits get
redrawn.
This is using the latest svn. I went back and tried the 2.8.10.1
version and it shows the same problem. It's weird, I hadn't seen this
reported so is this just some crazy issue with my setup? I'm on OS X
10.5 using the standard python and the 2.8.10.1 wxPython.
I'm happy to help w/debugging, Andrea, if you've got any ideas...
Rob
Andrea Gavana
2009/12/15 Rob McMullen:
> MSW. It's nice work, Andrea. I needed zero API changes to my code to
> get it to work, and in fact even got to drop a few hacks needed with
> the native AUI. And the native AUI would crash on GTK trying to drag
> tabs around.
>
> I did notice a strange issue on OS X as shown in the attached
> screenshot. After starting the AUI.py demo application and hitting
> the button to pop up the AUI frame, the frame appears to get drawn
> correctly, but immediately erases itself and only a few bits get
> redrawn.
>
> This is using the latest svn. I went back and tried the 2.8.10.1
> version and it shows the same problem. It's weird, I hadn't seen this
> reported so is this just some crazy issue with my setup? I'm on OS X
> 10.5 using the standard python and the 2.8.10.1 wxPython.
been tested since Cody stepped in a while ago, as summarized in this
thread:
http://groups.google.com/group/wxPython-dev/browse_thread/thread/3d2fd3894b61c1d4
Almost all (if not all) the issues have been fixed in the meantime,
except one: on the Mac the floating panes can not be resized, due to
some funny Mac behaviour: basically the Mac refuses to display a
wx.RESIZE_BORDER if the frame does not have a wx.CAPTION style set.
From the brief discussion which followed the aforementioned thread
between me, Robin, Cody and Stefan Csomor (wxMac guru in wxWidgets) it
seems that nothing can be done, although I don't really think this
particular issue has been investigated enough on the Mac. I am not
convinced that there is absolutely no way to display a resize border
on a frame without a caption.
> I'm happy to help w/debugging, Andrea, if you've got any ideas...
other platforms come into play. I can't test anything on the Mac. In
any case, the first thing that springs into my mind is that, inside
the Repaint() method of Auimanager, you could add something like this:
if wx.Platform == "__WXMAC__":
if dc is None:
self._frame.Refresh()
self._frame.Update()
return
Other than this, it's hard to say... I could use some of your
expertise to fix this (and other) issue(s) on he Mac!
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/
Rob McMullen
> It's hard to say as all the code I write is mostly blind guess when
> other platforms come into play. I can't test anything on the Mac. In
> any case, the first thing that springs into my mind is that, inside
> the Repaint() method of Auimanager, you could add something like this:
>
> if wx.Platform == "__WXMAC__":
> if dc is None:
> self._frame.Refresh()
> self._frame.Update()
> return
>
> Other than this, it's hard to say... I could use some of your
> expertise to fix this (and other) issue(s) on he Mac!
least experience with -- primary is GTK, and I test regularly in MSW
(in VirtualBox) because I have to support that for my real job. My
Mac is old and slow and tends to be relegated to the bottom of the
stack.
But, having said that, I do have some good news to report. In
framemanager.py, AuiManager.OnRender, it works for me now after I take
out the dc.Clear that happens when wx.Platform is __WXMAC__. I don't
know if it's just voodoo for my particular setup, so it would be nice
to get it tested on another Mac. Maybe the dc.Clear was needed for an
older version of wxPython? I'm using 2.8.10.1.
Rob
Andrea Gavana
2009/12/16 Rob McMullen:
source code. In any case, thank you for the patch, I'll apply it
tomorrow. Unfortunately agw.aui is still hungry for testers/developers
on the Mac :-(
Cody Precord
On Wed, Dec 16, 2009 at 4:42 PM, Andrea Gavana <andrea...@gmail.com> wrote:
>
> Not sure about that, it's been taken straight out of the C++ wxAUI
> source code. In any case, thank you for the patch, I'll apply it
> tomorrow. Unfortunately agw.aui is still hungry for testers/developers
> on the Mac :-(
run again in nearish future.
The main remaining issues that I remember from previous testing was that
1) trying to take panels and dock them to create new notebooks would
cause a crash on wxMac, and at that time I wasn't able to nail down
the cause completely.
2) The floating panes where using custom drawn title bars which
1) don't look as nice as the native miniframes used in the wxAUI
2) made it (as mentioned earlier in this thread) so that they
couldn't be resized
Cody
Andrea Gavana
2009/12/16 Cody Precord:
>
> On Wed, Dec 16, 2009 at 4:42 PM, Andrea Gavana <andrea...@gmail.com> wrote:
>>
>> Not sure about that, it's been taken straight out of the C++ wxAUI
>> source code. In any case, thank you for the patch, I'll apply it
>> tomorrow. Unfortunately agw.aui is still hungry for testers/developers
>> on the Mac :-(
>
> I've been quite swamped the last few months but will try to give it a
> run again in nearish future.
>
> The main remaining issues that I remember from previous testing was that
>
> 1) trying to take panels and dock them to create new notebooks would
> cause a crash on wxMac, and at that time I wasn't able to nail down
> the cause completely.
> 2) The floating panes where using custom drawn title bars which
> 1) don't look as nice as the native miniframes used in the wxAUI
> 2) made it (as mentioned earlier in this thread) so that they
> couldn't be resized
easy to go back and use the native title bars for floating mini
frames, as the code which handles floating panes motion, docking
etc... is quite a bit different from the original one. So I believe
this will require some work, and I would be happy to do it if I has a
way to test what I am doing.
Andrea Gavana
2009/12/16 Andrea Gavana:
original appearance of the caption of miniframes by using the
ModernDockArt class (which uses the pywin32 extension and draws the
caption title bars natively). Other than heavily modifying the code to
get back to the original wxAUI miniframes on the Mac, would it be
possible to do the same on the Mac by using a Carbon dll loaded as:
import ctypes
_carbon_dll = ctypes.cdll.LoadLibrary(r'/System/Frameworks/Carbon.framework/Carbon')
And then use this to draw the caption bars natively? Just thinking out
loud here...
Cody Precord
Hi Cody,
Thinking about it, on Windows it is already possible to get back the
original appearance of the caption of miniframes by using the
ModernDockArt class (which uses the pywin32 extension and draws the
caption title bars natively). Other than heavily modifying the code to
get back to the original wxAUI miniframes on the Mac, would it be
possible to do the same on the Mac by using a Carbon dll loaded as:
import ctypes
_carbon_dll = ctypes.cdll.LoadLibrary(r'/System/Frameworks/Carbon.framework/Carbon')
And then use this to draw the caption bars natively? Just thinking out
loud here...
Cody Precord
On Dec 16, 2009, at 5:06 PM, Andrea Gavana wrote:
> Hi Cody,
>
>> 2) The floating panes where using custom drawn title bars which
>> 1) don't look as nice as the native miniframes used in the wxAUI
>> 2) made it (as mentioned earlier in this thread) so that they
>> couldn't be resized
>
> Yep, this is what I wrote to Rob in a previous message. It's not that
> easy to go back and use the native title bars for floating mini
> frames, as the code which handles floating panes motion, docking
> etc... is quite a bit different from the original one. So I believe
> this will require some work, and I would be happy to do it if I has a
> way to test what I am doing.
Could you explain this to me again.
Does using the native title bars present some limitations? Are some
events not sent when dragging a window around by the titlebar as
apposed to handling the mouse motion yourself?
Not being able to resize the undocked windows is the deal breaker on
moving over from wxAui for my applications right now. Not having
native looking titlebars is also kind of an issue but not as important
as the windows not being resizable.
Cody
Rob McMullen
> 2) The docking hint window (the VS2005 like HUD) was not transparent so
> three large windows would cover the managed frame. Fixed in a similar way to
> how I had fixed the transparent docking hints before, use of wx.FRAME_SHAPED
> caused the issue and removing it from the style of the AuiSingleDockingGuide
> window when under wxMac fixed the issue.
I was just looking at this, too, but that breaks the Aero and Whidbey
docking guides, which need the shaped extension.
The problem I was trying to figure out is that you can't find out the
flag until after the window is created, but (not knowing anything
about shaped windows) I'm betting that you can't alter the shaped flag
after the window is created. I.e. this can't be called:
useAero = GetManager(self.GetParent()).GetFlags() &
AUI_MGR_AERO_DOCKING_GUIDES
until after the window is created, but you need to know the result of
that before you can decide whether or not to use the wx.FRAME_SHAPED
flag. Chicken-and-egg problem.
It might be that shaped windows have to be used for the VS2005 docking
guides, even though they are rectangular.
Rob
Cody Precord
On Dec 16, 2009, at 7:39 PM, Rob McMullen wrote:
> On Wed, Dec 16, 2009 at 5:21 PM, Cody Precord
> <codyp...@gmail.com> wrote:
>> 2) The docking hint window (the VS2005 like HUD) was not
>> transparent so
>> three large windows would cover the managed frame. Fixed in a
>> similar way to
>> how I had fixed the transparent docking hints before, use of
>> wx.FRAME_SHAPED
>> caused the issue and removing it from the style of the
>> AuiSingleDockingGuide
>> window when under wxMac fixed the issue.
>
> I was just looking at this, too, but that breaks the Aero and Whidbey
> docking guides, which need the shaped extension.
Oh, those must be new didn't see them.
Checked in a fix for it. There appears to be some transparency issues
with the Whidbey images but don't have time to look into it much more
today.
Cody
Rob McMullen
> Checked in a fix for it. There appears to be some transparency issues
> with the Whidbey images but don't have time to look into it much more
> today.
Pretty sure that's because the Aero/Whidbey images need the shaped extension. :)
Instead of the SetShape override, the AuiDockingGuide.__init__ method
needs the wx.FRAME_SHAPED for Aero and Whidbey. What I was trying to
say with my previous message was that the only way around this might
be to force all of the images to use the shaped extension, even though
the VS2005 images are rectangular.
Rob
Rob McMullen
It's weird, though. My lack of OS X experience is showing through
here: your comment in the code seems to indicate that FRAME_SHAPED has
problems on OS X, but the AuiCenterDockingGuide class seems to use it,
which is leading to my confusion.
If I try to turn the FRAME_SHAPED flag on for AuiSingleDockingGuide
and create a shaped window for the VS2005 style docking guides, I
noticed that I lose the smooth updating when dragging around the pane.
It's almost as if the big rectangular window you fixed in your change
#2 of a few message ago is still intercepting mouse movement.
Is FRAME_SHAPED totally unsupported on WXMAC?
Rob
Andrea Gavana
2009/12/17 Rob McMullen:
Not that I know of. As far as I know, for example, AdvancedSplash
works on the Mac too and it is using wx.FRAME_SHAPED. The fix Cody
committed works on Windows, I am not sure it works on the Mac. As for
the Whidbey images, the original images seem to have the correct
transparency, so I don't know which is the problem on the Mac...
Other than that, I'll try to make agw.aui use the original miniframes
as floating pane by adding another style (like
AUI_MGR_USE_NATIVE_MINIFRAMES) as an option (which will be "on" by
default on the Mac), and I'll report back the findings.
Thank you guys for the testing and the patches!
Cody Precord
Hi All,
Is FRAME_SHAPED totally unsupported on WXMAC?
Not that I know of. As far as I know, for example, AdvancedSplash
works on the Mac too and it is using wx.FRAME_SHAPED. The fix Cody
committed works on Windows, I am not sure it works on the Mac. As for
the Whidbey images, the original images seem to have the correct
transparency, so I don't know which is the problem on the Mac...
Other than that, I'll try to make agw.aui use the original miniframes
as floating pane by adding another style (like
AUI_MGR_USE_NATIVE_MINIFRAMES) as an option (which will be "on" by
default on the Mac), and I'll report back the findings.
Andrea Gavana
2009/12/17 Cody Precord:
I think I have managed to nail this thing down (not yet committed to
SVN). One thing I was a bit unsure on what to do is: when using custom
drawn pane captions, double-clicking on a pane caption simply re-docks
the pane in the manager. Using native wx.MiniFrames, first of all I am
not sure I can catch the double-click on a mini frame *caption*, and
secondly the default behaviour of double-clicking the mini frame
caption (for panes which have the MaximizeButton set to True) is to
maximize the mini frame, not to re-dock it.
Does anyone have any suggestion on what I should do in this case?
Cody Precord
On Thu, Dec 17, 2009 at 11:03 AM, Andrea Gavana <andrea...@gmail.com> wrote:
>>
>> Nice, will be interested to see.
>
> I think I have managed to nail this thing down (not yet committed to
> SVN). One thing I was a bit unsure on what to do is: when using custom
> drawn pane captions, double-clicking on a pane caption simply re-docks
> the pane in the manager. Using native wx.MiniFrames, first of all I am
> not sure I can catch the double-click on a mini frame *caption*, and
> secondly the default behaviour of double-clicking the mini frame
> caption (for panes which have the MaximizeButton set to True) is to
> maximize the mini frame, not to re-dock it.
>
> Does anyone have any suggestion on what I should do in this case?
You can try catching EVT_MAXIMIZE (won't work for frames with no
buttons), I don't think wx has any other mouse related events that get
fired for non client areas, but from a user perspective I wouldn't
guess that double clicking on a titlebar should dock a window I would
expect it to either 1 maximize it or 2 do nothing so it could
sufficient to just be documented as not working when using native
frames.
Cody
Andrea Gavana
2009/12/17 Cody Precord:
Good then, in SVN there is an update version of agw.aui with a couple
of AuiManager styles added:
1) AUI_MGR_SMOOTH_DOCKING: attempts to re-create the smooth docking
behaviour of PyQT (this will need some more work, as I would like it
to show the possible layout before docking and not only the blue hint
window (and maybe with added smooth slide-in/slide out of the new
layout));
2) AUI_MGR_USE_NATIVE_MINIFRAMES: use native miniframes as floating
frames (forced on the Mac, optional on other platforms).
Both new styles can be seen on the AUI demo, under "Options" =>
"Smooth Docking Effects" and "Options" => "Use Native wx.MiniFrames".
The new docs are currently building and will be available here:
http://xoomer.virgilio.it/infinity77/AGW_Docs/
in a short while.
Any tester/developer willing to step in to test/update the latest AUI
(on Mac and GTK especially) is more than welcome.
Robin Dunn
>> Yep, this is what I wrote to Rob in a previous message. It's not that
>> easy to go back and use the native title bars for floating mini
>> frames, as the code which handles floating panes motion, docking
>> etc... is quite a bit different from the original one. So I believe
>> this will require some work, and I would be happy to do it if I has a
>> way to test what I am doing.
>
> Thinking about it, on Windows it is already possible to get back the
> original appearance of the caption of miniframes by using the
> ModernDockArt class (which uses the pywin32 extension and draws the
> caption title bars natively). Other than heavily modifying the code to
> get back to the original wxAUI miniframes on the Mac, would it be
> possible to do the same on the Mac by using a Carbon dll loaded as:
>
> import ctypes
> _carbon_dll = ctypes.cdll.LoadLibrary(r'/System/Frameworks/Carbon.framework/Carbon')
>
> And then use this to draw the caption bars natively?
That won't help with the resize issue. At least in Carbon there isn't a
WindowClass type (that I could find) that allows for the window to be
both resizable and to be without a native caption bar, as far as I can
tell. Self-drawing a native-looking caption bar is still a window
without a native caption bar.
If anybody would like to take a look at it, the current code for
selecting the WindowClass is in
wxTopLevelWindowMac::DoMacCreateRealWindow in
src/mac/carbon/toplevel.cpp. When this issue first came up I
experimented with tweaking that code to try some new combinations for
wclass and attr but IIRC all my attempts either had no effect or caused
an error.
I see that while I've been writing this message that you have already
added back the ability to use the native caption bar. Sorry that I
don't have anything other than that to suggest.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Robin Dunn
> The problem appears to be that the floating pane is below the
> transparent docking hint window so the hint window seems to block the
> mouse motion events until it is hidden again. I tried a number of things
> to work around this but am yet to find the correct combination.
This may be another issue related to which Carbon WindowClass is used
for each type of wx frame style. I don't remember details but IIRC some
of the class types also mean that the window belongs to a different
"layer" or something like that.
Kevin Ollivier
Carbon is pretty quirky when it comes to window styles. Even if you find the right style, there are several styles that are incompatible with certain window classes and can't be combined. At one point, I tried to fix things so that, for example, we could dynamically set wx.STAY_ON_TOP, but gave up when I found that depending on the window style you chose, it just wouldn't work. This is just one area where things in Cocoa Just Work whereas the Carbon impl. is hindered by old API baggage.
Especially with Carbon, I think trying to get this working is probably just a bag of hurt that isn't worth bothering with. It's not only inflexible in a lot of areas, but deprecated and going out the door. The docs appear to have been removed from the OS X Dev site, and I doubt you'd find many people out there willing and able to help if we hit a problem. The Visual Studio UI elements are completely foreign on Mac anyway, so I'm not sure of the value of trying to force them when the native UI would be much more natural.
Regards,
Kevin
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org
>
> --
> To unsubscribe, send email to wxPython-user...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-users?hl=en
Andrea Gavana
2009/12/17 Kevin Ollivier:
> Hi Robin and all,
>
> On Dec 17, 2009, at 10:14 AM, Robin Dunn wrote:
>
>> On 12/17/09 5:03 AM, Cody Precord wrote:
>>> The problem appears to be that the floating pane is below the
>>> transparent docking hint window so the hint window seems to block the
>>> mouse motion events until it is hidden again. I tried a number of things
>>> to work around this but am yet to find the correct combination.
>>
>> This may be another issue related to which Carbon WindowClass is used
>> for each type of wx frame style. I don't remember details but IIRC some
>> of the class types also mean that the window belongs to a different
>> "layer" or something like that.
>
> Carbon is pretty quirky when it comes to window styles. Even if you find the right style, there are several styles that are incompatible with certain window classes and can't be combined. At one point, I tried to fix things so that, for example, we could dynamically set wx.STAY_ON_TOP, but gave up when I found that depending on the window style you chose, it just wouldn't work. This is just one area where things in Cocoa Just Work whereas the Carbon impl. is hindered by old API baggage.
>
> Especially with Carbon, I think trying to get this working is probably just a bag of hurt that isn't worth bothering with. It's not only inflexible in a lot of areas, but deprecated and going out the door. The docs appear to have been removed from the OS X Dev site, and I doubt you'd find many people out there willing and able to help if we hit a problem. The Visual Studio UI elements are completely foreign on Mac anyway, so I'm not sure of the value of trying to force them when the native UI would be much more natural.
What does the native UI recommend on wxMac? Does it mean wxAUI (and
agw.aui) are not the proper tools on Mac platforms? I am pretty sure
we are close enough to fix the problems of agw.aui on Mac too (it
works pretty well on Windows and GTK, as far as I know), but if the
"Visual Studio" docking guides are so foreign to the Mac natural UI
style it takes zero time to remove them and go back to the standard
wxAUI hint windows on the Mac.
Other than that, I heard many people saying that the lack of "native"
floating panes and the impossibility of resizing a floating pane were
the major things which prevented them from using agw.aui on the Mac.
It was the same for me in GUI2Exe, I was falling back to the standard
wxAUI on the Mac because of those issues. Now that these 2 issues are
resolved, I don't see why we should drop AUI on the Mac, unless there
are clear indications that wxAUI is absolutely out of place on wxMac
and some other strategy should be used instead. I am not convinced of
this anyway as I see many open source apps using wxAUI on Mac too
(also from Mac developers and experienced Mac users).
Kevin Ollivier
On Dec 17, 2009, at 3:22 PM, Andrea Gavana wrote:
> Hi Kevin,
>
> 2009/12/17 Kevin Ollivier:
>> Hi Robin and all,
>>
>> On Dec 17, 2009, at 10:14 AM, Robin Dunn wrote:
>>
>>> On 12/17/09 5:03 AM, Cody Precord wrote:
>>>> The problem appears to be that the floating pane is below the
>>>> transparent docking hint window so the hint window seems to block the
>>>> mouse motion events until it is hidden again. I tried a number of things
>>>> to work around this but am yet to find the correct combination.
>>>
>>> This may be another issue related to which Carbon WindowClass is used
>>> for each type of wx frame style. I don't remember details but IIRC some
>>> of the class types also mean that the window belongs to a different
>>> "layer" or something like that.
>>
>> Carbon is pretty quirky when it comes to window styles. Even if you find the right style, there are several styles that are incompatible with certain window classes and can't be combined. At one point, I tried to fix things so that, for example, we could dynamically set wx.STAY_ON_TOP, but gave up when I found that depending on the window style you chose, it just wouldn't work. This is just one area where things in Cocoa Just Work whereas the Carbon impl. is hindered by old API baggage.
>>
>> Especially with Carbon, I think trying to get this working is probably just a bag of hurt that isn't worth bothering with. It's not only inflexible in a lot of areas, but deprecated and going out the door. The docs appear to have been removed from the OS X Dev site, and I doubt you'd find many people out there willing and able to help if we hit a problem. The Visual Studio UI elements are completely foreign on Mac anyway, so I'm not sure of the value of trying to force them when the native UI would be much more natural.
>
> What does the native UI recommend on wxMac? Does it mean wxAUI (and
> agw.aui) are not the proper tools on Mac platforms? I am pretty sure
> we are close enough to fix the problems of agw.aui on Mac too (it
> works pretty well on Windows and GTK, as far as I know), but if the
> "Visual Studio" docking guides are so foreign to the Mac natural UI
> style it takes zero time to remove them and go back to the standard
> wxAUI hint windows on the Mac.
Most Mac native apps use what's called the SDI model, where each document gets its own TLW and palettes are usually floating and are rarely ever docked to the document window. It's actually similar to the old Windows MDI approach, except it works a lot better because of differences in how the Mac OS manages documents / apps. The best thing I've come across which highlights these differences between Mac and Windows is this Ars Technica article:
http://arstechnica.com/software/news/2009/01/dock-and-windows-7-taskbar.ars
The first page is really the important part. As it says, TLWs on Mac represent documents rather than applications, whereas the AUI model (and wxMDI and wxDocView...) assumes a TLW is an application. So, for example, in Editra, if I create two documents in different windows, it doesn't just create a new document window, it clones the entire Editra UI each time, which both considerably increases the space a document takes up and gives me a number of duplicate panes. This sort of thing rarely happens on Mac. Instead, all the items 'docked' to the document would be floating panes instead (with the exception of the document's toolbar), and they would be shared by all documents. AUI doesn't really support doing that yet, though, because:
1) It doesn't have a mode where there are no open TLWs (i.e. the app is running but nothing is open on Mac)
2) AFAICT, it doesn't save and restore a pane's floating state. So if you have a floating pane, close the app, then start it again, the pane is now docked to the TLW, not floating.
3) All the manager event handling seems to be sent to a TLW, rather than having an option to send it to the app or a non-GUI (i.e. wx.EvtHandler-derived) event sink.
> Other than that, I heard many people saying that the lack of "native"
> floating panes and the impossibility of resizing a floating pane were
> the major things which prevented them from using agw.aui on the Mac.
> It was the same for me in GUI2Exe, I was falling back to the standard
> wxAUI on the Mac because of those issues. Now that these 2 issues are
> resolved, I don't see why we should drop AUI on the Mac, unless there
> are clear indications that wxAUI is absolutely out of place on wxMac
> and some other strategy should be used instead. I am not convinced of
> this anyway as I see many open source apps using wxAUI on Mac too
> (also from Mac developers and experienced Mac users).
AUI is the best wx solution out there right now for managing complex UIs with multiple panes in it, and in that sense I think wx devs, Mac or otherwise, are glad to have it, but that's different from saying that it supports Mac SDI-style document management.
To me, it's not just, or even primarily, an issue of looks; one nice feature I use regularly from TextWrangler is a feature that basically does a diff of two documents, then lays the documents out side-by-side and lets you step through the changes. This is very useful for comparing versions of documents when you don't have the benefit of a VCS like svn or git (e.g. tracking web site changes), but it's kind of hard to emulate that UI using AUI when all your docs are in tabs inside a pane inside a main window. ;-) It's features like this that keeps driving me back to the native tools, even if I'd like to support a wx alternative.
I'm sure some people don't use this stuff, nor care if the app manages and displays its windows using a Win/Linux style approach. But it does look and work out of place compared to most native apps, and it's using an approach which is not standard on Mac. To me, that means wxMac apps tend to stick out from native apps, which I think is the whole problem wx is supposed to move us away from.
Regards,
Kevin
> Andrea.
>
> "Imagination Is The Only Weapon In The War Against Reality."
> http://xoomer.alice.it/infinity77/
> http://thedoomedcity.blogspot.com/
>