Python GUI?

[Joe Junior]

Pressing keys on a keyboard was never the hard part of coding.

Nor the fun part.

Joe

 

[eamonnrea]

I disagree with you. It's not hard, and I apologise if its ever sounded that way, but it is the fun part for me. I love spending hours(days even) debugging.

Well, thanks all for depressing me. Time to give up programming and find something else to do with my life.

 

[Terry Reedy]

With the themed widget introduced in Tk 8.5, Tkinter is now a peer to
the other GUI toolkits in most respects, surpasses them in some (canvas
widget), and lags behind in just two areas: printing (several
platform-specific solutions but no cross-platform API) and HTML display
(a few extensions but no standard widget set).

I would add the ancient and limited image support, both for input and
canvas output. Modern SVG output instead of ancient (possibly buggy)
PostScript would be a real improvement.

Otherwise, I have become more impressed with the text widget as I have
studied the Idle code. Even that does not use everything. I have not
looked at the text widget in other guis to compare.

 

[Joe Junior]

I disagree with you. It's not hard, and I apologise if its ever sounded that way, but it is the fun part for me. I love spending hours(days even) debugging.

Well, thanks all for depressing me. Time to give up programming and find something else to do with my life.

lol! You made my day. :-D

Well, you can always ignore any and all graphical design tools if
you're working alone. And write all those Xs and Ys and widths and
heights all day long. None of the mentioned graphical toolkits forces
you to use them.

And if you like debugging, GUI is not the main dish! Try networking
and concurrent programming, loads and loads of fun!

Of course, that's lots of other unnecessary time consuming stuff you
can do. You just have to use your imagination.

Joe

 

[Neil Cerutti]

Nor the fun part.

When John Henry was a little baby,
Sittin' on his daddy's knee,
He Telneted to the server with a tiny bit of code, and said:
Emacs will be the death of me, Lord, Lord!
Emacs will be the death of me.

Well John Henry said to the captain:
Go on and bring your toolkit round,
I'll pound out your GUI with a hundred thousand keystrokes,
And throw that GUI Builder down, Lord, Lord!
I'll throw that GUI Builder down.

Well John Henry hammered on his keyboard,
Till is fingers were bloody stumps,
And the very last words that were entered in his .blog were:
GUI Builders are for chumps, Lord, Lord!
Those GUI builders are for chumps.

 

[eamonnrea]

lol! You made my day. :-D



Well, you can always ignore any and all graphical design tools if

you're working alone. And write all those Xs and Ys and widths and

heights all day long. None of the mentioned graphical toolkits forces

you to use them.



And if you like debugging, GUI is not the main dish! Try networking

and concurrent programming, loads and loads of fun!



Of course, that's lots of other unnecessary time consuming stuff you

can do. You just have to use your imagination.



Joe

I was planning on getting into networking, but like I said, thanks to most people encouraging less coding, I don't code anymore. Glad I made your day though. And "unnecessary time consuming stuff" -- That's my problem. Is*shouldn't* be unnecessary! It should be something that has to be done. That's what annoys me!!

 

[eamonnrea]

When John Henry was a little baby,

Sittin' on his daddy's knee,

He Telneted to the server with a tiny bit of code, and said:

Emacs will be the death of me, Lord, Lord!

Emacs will be the death of me.



Well John Henry said to the captain:

Go on and bring your toolkit round,

I'll pound out your GUI with a hundred thousand keystrokes,

And throw that GUI Builder down, Lord, Lord!

I'll throw that GUI Builder down.



Well John Henry hammered on his keyboard,

Till is fingers were bloody stumps,

And the very last words that were entered in his .blog were:

GUI Builders are for chumps, Lord, Lord!

Those GUI builders are for chumps.

I don't fully understand the meaning of that, but that was a good poem!

 

[Steven D'Aprano]

I disagree with you. It's not hard, and I apologise if its ever sounded
that way, but it is the fun part for me. I love spending hours(days
even) debugging.

Well, thanks all for depressing me. Time to give up programming and find
something else to do with my life.

What on earth are you talking about?

If you like cutting trees down with an axe, the existence of chainsaws
doesn't stop you from still using an axe.

If you don't like GUI app builders, don't use one.

 

[eamonnrea]

But is it efficient to use an axe? Is it sensible to use an axe when there is a chainsaw? No. Eventually, everyone will be using chainsaws, and no one will be using axes. This is my point: to have fun and be productive, but apparently it's not possible.

 

[Dave Angel]

I disagree with you. It's not hard, and I apologise if its ever sounded that way, but it is the fun part for me. I love spending hours(days even) debugging.

Well, thanks all for depressing me. Time to give up programming and find something else to do with my life.

I expect that this thread has all been a troll, but on the off chance
that I'm wrong...

I spent 40+ years programming for various companies, and the only GUI
programs I wrote were for my personal use. Many times I worked on
processors that weren't even in existence yet, and wrote my own tools to
deal with them. Other times, there were tools I didn't like, and I
wrote my own to replace them. One example of that is the keypunch.
Another is paper tape punch. I was really glad to stop dealing with
either of those.

Still other times, tools were great, and I used them with pleasure. If
the tool was flexible, I extended it. And if it was limited, I
replaced it, or found a replacement.

Many times I've chosen a particular approach to solving a problem mainly
because it was something I hadn't done before. On one project, I wrote
code whose job was to generate about 40,000 lines of C++ code that I
didn't feel like typing in, and maintaining afterward. The data that
described what those lines should look like was under the control of
another (very large) company, and they could change it any time they
liked. Most changes "just worked."

If you seriously can't find anything interesting to do in software, and
tools to do it with, then maybe you should take up fishing. With a
bamboo pole and a piece of string.

 

[Michael Torrie]

So, you are recommending not to code as much? :'( That is what
depresses me. These "tools" depress me!

And some people think that automatic transmissions are depressing. To
each his own.

I don't understand why people don't want to code. It's time
consuming: But that's the point!!! It *should* be time consuming. It
*should* take time to make programs. Speed isn't the main thing, fun
is. And these "tools" are taking the fun away.

And nothing in Gtk, Qt, Tk, wx, or any other modern toolkit prevents you
from declaratively creating your GUI. And for small programs there's
nothing wrong with coding the gui by hand (and in fact I recommend it).

As complexity rises, though, I'd rather just code the creative parts of
things, and not busy-code, which is what gui code becomes. Much of it
is boiler-plate, cut and pasted, etc.

 

[eamonnrea]

(e-mail address removed) writes:






Which criterion is more important to *you* — fun, or efficiency?






Which criterion is more important to *you* — fun, or sensibility?







Which criterion is more important to *you* — fun, or popularity?







Who has said that's not possible? If you find using a tool to be both

fun and productive, use it and be happy. If not, use something else.



--

\ “They can not take away our self respect if we do not give it |

`\ to them.” —Mohandas Gandhi |

_o__) |

Ben Finney

I hadn't thought of it that way! Thanks! I suppose it's like saying "Whyuse a MacBook when you could use X computer instead? Because I prefer Macs".

Also, this thread hasn't been a troll. I'm completely serious. Why is it when I ask things like this people think I'm trolling??

 

[Chris Angelico]

Also, this thread hasn't been a troll. I'm completely serious. Why is it when I ask things like this people think I'm trolling??

This is python-list. We're used to duck-typing. If it looks like a
file, we can write to it... if it looks like a troll, we can "throw
eggs" to try to get it to move away from the rickety bridge, then type
"fee; fie; foe; foo" to get the eggs back.

Hmm. Am I showing my age, or my nerdiness?

ChrisA

 

[Wolfgang Keller]

As complexity rises, though, I'd rather just code the creative parts

of things, and not busy-code, which is what gui code becomes. Much
of it is boiler-plate, cut and pasted, etc.

If much of the code for a GUI is boiler-plate, busy-code etc. than I
would suggest that the framework is not really as efficient as it
should be.

In fact that's one of the issues I still have with Python: The language
in general is very efficient, allows to do a lot with very little code.
But all GUI frameworks that I had a look at seem to be not "pythonic"
at all in this regard. Except for PyGUI maybe, but that's far from being
as extensive as wxPython or PyQt. So for GUI applications, Python
doesn't seem to have any advantage over #§$%&! like C++ etc. concerning
code efficiency.

X-(

Sincerely,

Wolfgang

 

[Dave Cook]

If much of the code for a GUI is boiler-plate, busy-code etc. than I
would suggest that the framework is not really as efficient as it
should be.

There are very few Python GUI frameworks as such. They are almost all
just toolkits, not frameworks in the sense of, say, Django.

Enthought has some interesting GUI framework projects which I haven't
tried:

http://code.enthought.com/projects/

Dabo would be another example.

Dave Cook

 

[rusi]

The main difference between wx and qt is that qt looks native on every platform
while wx *is* native on every platform (it uses native controls wherever
possible). This means that wx integrates into the OS better, but your also more
likely to need OS-specific tweaks in wx, at least from my experience from a few
years ago.

For someone who is GUI-challenged, can you please expand on that a bit?

 

[Benjamin Kaplan]

For someone who is GUI-challenged, can you please expand on that a bit?
--

Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
Win32 on Windows). Other programs that want to hook into yours, such
as screen readers, are familiar with the platform's native GUI
elements- it knows what a Win32 combo box is, and it knows how to read
the text inside it.

The other way to make a GUI is to take a blank canvas and draw on it
yourself. This is more flexible and provides a more consistent
experience across platforms, but unless you specifically go out of
your way to provide hooks for other programs to jump in, all they see
is a bunch of pixels on the screen. In addition, drawing your own
stuff won't necessarily give you the "normal for the operating system"
behavior on other things, like tab behavior. It's possible for
non-native GUI environments to mimic this behavior (and QT does a
pretty good job of this), but there's always going to be little things
that seem a bit off.

The situation is a bit more complicated because QT is the native
toolkit on KDE, so in that environment, QT will be more "correct" than
wx, which would be using GTK if present and plain X11 if it isn't.

 

[rusi]

Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
Win32 on Windows). Other programs that want to hook into yours, such
as screen readers, are familiar with the platform's native GUI
elements- it knows what a Win32 combo box is, and it knows how to read
the text inside it.


The other way to make a GUI is to take a blank canvas and draw on it
yourself. This is more flexible and provides a more consistent
experience across platforms, but unless you specifically go out of
your way to provide hooks for other programs to jump in, all they see
is a bunch of pixels on the screen. In addition, drawing your own
stuff won't necessarily give you the "normal for the operating system"
behavior on other things, like tab behavior. It's possible for
non-native GUI environments to mimic this behavior (and QT does a
pretty good job of this), but there's always going to be little things
that seem a bit off.

Thanks for the explanation. However I am not able to square it up:

You seem to be saying that QT draws on a blank canvas rather than calling out to the OS library.
You also seem to be saying that QT (for the most part) Does the Right Thing for each platform.

 

[Benjamin Kaplan]

Thanks for the explanation. However I am not able to square it up:

You seem to be saying that QT draws on a blank canvas rather than calling out to the OS library.
You also seem to be saying that QT (for the most part) Does the Right Thing for each platform.
--

Right. The QT developers have been working for years to get their
controls to quack like the native ones, even though they aren't
native. They started from controls that looked and worked the same on
all platforms and have been trying to get them to play nicely with the
environment they're running in. wx has been working from the opposite
direction- they started with wrapping the native API and have been
working on getting their API to make programs come out the same even
when using different underlying toolkits. When I used wx about 5 years
ago, some of the layout got messed up when we first ran the program
(developed on Linux/GTK+) on a Mac because of some differences
between how Carbon and GTK+ draw their controls.

 

[Michael Torrie]

Sure. Every platform provides its own GUI library (Cocoa on Mac OS X,
Win32 on Windows). Other programs that want to hook into yours, such
as screen readers, are familiar with the platform's native GUI
elements- it knows what a Win32 combo box is, and it knows how to read
the text inside it.

The other way to make a GUI is to take a blank canvas and draw on it
yourself. This is more flexible and provides a more consistent
experience across platforms, but unless you specifically go out of
your way to provide hooks for other programs to jump in, all they see
is a bunch of pixels on the screen. In addition, drawing your own
stuff won't necessarily give you the "normal for the operating system"
behavior on other things, like tab behavior. It's possible for
non-native GUI environments to mimic this behavior (and QT does a
pretty good job of this), but there's always going to be little things
that seem a bit off.

The situation is a bit more complicated because QT is the native
toolkit on KDE, so in that environment, QT will be more "correct" than
wx, which would be using GTK if present and plain X11 if it isn't.

I don't think the distinction you're drawing is really all that
important. Almost all platforms now have accessibility APIs which are a
way better way to go than relying than trying to scrape the information
by peaking into GUI structures that could change.

And on Windows, while the Win32 widget stuff you speak of is a lowest
common denominator, few modern apps use it directly anymore. MS Office
set the the example early on by creating a new widget set for every
release (using the blank canvas method you describe!). .Net apps using
winforms use yet another widget set. They all now use the theming API
to draw their widgets (just like Qt does on Windows), but do their own
even processing, etc.

And it turns out that wxWidget's use of the old win32 widgets means that
some widgets just look plain old and out of place on a new Windows 7 or
8 machine, though MS has tried to make the older widgets work better
with the new theming api:

http://wiki.wxwidgets.org/WxFAQ#Why_does_my_app_take_a_Windows-95-like_look_on_Windows_.3F

My point is, the former method isn't actually the best way to go in the
long run. The second turns out to work out better, once things like
accessibility frameworks and theming apis are in place. Perhaps in the
future MS Windows will just provide a drawing method and a theming api.