[Pythonmac-SIG] Re: Best Python GUI for Arabic, etc.

[Kevin Ollivier]

Hi Gary,

There is a page for OS X/Mac issues but it is a bit hidden. To get 
there, you go to the wxPython Wiki, select "Other Docs", then 
"wxPythonOSX issues". Here's the link:

http://wiki.wxpython.org/index.cgi/wxPythonOSX_20Issues

The buttons issue has been resolved. As for the other issues, I'll try 
to take a look at them and see what can be done, but if you could go 
ahead and post a note to the wiki page it would be very helpful.

One thing to note too, is that some of the issues (i.e. header tab 
spacing) may be a result of wxMac trying to adhere to Apple's Human 
Interface Guidelines. It's important to Mac users that applications 
follow those guidelines, so wxMac does try to follow them, even if it 
may cause some visual differences between the Mac version and those for 
Windows/Linux. (If the spacing is off and it is not following the 
guidelines, however, then that most certainly needs to be fixed.)

Thanks,

Kevin

On Jan 19, 2004, at 8:12 PM, Gary Shao wrote:

> Hi,
>
> Thanks Kevin for the update on wxPython. I've only recently tried 
> running an existing wxPython
> script that works fine on Linux and Windows machines on a Mac OS X 
> box. I quite quickly
> observed some of the visual irregularities mentioned when people talk 
> about the status of
> wxPython on the Mac. The most readily apparent problems were rounded 
> buttons that were
> surrounded by white rectangles and tab headers that had poor spacing 
> when compared to
> what appeared on Linux and Windows. Another problem that showed up on 
> the Mac version
> was the GetValue method of a wxTextCtrl object not returning the 
> correct value unless
> the user manually changed the value (for instance simply backspacing 
> over one letter of the
> default value shown and typing the same letter back in).
>
> When I looked through the wxPython site, I could find no mention of 
> known problems with the
> Mac implementation. This meant there was no way to know whether any 
> problems I found
> were already known and whether they were already fixed for later 
> releases, planned for being
> worked on, or would continue in later versions until someone addressed 
> them.  I'm interested in
> writing Python applications that are truly cross-platform, and would 
> appreciate having some
> pointers on where the status of specific Mac issues can be found. 
> Thanks again.
>
>    --Gary
>
>> There should be a wxPython 2.5.1 release in the very near future (1-2 
>> weeks max, maybe even sometime next week) and from my testing on 
>> Panther there have been major improvements. It still uses 5-9% CPU 
>> time on idle, but maxes out at about 20% as opposed to the 50% max 
>> Bob measured previously (yes, that's when using wxSTC). Load times 
>> range in the 4-6 second range, depending on what else you've got 
>> going on. Most of my testing was on an 800Mhz iMac, but it seemed 
>> even faster on my 1Ghz PowerBook. =)
>>
>> And we're not done yet. =) In the very near future, Classic support 
>> is getting separated so that we can maximize the Carbon port using 
>> Carbon Events, etc. This should bring down the idle CPU time down 
>> even further as we delegate more of the idle event handling to 
>> Apple's Window Manager. We're also going to implement HIView for 
>> Jaguar+.
>>
>> As for Unicode support, there's still a few issues to be worked out, 
>> the main one being that Mac APIs use short-wchar-t (2 bytes) while 
>> wxMac expects the 4-byte implementation. The result is that we get 
>> clipped text. This shouldn't be difficult to resolve, however 
>> (implement --fshort-wchar in configure and maybe set a define), and 
>> once I get out the latest release of wxMozilla I'll take a look into 
>> making this work.
>>
>> However, while wxPython 2.5 is probably more stable than its 2.4 
>> counterpart, this is all very new so unless you're adventurous and 
>> have patience for dealing with the little quirks that arise, it might 
>> be best as Bob suggested to prototype the app in PyObjC, and then 
>> come back to wxPython when you need to really make your app 
>> cross-platform. Either that, or start writing your code on Linux or 
>> Windows using wxPython then move it over to Mac later. I would also 
>> agree that wxPython is a better choice than Tkinter and pyQT/pyGTK 
>> for Mac, but then again I'm a bit biased. ;-)
>>
>> Thanks,
>>
>> Kevin
>>
>>
>>
>
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>