[Pythonmac-SIG] Objective C and Cocoa

[Bob Ippolito]

On Wednesday, Oct 15, 2003, at 23:41 America/New_York, Kevin Ollivier 
wrote:

> On Wednesday, October 15, 2003, at 02:12  PM, Martina Oefelein wrote:
>
>>> The main reason I'm so keen on wxWindows is that other toolkits 
>>> commonly have the problem that they were *written* specifically for 
>>> one platform, then ported to another. (Often using 'themes' to mimic 
>>> look - ugh.) Portability wasn't necessarily an initial goal, but 
>>> people started saying "Oh, can I run this on platform Y too?". Thus 
>>> even though they run on other platforms, there are a lot of internal 
>>> assumptions in the code which make it not really portable. *nix apps 
>>> tend to follow Windows conventions to some extent so the change 
>>> isn't so dramatic, but when porting a *nix toolkit to Mac or vice 
>>> versa, it is bound to at least feel strange on the other platform. 
>>> wxWindows is by far the closest thing I know of to something that 
>>> "does the right thing".
>>
>> well, I must admit I haven't tried to use it yet, but the terminology 
>> and documentation I browsed so far feels rather Windows-ish. For 
>> example, "window" is encompassing controls and views as well as 
>> "real" windows (which are called "frames" in wxWindows). Other 
>> examples are SDI/MDI, per-window (pardon, per-frame) menus, right 
>> moues button, key names etc. That gives me (still) the impression of 
>> a "ported" toolkit and lets me wonder whether it would be possible to 
>> develop wxWindows apps using the Mac as main development platform.
>>
>> Thus I believe one would often have to think "backwards" to realize a 
>> particular feature - translating from Mac into (wx)Windows concepts 
>> and terminology, and hoping that wxWindows will translate this into 
>> the desired Mac look & behaviour.
>
> There are a couple issues merged together here, so let me address them 
> individually:
>
> - terminology: Impressions/perceptions are hard to predict, and they 
> are largely based on the developer's predisposition and experiences. 
> (i.e. a developer who only/primarily develops on Mac will react to the 
> terminology differently than someone familiar with many platforms) It 
> is very true that wxWindows' terms may make some developers wonder if 
> it works or not as a Mac development tool; IMHO, the only issue is 
> whether or not they will take the time and effort to find out whether 
> or not their theory is correct. =)
>
> BTW, one can install wxPython and run the demo located at 
> /Applications/wxPythonOSX-2.4.x.x to see just about every major 
> wxWindows component in action.
>
> - functionality/paradigms: It's true that wxWindows supports the use 
> of some platform-specific paradigms, like per-frame menues. Developers 
> who care about Mac support will of course avoid them, and probably use 
> Mac-specific development practices as much as possible. If the 
> developer doesn't care about Mac support, it is fair to ask why they 
> shouldn't be allowed to use per-frame menues, for example. In that 
> sense, the pendulum swings both ways in that it is quite possible that 
> Mac-specific classes will be added to the Mac port, like wxDrawer, if 
> there's a demand for them. Also, Mac developers could just as easily 
> write ugly/bad applications using Carbon (and they do exist) if they 
> chose to ignore the Aqua HIG. wxWindows just makes Mac support *much* 
> simpler (and in some cases trivial) to implement. It's up to the 
> developer to decide whether or not they want Mac support.
>
> BTW, with regards to your specific points, it does properly interpret 
> CTRL+click as a right-click on Mac, as can be seen in the demo. And 
> since you can buy 2-button mice on Mac (and I use one) I don't think 
> talking about right clicks are totally inappropriate. =) It also 
> automatically does a number of other little things, like renames 
> "Exit" to "Quit" on Mac (for OS 9), lets you plug into the application 
> menu (on OS X) and changes CTRL+key shortcut keys to COMMAND+key on 
> Mac.
>
> Let me finally say that cross-platform applications can only be made 
> easier by a toolkit like wxWindows; there will not be a magic bullet 
> which makes it a non-issue. If I'm a developer who wants to optimize 
> for OS X (and I am =), I'll have to think about what I can do to make 
> my app more friendly to OS X users and focus on following the Apple 
> HIG. In any case, you are right that developers will need to 'think 
> different' when using a cross-platform toolkit, but in my experience 
> wxWindows is the best of the bunch when trying to make Mac-friendly 
> cross-platform applications.

I think that the point that Ronald was trying to make earlier is that 
sometimes it's best to just develop multiple GUI frontends.  It's 
definitely easier to develop a PyObjC+Cocoa application than a wxPython 
application assuming you like using OS X (subjective, but I don't think 
many of you will disagree).  Cocoa encourages good model/view 
separation.  So theoretically if you write it with Cocoa first, it 
shouldn't be terribly hard to write (or hope someone else writes) 
another frontend on top of that, whether that's wxWindows, GTK, or 
whatever.  Nothing you've said so far leads me to believe that trying 
to make wxWindows fit both GUI paradigms (win32/linux and mac) is less 
effort than making wxWindows do what it does best (win32/linux) and 
spending the "mac thinking" time just writing a PyObjC/Cocoa frontend 
for Mac.  wxWindows makes porting to the Mac easiest for people who 
don't own a Mac.  In which case, they'll probably design it such that 
it's not consistent with the Apple HIG anyway.  Of course, in some 
situations the application is more important than the interface, and 
the Mac user just won't care so much because it does what they need it 
to do.

-bob