I'd like to not use the Mac style menubar, and so I am looking at
getting FlatMenu to work on the Mac. Hoping some people might have
comments on it.
Should I do this?
Probably not if your users are Mac lovers. One thing that most Mac users hate is applications that do not look or feel native.
I want my app to look the same everywhere and this
is important for that.. I also personally can't stand using my app
with the menu bar not on the app itself - I could redesign so its not
used so much, but don't want to.
Can I do this or will I get tripped up with menu events?
Should I be working with 2.9 trunk for this?
Probably. IIRC the FlatMenu uses wx.PopupWindow which didn't have an implementation for Mac until 2.9.
I can't find it again, but I remember there was a problem with
rendering order on the Mac, or rendering to a MemDC first causing
problems... Any recent issues I should be wary of? There is clearly a
drawing problem with FlatMenu on the Mac currently.
Buffering to a MemoryDC shouldn't be a problem, although since the system is already doing buffered drawing it is essentially redundant. There are some DC related issues in wxMac that you should be aware of however, which on the other platforms are allowed but probably not a "best practice" so it would be wise to change them anyway.
First, you should avoid using wx.ClientDC for anything other than measuring text or other non-drawing operations. The system uses a "pipeline" design for updating the display, where each window that is being updated is in some position in that pipeline with a partially completed result. Normally this is a very good thing as it allows the system to highly optimize drawing the display contents, blend transparencies, etc. But when you use a wx.ClientDC, whose design requires an immediate update of the display when something is drawn to it, causes all the partial drawing currently in the pipeline to be dumped so the client DC's work can be done, and then the pipeline is restarted again. So it leads to efficiency problems and can really slow down the drawing of your windows. The better approach would be to simply do a Refresh() when some new window state needs to be drawn, and then let it happen in the EVT_PAINT event when the system decides that it is your app's turn to be updated. This is almost always quick enough that you don't notice any difference at runtime.
Second, you can not have more than one DC associated with the same window at the same time. This tends to happen in classes where you have methods that you sometimes call by themselves and sometimes they are called from other drawing functions. Instead you should always pass the DC to drawing functions and let the calling code either create the DC itself, or pass along the DC that was passed to it.
···
On 7/24/10 8:41 PM, Mark wrote:
--
Robin Dunn
Software Craftsman