[Pythonmac-SIG] Objective C and Cocoa

[Kevin Ollivier]

Hi Ronald,

On Wednesday, October 15, 2003, at 11:59  AM, Ronald Oussoren wrote:

>
> On 15 okt 2003, at 20:36, Bob Ippolito wrote:

[snip comments about GNUStep portability]

>>
>> Honestly, I don't care if it's a closed source single platform 
>> framework.  What I care about is getting stuff done as elegantly and 
>> effortlessly as possible on the platform of my choice.  Kludge sucks. 
>>  But in any case, there's GNUStep, so in theory in the near future 
>> (as near as we, the open source community, make it) all this stuff 
>> would work on Linux and (with some work on the win32 port of GNUStep) 
>> win32.
>
> I don't care too much about having GNUstep available for when I'd like 
> to move to Linux. AFAIK the GNUstep folks want to recreate NeXTstep, 
> without much integration in the dominant desktop environments.
>
> GUI programs should contain of a portable core and a platform 
> dependent GUI layer on top of that, this makes it a lot easier to make 
> the look&feel just right for a given platform. wxWindows and other 
> x-platform toolkits get close, but it is often noticeable that a GUI 
> was developed on a foreign platform.

Actually, you've hit on a good point here - one that has to deal with 
the developer (and the platform they're comfortable with) rather than 
the tools themselves. The real problem is not that wxWindows can't be 
used to write a solid Mac application (though yes it still needs tweaks 
and bug fixes to make it OS X optimized), the problem is that the 
developers using the toolkit don't know what interface paradigms (i.e. 
MDI) work on platform X but not on platform Y. So when writing 
behaviors, they tend to lean towards the same behaviors that exist on 
their primary platform. I think the solution here is that there needs 
to be a cross-platform "HIG" like the one Apple has for Mac, so that 
the developers know that by using certain interface elements or 
implementing certain behaviors that they aren't committing a no-no on 
any particular platform.

IMHO, wxWindows is close enough that it's in 'bug fix' mode to tweak 
any problems that arise, as well as optimizing code to take advantage 
of Mac-only features whenever possible. The only major control that 
doesn't do the right thing on Mac, that I know of, is the wxListCtrl, 
which needs to be have its internal implementation moved to the 
DataBrowserControl instead of the ListCtrl that Mac classic/carbon uses.

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".

Thanks,

Kevin