[Pythonmac-SIG] coding preference

[Kevin Ollivier]

Hi Jack,

On Jan 20, 2005, at 3:33 PM, Jack Jansen wrote:

>
> On 19-jan-05, at 18:54, Chris Barker wrote:
>
>> I've never used QT, so I can't speak to the advantages. One reason I 
>> would consider switching, however, is that there are more Scientific 
>> Widgets for QT (like http://qwt.sourceforge.net/). If you don't have 
>> a need for those, then wx should be fine.
>
> I've only used it from C++, and only on Linux (the multimedia projects 
> I do tend to grow platform-dependent UI solutions), but I was 
> favorably impressed. Functionality tends to be in the place where you 
> expect it, which is where most GUI packages break down (including 
> Cocoa), and the documentation is pretty good. For Linux standards 
> things look absolutely great on-screen.
>
> Which brings me to my real point: I don't think a good cross-platform 
> GUI toolkit is possible. Period. There are some things that simply 
> cannot be matched programmatically, specifically when paradigms are 
> different.

I think you're getting bogged down by the differences between platforms 
rather than abstracting them. ;-) Which is what any cross-platform 
developer will need to do if they wish to succeed, regardless of what 
GUI toolkit(s) they use. For the most part, it isn't 'what' the native 
toolkits (or platforms) do that differ, it's 'how' they do it. So if 
you program 'what' you want to do, and design the toolkit to figure out 
'how' to do it correctly on each platform, a lot of times you can get 
the right look *and* feel without much extra effort. Granted, there are 
some technical challenges (look at Apple's Carbon text control 
technologies, like MLTE for example, where sometimes you need to 
manually implement even basic, standard functionality), but I have a 
hard time understanding how these difficulties are insurmountable.

> So while a really good x-platform GUI toolkit may get the "look" 
> right, I don't think it'll ever manage getting the "feel" right. Which 
> means your stuck with the worst of both worlds: something that looks 
> like a (say) Mac application but doesn't behave like it.

Well, that depends on the programmer. Even a Mac developer can create 
an application that doesn't "feel" like a Mac application; it really 
isn't very hard if you try. (And for people coming from Windows, that 
will be their natural inclination anyways.) It's arguable that the 
problem is the toolkit at all - it's the developer simply not taking 
Mac design considerations into effect. Yes, toolkit affects their 
ability to do this, but in the end a tool is just a tool. I see no 
fundamentally technical reason a cross-platform GUI toolkit *cannot* 
provide a user with the ability to create a well-designed Mac 
application.

Heck, if wxPython had some more resources in its corner, I firmly 
believe it would already be doing so. That's the downside of open 
source. We've got the technical expertise to fix most of the issues 
that people have brought up with wxWidgets/wxPython, it's just that 
most of these experts have to handle bread and butter problems first. 
Again, not a technical problem.

(As an aside, wxPython will in its next release have a tool that 
automatically creates standard button layouts that match the platform's 
HIG and even provides "Save" "Don't Save" on Mac. We're also working on 
a way to get and utilize standard "borders/spacing" for various native 
controls, so that you can properly space items in a 
non-platform-specific manner. And IIRC the scrollbars issue is 
*finally* resolved.)

I do agree that it is probably next to impossible for some 
cross-platform GUI toolkit to match the elegance of Apple's libraries 
(or possibly QT), but sometimes the need/desire for elegance is 
superseded by real world constraints like time and money, and if you 
need cross-platform w/ native look and feel, something like wxPython is 
about the best option that's out there.

> My solution: for throwaway applications consider a cross-platform 
> toolkit, for anything serious use MVC and code the view and controller 
> in a platform-native toolkit.

Just be aware that for all but 'throwaway' apps, this means that some 
developer is going to have to learn and master three different GUI 
toolkits, and create, test, debug, document, and package three totally 
different interfaces. Maybe you have time to put in the extra effort 
when writing your apps, but I think a lot of people don't. And when a 
PHB is told that the only way to support a minority platform is to do 
that work, s/he's going to say - sorry, just build the Windows version. 
For my app, I can tell you without doubt - if I had to do what you 
suggest, Mac support would not be an option. Bye bye Mac port.

I performed some training last summer, and to be honest, the Mac users 
at the training were quite glad that a Mac version of my app existed 
and that they weren't marginalized users (as they often end up being in 
the real world) who would need to "pick up a PC" to undergo the 
training. It certainly wasn't as 'slick' as an Apple app, but it worked 
and some people quite liked it. And in the end, that's how I personally 
measure whether a technology is "good" or not. Whether or not it has a 
positive impact.

So my point is, you may very well be advocating an approach which will 
marginalize the Mac platform even further. I know that's not your 
intent, your intent is to see excellent Mac apps get created, but by 
eschewing and not helping approaches like the one wxWidgets takes, and 
in fact by making the toolkit sound useless for any practical purpose, 
you're actually reducing the options that people have, and in doing so 
making Mac support a less attractive option or possibly a simply 
unfeasible one. Does the Mac platform really win in the end if you do 
that?

And the shame of it all is that aside from the ambiguous, off-hand 
comments ("widgets designed by children", "a really good cross platform 
GUI toolkit is not possible") that do little except poke fun at 
projects such as wxPython, we get very little constructive feedback 
about exactly what needs fixing. But I guess if you blindly assume it's 
all "hopeless", then there's little point in that, is there?

Kevin