Do other Python GUI toolkits require this?

[Michael Bentley]

OK. In order to kill the-thread-that-would-not-die(tm), I think I
know what I must do. I'll print a correction:

... I switched to PyObjC. The
learning curve is rather steep IMO, but worth it. One thing I think
I should mention though is that if you move to PyObjC -- do some
projects in Objective C first. Otherwise your brain will implode.

Should be changed to:

... I switched to PyObjC. The
learning-effort curve is rather steep IMO, but worth it. One thing I
think
I should mention though is that if you move to PyObjC -- do some
projects in Objective C first. Otherwise your brain will implode.

Hope this helps,
Michael ;-)

 

[Kevin Walzer]

OK. In order to kill the-thread-that-would-not-die(tm), I think I know
what I must do. I'll print a correction:



Should be changed to:

.. I switched to PyObjC. The
learning-effort curve is rather steep IMO, but worth it. One thing I think
I should mention though is that if you move to PyObjC -- do some
projects in Objective C first. Otherwise your brain will implode.

Hope this helps,
Michael ;-)

I had originally thought that learning PyObjC might preclude me from
having to learn Objective-C, but that seems not to be the case. I have
previously found the same to be true with PyQt and wxPython--not knowing
the toolkits as they are implemented in C++ is a serious handicap. I've
even found this to be the case with Tkinter: understanding the Tcl
implementation of Tk (which I do, because I am also a Tcl developer) is
a huge advantage.

Am I wrong to conclude that, if you want to do GUI programming in
Python, then some level of proficiency with another language is not just
recommended, but almost required? This is the case at least in my
experience. When I first started learning Python a couple of years ago,
I spun my wheels with it for months, because I couldn't figure out where
to get started with GUI programming. Finally I set Python aside and took
up Tcl/Tk for awhile--its simplicity in building GUI's is more
beginner-friendly. (No "there's more than one way to do it"--there's
only one way to do it, and that's Tk.)

Now, coming back to Python with the Tk model of GUI development burned
in my brain, I appreciate the breadth of functions that Python
supports--but I still find myself "dropping down into Tcl" (!) to
assemble elements of my GUI's--either to write a Python wrapper, or
figure out how to implement something in pure Python.

I understand the argument for Python having lots of bindings to
different GUI toolkits. If you are already proficient with a GUI toolkit
in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
switching to Python will speed up your development--learning Python is
easy if you already know C++, for instance, and usually the Python
bindings are just a "thin wrapper" over the compiled bits. But if you
come to Python from the other direction--you're a relative beginner and
you want to learn GUI programming without the complexities of compiled
languages--then it's a lot harder to get started, ironically. Even
Tkinter is a challenge for someone who doesn't know Tcl. The basics are
easy enough--buttons, menus, labels, images--but doing anything
sophisticated, such as trees, column views, drag-and-drop, and so on,
requires extensions that may or may not be implemented in Python.

 

[Kevin Walzer]

OK. In order to kill the-thread-that-would-not-die(tm), I think I know
what I must do. I'll print a correction:



Should be changed to:

.. I switched to PyObjC. The
learning-effort curve is rather steep IMO, but worth it. One thing I think
I should mention though is that if you move to PyObjC -- do some
projects in Objective C first. Otherwise your brain will implode.

Hope this helps,
Michael ;-)

I had originally thought that learning PyObjC might preclude me from
having to learn Objective-C, but that seems not to be the case. I have
previously found the same to be true with PyQt and wxPython--not knowing
the toolkits as they are implemented in C++ is a serious handicap. I've
even found this to be the case with Tkinter: understanding the Tcl
implementation of Tk (which I do, because I am also a Tcl developer) is
a huge advantage.

Am I wrong to conclude that, if you want to do GUI programming in
Python, then some level of proficiency with another language is not just
recommended, but almost required? This is the case at least in my
experience. When I first started learning Python a couple of years ago,
I spun my wheels with it for months, because I couldn't figure out where
to get started with GUI programming. Finally I set Python aside and took
up Tcl/Tk for awhile--its simplicity in building GUI's is more
beginner-friendly. (No "there's more than one way to do it"--there's
only one way to do it, and that's Tk.)

Now, coming back to Python with the Tk model of GUI development burned
in my brain, I appreciate the breadth of functions that Python
supports--but I still find myself "dropping down into Tcl" (!) to
assemble elements of my GUI's--either to write a Python wrapper, or
figure out how to implement something in pure Python.

I understand the argument for Python having lots of bindings to
different GUI toolkits. If you are already proficient with a GUI toolkit
in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
switching to Python will speed up your development--learning Python is
easy if you already know C++, for instance, and usually the Python
bindings are just a "thin wrapper" over the compiled bits. But if you
come to Python from the other direction--you're a relative beginner and
you want to learn GUI programming without the complexities of compiled
languages--then it's a lot harder to get started, ironically. Even
Tkinter is a challenge for someone who doesn't know Tcl. The basics are
easy enough--buttons, menus, labels, images--but doing anything
sophisticated, such as trees, column views, drag-and-drop, and so on,
requires extensions that may or may not be implemented in Python.

 

[Diez B. Roggisch]

I had originally thought that learning PyObjC might preclude me from

having to learn Objective-C, but that seems not to be the case. I have
previously found the same to be true with PyQt and wxPython--not knowing
the toolkits as they are implemented in C++ is a serious handicap. I've
even found this to be the case with Tkinter: understanding the Tcl
implementation of Tk (which I do, because I am also a Tcl developer) is
a huge advantage.

Am I wrong to conclude that, if you want to do GUI programming in
Python, then some level of proficiency with another language is not just
recommended, but almost required? This is the case at least in my
experience. When I first started learning Python a couple of years ago,
I spun my wheels with it for months, because I couldn't figure out where
to get started with GUI programming. Finally I set Python aside and took
up Tcl/Tk for awhile--its simplicity in building GUI's is more
beginner-friendly. (No "there's more than one way to do it"--there's
only one way to do it, and that's Tk.)

Now, coming back to Python with the Tk model of GUI development burned
in my brain, I appreciate the breadth of functions that Python
supports--but I still find myself "dropping down into Tcl" (!) to
assemble elements of my GUI's--either to write a Python wrapper, or
figure out how to implement something in pure Python.

I understand the argument for Python having lots of bindings to
different GUI toolkits. If you are already proficient with a GUI toolkit
in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
switching to Python will speed up your development--learning Python is
easy if you already know C++, for instance, and usually the Python
bindings are just a "thin wrapper" over the compiled bits. But if you
come to Python from the other direction--you're a relative beginner and
you want to learn GUI programming without the complexities of compiled
languages--then it's a lot harder to get started, ironically. Even
Tkinter is a challenge for someone who doesn't know Tcl. The basics are
easy enough--buttons, menus, labels, images--but doing anything
sophisticated, such as trees, column views, drag-and-drop, and so on,
requires extensions that may or may not be implemented in Python.

I personally can't conclude with your conclusions

Some background: I've started with Tcl/Tk as a scripting language precisely
because of Tk - I liked the easy GUI creation, the layout management, and
it was available for Unix/Linux, my OS of choice.

So when I discovered Python about 7 or 8 years ago, I certainly had the
right mindset for Tk. So, I was able to create GUIs in Tkinter, yet it
never felt very comfortable - it just has too much Tclisms in there for my
taste.

So for GUI-development, I moved on to Qt - and simply loved it. I do have
some C++-skillz, although these are somewhat rusty. And all I needed them
for was reading the excellent reference Qt-documentation. Just the
class-docs, not examples!

The last step then was PyObjC. I bought a mac roughly two years ago, and
immediately got interested in GUI-development there. I've never done a
single bit of ObjectiveC before, and even though I now have some few
classes done (mainly for interfacing with parts of OS X or other libraries
that weren't exposed to python, e.g. CIImage and CGImage processing), I
wouldn't say that I'm an ObjectiveC-programmer.

The hardships for me with PyObjc stemmed from the unawareness and
unfamiliarity with the specifics of GUI-development under the mac in
general. E.g. the concepts of NIBs, NIB-classes, bundles and the like.

Now admittedly I'm not a totally fair comparison to you for judging the
matters at hand - I had a fair amount of exposure to different languages
before and while learning python. But especially for PyObjC I can say that
I became productive pretty fast without having to actually do serious or
even not so serious ObjectiveC-development.

I'd rather say that using a gui-toolkit usually requires to adapt to
whatever concepts that toolkit has implemented. And certainly there are
some of these that are influenced by the language the toolkit has been
developed for. But for example ObjectiveC and Python both allow for dynamic
dispatch - thus lots of the design decisions would have been the same. And
as ObjecC and Cocoa heavily rely on NSArray and NSDictionary, which the
bridge has good marshalling code for, using python's lists & dicts is
natural and easy.

In Qt OTOH they implemented their dynamic dispatch themselves - but using
slots and signals is easy as cake as well. To me at least

Diez

 

[David Boddie]

I had originally thought that learning PyObjC might preclude me from
having to learn Objective-C, but that seems not to be the case. I have
previously found the same to be true with PyQt and wxPython--not knowing
the toolkits as they are implemented in C++ is a serious handicap.

I'm not so sure about that. Certainly, it's useful to be able to read C++
example code, but none of the examples you see should require more than
a basic proficiency in C++.

I started using PyQt before I had more than basic C++ skills, and I don't
think it slowed me down too much.

I've even found this to be the case with Tkinter: understanding the Tcl
implementation of Tk (which I do, because I am also a Tcl developer) is
a huge advantage.

Am I wrong to conclude that, if you want to do GUI programming in
Python, then some level of proficiency with another language is not just
recommended, but almost required? This is the case at least in my
experience. When I first started learning Python a couple of years ago,
I spun my wheels with it for months, because I couldn't figure out where
to get started with GUI programming.

Of the common toolkits and frameworks, I started using Tkinter because
that's what came with Python, but I can't say that I'm comfortable with
it. Once I started using PyQt, I started to forget Tkinter, and now I
don't have a reason to go back to using it.

Finally I set Python aside and took
up Tcl/Tk for awhile--its simplicity in building GUI's is more
beginner-friendly. (No "there's more than one way to do it"--there's
only one way to do it, and that's Tk.)

Now, coming back to Python with the Tk model of GUI development burned
in my brain, I appreciate the breadth of functions that Python
supports--but I still find myself "dropping down into Tcl" (!) to
assemble elements of my GUI's--either to write a Python wrapper, or
figure out how to implement something in pure Python.

While this is one of the strengths of Tcl/Tk/Tkinter, I think this is a
relatively rare thing to do with other toolkits and frameworks. For example,
there are people writing wrappers around Qt-based classes, but the only
people writing wrappers for Qt or KDE classes are the bindings authors
themselves.

I understand the argument for Python having lots of bindings to
different GUI toolkits. If you are already proficient with a GUI toolkit
in a compiled language (Gtk, wxWidgets, Cocoa, Qt) then presumably
switching to Python will speed up your development--learning Python is
easy if you already know C++, for instance, and usually the Python
bindings are just a "thin wrapper" over the compiled bits.

Yes and no. The bindings may be thin, but there are often other advantages
that make the bindings subtly different/better to use than the underlying
toolkit/framework.

From memory, PyGTK is more natural to use the GTK+ on its own because Python
provides the object-oriented features that you don't get in C, though there
are C++ bindings to GTK+ as well.

Another example would be the way PyQt handles Qt's signals and slots. In C++
you need to declare these with specific signatures at compile time, but
that would be a bit restrictive in Python. The result is that PyQt lets you
define and connect arbitrary signals, slots and normal Python methods at
run-time. (Actually, you don't even need to define signals.)

So, even the thin wrappers contain some value other than simply enabling you
to use Python.

But if you come to Python from the other direction--you're a relative
beginner and you want to learn GUI programming without the complexities of
compiled languages--then it's a lot harder to get started, ironically.
Even Tkinter is a challenge for someone who doesn't know Tcl. The basics
are easy enough--buttons, menus, labels, images--but doing anything
sophisticated, such as trees, column views, drag-and-drop, and so on,
requires extensions that may or may not be implemented in Python.

I think that's a specific Tkinter problem in many ways. However, the
expectations of many new users have also increased since I wrote my first
GUI program in Python, and that also influences the way people respond to
the different solutions on offer.

David

 

[James Stroud]

Kevin Walzer a écrit :
(snip)



Noticed this too ?-)

I would have noticed, but my learning curve is rather steep.

(Did I use that right?