[Pythonmac-SIG] Mac User Python newbies

[Roger Binns]

> Even still, given how wrong it is for NetBSD, I find it hard to assign 
> any weight at all to what sourceforge's numbers are.

http://freshmeat.net/browse/199/

Quite simply my experience has been that there is a large amount of
open source for Windows, despite Microsoft's general disdain for it.
I believe a lot of this is because there is such a large user base.

> That article is four and a half years old, and it doesn't account for a 
> lot of things.  

None of his points have been invalidated.  The market share numbers
are roughly the same.  Yes there will be different cases such as
yours.  There used to be a belief, especially from the UNIX
community that the right thing to do is support all platforms
equally and at the same time for a first release.  Noone believes
that any more.

> together.  There is a disproportionate amount of support requests on 
> the Windows side, but that's because it more or less Just Works on the 
> Mac, where there seems to be some weirdness on some obscure Windows 
> configurations that we can't reproduce (unfortunately we're at the 
> mercy of some other software and hardware for this product).

Handling support is one of the biggest difficulties for general
consumer software these days.  Most companies try to do it by
hiding the costs (include the price into the software), treating
all customers equally and treating support as a loss centre
and try to minimise its costs.  That typically ends up frustrating
the users and the company.

I think the next generation of successful companies will be
those that figure out better solutions to the support side.
It may involve telling some customers to go away.  One trend
is definitely to improve the amount of diagnostics available
to track down issues.  Python is really cool for this.  You
can get traces including information down to the variable
level.  Here is an example:

http://article.gmane.org/gmane.comp.mobile.bitpim.user/2218

The holy grail would a diagnostics dump that can be fed
into virtualisation software that then sets up everything
in the same way :-)

> The user also doesn't care if the UI code isn't shared between all 
> platforms as long as they're maintained.  The Tkinter GUI and the 
> PyObjC GUI share a bunch of code (as much as is reasonable).  The 
> Tkinter GUI actually has code in it to emulate a bunch of Mac-isms and 
> it reads resources directly out of its sibling Mac OS X bundle 
> (metadata, localization, and the application's data).  I'd have used 
> wx, but Tkinter was easier for this and wasn't as big.

I originally did my first Python guis using Tkinter.  In the end I
was very annoyed that I had to write my own combobox widget, and
moved to wxPython and have been very happy there ever since.  It
looks like Tkinter still doesn't address things like printing,
drag and drop and various other things needed by full featured
applications.

When choosing a Python gui toolkit for BitPim, these were the main
points:

 Tkinter  

    Lowest common denominator 
    Draws widgets itself 
    Unpleasant prior experience 
    Stagnant 

 Qt  

    High common functionality 
    Not open source on Windows 
    Draws widgets itself 

 GTK  

    Linuxy 
    Draws widgets itself 

 wxWidgets/wxPython 

    High common functionality 
    Uses native widgets where possible 
    Very active community 
    Pleasant prior experience 

More detail is at http://bitpim.org/papers/baypiggies/

Roger