On Thu, Sep 16, 2010 at 7:46 PM, Eric Frederich <eric.freder...@gmail.com> wrote: > > I think that seems to be my problem. > Just way too many ways to skin this cat. > I'd hate to say something good about Java (especially now that they're owned > by Orable) but there were much less options for me to get overwhelmed with. > Perhaps after I'm done being overwhelmed I'll welcome the multitude of > options. > Its just at this early stage I don't want to start going down the wrong > path.
Choosing is always an effort, but better several choices than none IMHO... A large part of my initial relationship with (Py)Qt has consisted of spending an hour to write fifty lines of (working) code... then spend another two bringing that line count to five or so, after discovering the magic API I had been duplicating :-) Now I spend more time upfront in the Qt docs, and looking for prior art on the Web (of which there is a lot), and things are much smoother. One particular thing that tripped me badly in the early days, being not well versed in object-oriented practice, was working from the PyQt docs on the Riverbank website. They're useful and indispensable in that they alone explain the differences between the C++ Qt APIs and their Python equivalents. Their drawback is that they *only* present the APIs (slots, signals etc.) that are specific to the current object. I often puzzled why a given object didn't offer a way to do this and that, only to realize afterwards that it did have that method, but inherited from parent classes several levels above, sometimes all the way back to QWidget... The Qt version offers to list everything an object has to offer, inherited or not, which is easier on newbies (if sometimes overwhelming :-). Learning to walk, then to ride a bike, is difficult too. But you get a lot of mileage after that (bad pun intended). _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
