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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
