How to choose the right GUI toolkit ?

[Eric Brunel]

Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP.

It seems to depend on the widget type, and on what you call native... For
example, tk menus are definitely the native ones; tk scrollbars are the
native ones, but with the Win2k look (no XP look available yet); tk
buttons do not seem to be the native ones, as they don't act like "normal"
Windows buttons.

But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop.

You seem to imply that GTK is "native" on Linux. It isn't, as can be seen
with the echoes of the "holy war" between Gnome and KDE that we often see
around here. As an aside, I personnally work on Linux and don't even use
any of these environments (both are too much Windows-like to my taste...).

Is there a way to get it to do so?

Not yet. But tcl/tk 8.5 will include the Tile extension including new
themable widgets. See here:
http://tktable.sourceforge.net/tile/screenshots/unix.html

There is also a Tile/QT extension that allows the Tile widgets to use the
QT library. See here:
http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=24&Itemid=40

AFAIK, nothing equivalent for GTK yet.

HTH

 

[Jeremy Sanders]

My apologies! I'm glad to be corrected on this. There are Cygwin
packages for Qt as well, but I have heard about enough bugs to think I
should avoid Qt. I have used enough Gtk apps that run flawlessly under
Windows to have my hopes that it works well.

You normally use PyQt/Qt on Windows without Cygwin. There are very few bugs
and lots of professional companies base their products on Qt Windows.

 

[Neil Cerutti]

Or line continuation in REXX... Where you get such oddities as:

call xyz(a, b, c, ,
d, e, f)

That is NOT a NULL argument between c and d... The first comma
is the argument separator, the second comma is the
to-be-continued marker

Eyiyi! That's yugly.

The colon's main purpose seems to be to allow one-liners:

Easy to parse: if a < b: a += 1
Hard to parse if a < b a += 1

 

[skip]

Neil> The colon's main purpose seems to be to allow one-liners:

Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1

No, as the note from Tim Peters referenced by Robert Kern pointed out
earlier in this thread, the ABC language designers found that
indentation-based block structure by itself wasn't enough to clue new users
in about the code structure. Adding the colon at the end of the
if/while/for clause helped.

Skip

 

[Neil Cerutti]

What about

if color == red or blue or green:
return 'primary'

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that. The disadvantage is that the
usual binary logical operators must exist and are spelled
differently. (It uses C's '||' and '&&'.)

if (color == red or blue or green && color.type == additive) {
return 'primary';
}

It also supports a switch statement syntax and semantics that
would fit nicely with Python.

switch (action) {
Eat:
print "Gulp! Delicious, but poisonous.";
deadflag = 1;
Taste:
print "You nibble at one of the corners. Yum!";
Attack:
print "What did that mushroom ever to to you?";
default:
print "You can't do that to a mushroom.";
}

There's no fall-through, and there's no syntax to enable it,
either.

In Python it would hypothetically be:

switch action:
Eat:
print "Gulp! Delicious, but poisonous."
deadflag = True
Taste:
print "You nibble at one of the corners. Yum!"
Attack:
print "What did the mushroom ever to to you?"
default:
print "You can't do that to a mushroom."

I've often wanted a "Pythonic" Inform to Inform translator, so I
can leave out all the unecessary (), {} and ;.

* Inform 6 is a language for implementing text adventures, not
to be confused with the unrelated language Inform 7.

 

[skip]

Neil> The colon's main purpose seems to be to allow one-liners:

Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1

Skip> ... the ABC language designers found that indentation-based block
Skip> structure by itself wasn't enough to clue new users in about the
Skip> code structure. Adding the colon at the end of the if/while/for
Skip> clause helped.

One final note. Just because the colon isn't technically required in many
situations doesn't mean it's superfluous. If all language designers cared
about was ease of parsing we'd probably all be programming in assembler,
sendmail, brainfuck. Or, as the Zen of Python says: "Readability counts".

Skip

P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

S

 

[Nick Craig-Wood]

( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

If you install the QT theme for GTK it all starts to look a lot nicer

Eg debian

ii gtk2-engines-gtk-qt 0.7-1 theme engine using Qt for GTK+ 2.x

You get a control panel for GTK apps in the KDE control center also.

 

[Neil Cerutti]

Neil> The colon's main purpose seems to be to allow one-liners:

Neil> Easy to parse: if a < b: a += 1
Neil> Hard to parse if a < b a += 1

No, as the note from Tim Peters referenced by Robert Kern
pointed out earlier in this thread, the ABC language designers
found that indentation-based block structure by itself wasn't
enough to clue new users in about the code structure. Adding
the colon at the end of the if/while/for clause helped.

Thanks. I worded that lousily.

 

[Dan Lenski]

It seems to depend on the widget type, and on what you call native... For
example, tk menus are definitely the native ones; tk scrollbars are the
native ones, but with the Win2k look (no XP look available yet); tk
buttons do not seem to be the native ones, as they don't act like "normal"
Windows buttons.

So, basically, Tk is actually embedding the native Win2k menus, but it
isn't actually embedding the native Win2k scrollbars... it's just
emulating their look and feel?

You seem to imply that GTK is "native" on Linux. It isn't, as can be seen
with the echoes of the "holy war" between Gnome and KDE that we often see
around here. As an aside, I personnally work on Linux and don't even use
any of these environments (both are too much Windows-like to my taste...).

I didn't imply that GTK widgets are "native" on Linux. I implied that
GTK widgets native under Gnome ;-) I was basing my assumption on an
earlier poster who said that Tk 8.x can use native widgets on all
supported platforms... so I assumed that under Gnome it should use GTK
widgets.

Not yet. But tcl/tk 8.5 will include the Tile extension including new
themable widgets. See here:
http://tktable.sourceforge.net/tile/screenshots/unix.html

Good to know! I'm looking forward to 8.5.

Dan

 

[vdicarlo]

I highly recommend wxPython. It's very mature, full-featured, and

portable, and fairly easy to learn as well.

I am also a Python beginner thinking about what GUI toolkit to use, and
the availability of a free video screencast series on installing and
using wxpython at showmedo.com is making me want to go that way. I
viewed their introduction to Python resources and wished I had found it
first.

The wxpython series is at http://tinyurl.com/yggean

Vincent

 

[Bjoern Schliessmann]

On 2006-11-09, Bjoern Schliessmann

The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that.

Python also supports it.

The disadvantage is that the usual binary logical operators must
exist and are spelled differently. (It uses C's '||' and '&&'.)

Do they have to be spelled differently? In Python, they don't have
to.

Regards,


Björn

 

[Robert Kern]

P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

You did it just now!

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Tony Nelson]

What about

if color == red or blue or green:
return 'primary'

What about

if color in [red, blue, green]:
return 'primary'
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

 

[Michael Hobbs]

Please don't hide your new thread as a reply to an existing, unrelated
message. Start a new message if your message isn't actually a reply.

My apologies. My email client was apparently hiding some important
headers from me.

Why have two different syntaxes for the same statement?

Why am I allowed separate statements with semi-colons in addition to
newlines? Why have triple-quoted long strings in addition to
single-quoted short strings? Why do I have to type backslash to continue
a line, except when I'm currently inside parens, brackets, or braces?

The answer is that it's a matter of convenience for the most common
case, with some exceptions allowed for the exceptional cases.

A use case. What problem is being solved by introducing this
inconsistency?

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

As far as using the FAQ as gospel, the FAQ also provides arguments for
why there isn't a with statement or a switch statement. The with
statement has already been implemented in 2.5 and there's a PEP to
implement switch (3103).

- Mike

 

[Neil Cerutti]

Python also supports it.


Do they have to be spelled differently? In Python, they don't
have to.

That kind of answers your question. ;-)

That is cool. I was unaware of the feature; until just now I
thought Inform was had innovated the syntax!

 

[Neil Cerutti]

You did it just now!

I hate Godwin's Law Nazis.

;-)

 

[Marc 'BlackJack' Rintsch]

Python also supports it.

No it doesn't -- look again at the example given above. It's legal syntax
in Python but doesn't have the semantics implied by the example.

Ciao,
Marc 'BlackJack' Rintsch

 

[skip]

Robert> You did it just now!

Hence the smiley. ;-)

S

 

[Steve Holden]

Ben Finney wrote: [...]

A use case. What problem is being solved by introducing this
inconsistency?

The same problem that is solved by not having to type parens around the
'if' conditional, a la C and its derivatives. That is, it's unnecessary
typing to no good advantage, IMHO. I was coding in Ruby for several
months and got very comfortable with just typing the if conditional and
hitting return, without any extra syntax. When I came back to Python, I
found that I felt annoyed every time I typed the colon, since it
obviously isn't required. The FAQ says that the colon increases
readability, but I'm skeptical. The indentation seems to provide more
than enough of a visual clue as to where the if conditional ends.

So you'd also like us to shorten the names of the builtins and the the
keywords? Why bother with "def" when we could just use "d", "class" when
we could just use "c"? Or *does* readability matter to some degree?

As far as using the FAQ as gospel, the FAQ also provides arguments for
why there isn't a with statement or a switch statement. The with
statement has already been implemented in 2.5 and there's a PEP to
implement switch (3103).

But the "with" statement isn't the one that "with" was reserved for in
the FAQ, which is really talking about the same kind of "with" statement
that Visual Basic uses: an implied left operand for unary "." operations.

regards
Steve

 

[Steve Holden]

What about

if color == red or blue or green:
return 'primary'



Really, I think it'd be more mess to let the if statement's end only
depend on ":". I think there could arise situations that are messy
to debug. If I need multiple lines I prefer the parentheses.

I still prefer

if color in (red, blue, green):
...

regards
Steve