G
Gregory Ewing
Ethan said:
That's correct. The current version of PyGUI includes
a pywin32-based implementation.
That's correct. The current version of PyGUI includes
a pywin32-based implementation.
M
Martin v. Loewis
Is the Tkinter GUI also the basic way that Python handles a graphics
No. Python, in itself, does not "handle" graphics displays at all. For
any output to the graphics display, it uses some kind of library,
whether it's console output, or a GUI application. One specific GUI
library is Tkinter. A standard "print" command (which eventually also
outputs to the graphics display) instead uses the terminal emulation of
the operating system.
Regards,
Martin
No. Python, in itself, does not "handle" graphics displays at all. For
any output to the graphics display, it uses some kind of library,
whether it's console output, or a GUI application. One specific GUI
library is Tkinter. A standard "print" command (which eventually also
outputs to the graphics display) instead uses the terminal emulation of
the operating system.
Regards,
Martin
M
Martin v. Loewis
That said, PerlTk didn't use Tcl did it?
If you are referring to http://search.cpan.org/~srezic/Tk-804.028/ -
this also has a full Tcl interpreter, in pTk/mTk, and uses Tcl_Interp
and Tcl_Obj throughout. From the Perl/Tk FAQ (*):
"However, from a Perl perspective, Perl/Tk does not require any
familiarity with Tcl, nor does its installation depend on any Tcl code
apart from that packaged within Perl/Tk."
They also explain
"The pTk code proper is an externally callable Tk toolkit (i.e. a
re-write of the Tk 8.0 code that allows easier external linking &
calling, especially by perl)."
I couldn't quite understand what they mean by that: the sources for
tcl/generic (for example) look fairly unmodified.
Regards,
Martin
(*) http://www.lns.cornell.edu/~pvhp/ptk/ptkFAQ.htm
If you are referring to http://search.cpan.org/~srezic/Tk-804.028/ -
this also has a full Tcl interpreter, in pTk/mTk, and uses Tcl_Interp
and Tcl_Obj throughout. From the Perl/Tk FAQ (*):
"However, from a Perl perspective, Perl/Tk does not require any
familiarity with Tcl, nor does its installation depend on any Tcl code
apart from that packaged within Perl/Tk."
They also explain
"The pTk code proper is an externally callable Tk toolkit (i.e. a
re-write of the Tk 8.0 code that allows easier external linking &
calling, especially by perl)."
I couldn't quite understand what they mean by that: the sources for
tcl/generic (for example) look fairly unmodified.
Regards,
Martin
(*) http://www.lns.cornell.edu/~pvhp/ptk/ptkFAQ.htm
G
Gregory Ewing
Brian said:
That's more or less what PyGUI is meant to be, except that the
frameworks currently wrapped are Cocoa, Gtk and pywin32. There's
also a slight difference in emphasis, since PyGUI aims to leverage
platform functionality as much as possible, rather than rely on
a large third-party library that duplicates much of that functionality.
Hmmm... you probably *could* do that with PyGUI if you wanted, but
it would require delving under the covers and dealing with some
stuff that's a bit on the hairy side and wasn't meant to be seen
by ordinary mortals. Also the resulting app would no longer be
cross-platform, and might be tied to details of a particular
version of PyGUI. Possibly some hooks could be added to the API
to make this sort of thing cleaner, though.
G
Gregory Ewing
Brian said:
Just had a quick look at that. In the third example code box:
def Body(self):
^^^^
self.textbox = TextBox(self, multiline=1, wrap=0)
self.AddComponent(self.textbox)
^^^^^^^^^^^^
Here's something unpythonic already: a couple of non-pep-8-compliant
method names.
And a bit further down:
self.textbox.SetFont(FIXED_FONT)
^^^^^^^
Using a setter method instead of a property.
So while it's quite likely better than raw wxPython, it fails the
pythonicity test for me.
G
Gregory Ewing
Martin said:
Is there? I wasn't aware of that. What's the reason?
If it's because ctypes doesn't work on all platforms, then
I don't think that applies in this case, because the only
platform where it would be needed is Windows, where ctypes
does work.
Pywin32 does seem to have grown rather haphazardly. Some
functionality is wrapped in two different ways in different
modules, for no apparently good reason, and some other
things are wrapped incompletely or not at all. A well
thought out replacement suitable for stdlib inclusion
wouldn't go amiss.
B
Brian Blais
I hope I didn't imply that it was perfect.
It's definitely much easier than raw wx, and I think it is a reasonable starting point.
Some of the things that you pointed out are very easily fixed, and
are there because of some wx quirks. AddComponent could easily be
renamed to append, for the same meaning. Many other wx getters/
setters are done with properties or attributes, so it is in the right
direction.
I've tried PyGUI about 6 months ago, and it seemed like a good start,
but missing a lot of what I would need. I also am not very fluent in
MVC (having developed all my bad GUI habits from years of matlab
programming), so the structure wasn't particularly intuitive. I just
tried it again a few days ago, and couldn't get it running on my
system, which is a bit old (OS X Tiger).
Since many seem to be married to a particular GUI framework, I was
just suggesting that a thin wrapper around the framework might be
fruitful, with wax as a working proof-of-concept. That way, when
there is a limitation, one can fall back on the underlying framework
easily. Wrapping an already cross-platform framework would seem to
get the most bang for the buck.
bb
P
python
R
rantingrick
Yes, i'll agree the syntax it not what we would want for Python.
Although it could be re-written in a Pythonic fashion but then again
scaling to the real Wx library would not be as "clean". However wax
does have one very likable quality -- it "is" a small part of a well
established GUI and very large library. But again, not what any of
"us" would consider to be Pythonic "enough".
R
rantingrick
You summed up in a most elegant way what i was unable to do earlier.
But i want to add more...
I think PyWin32, like Tkinter, was another gift we have failed to
maintain on our end. The great Mark Hammond brought us the much need
functionality of PyWin32 and even today it has not be seized upon and
made better by the Python community? Do we expect Mark to just keep
maintaining and supporting what REALLY should be a stdlib module
forever?
Like it not (And i'm talking directly to all the Unix hackers here!)
Win32 is here to stay! You should have realized that years ago! And
likewise, like it or not, GUI is here to stay. You should have also
realized that years ago (although we may be supporting web interfaces
soon...same thing really). If you wish to hide your head in the sand
and ignore these facts hoping that the "old days" of command line and
no windows platform will return, well thats not going to happen. The
rest of us are going to move forward and hope that eventually you will
see the light and tag along.
Tkinter and TclTk are dead! I use Tkinter and i can happily say that.
And the ONLY reason i even use Tkinter is the fact that it's there in
the stdlib! Remove the module and i will move on to something better.
Tkinter is legacy software built on legacy software. It was the best
choice way back when Guido forged the path. But now Tkinter has fallen
into obscurity. Sure it's useful, i use it all the time. But it's too
large, too slow, and just too damn ugly to be part of "our" Python
stdlib. Embedded interpretor, YUCK! If people want to use Tkinter they
can download it as a 3rd party module, no harm done! But Tkinter is
harming Python by disgracing Python's stdlib and slowing Python down.
PyGUI is still the front runner and has my vote until someone can show
me a better option. I think if PyGUI where around circa 1995 Guido
would have pounced on it like a hungry tiger on a wildebeest. Ask
yourself what a Python GUI should look like, and what it should feel
like. Then go and use PyGUI. The choice will be obvious.
M
Martin v. Loewis
or PyGui would need to be implemented in terms of ctypes (which then
ctypes is inherently unsafe. It must be possible to remove it
from a Python installation, and still have the standard library work.
Regards,
Martin
ctypes is inherently unsafe. It must be possible to remove it
from a Python installation, and still have the standard library work.
Regards,
Martin
E
Emile van Sebille
On 6/10/2010 9:34 AM rantingrick said...
Frankly, I'm dropping clients that insist on windows only and am
actively migrating clients to ubuntu/openoffice/firefox/thunderbird/etc.
After 15 years, I don't see that MS has gotten it right yet and I'm
tired of fixing stupid windows boxes. Talk about time sinks!
Emile
Frankly, I'm dropping clients that insist on windows only and am
actively migrating clients to ubuntu/openoffice/firefox/thunderbird/etc.
After 15 years, I don't see that MS has gotten it right yet and I'm
tired of fixing stupid windows boxes. Talk about time sinks!
Emile
S
Stephen Hansen
You're bordering very near "silly" now. Drop the rhetoric, it doesn't
actually help your case, argument, or position in the least. No one
thinks GUI's are going away. No one thinks win32 is going away.
Everytime you make a statement like this, you just sound daft.
Its not a question of those things going away. Its a question of what
exactly belongs in the standard library and what doesn't. Everything in
the world that is modern, current, or not "going away" does not need to
be in the standard library.
Why not include pywin32? Well the first question is: does Mark Hammond
even *want* it included? He has to offer it before the question can even
be considered, and assign copyright to the PSF. And after that
willingness is determined: its huge, and despite all of my *windows*
programming-- its what I get *paid* for in my day job-- I never needed
it except once.
So... uh, why again are we including it? Those people who need it, have
ready access.
Why not include wxPython and a very-easy-wrapper around it? Because
wxPython is also *huge* -- and also directly tied to the development and
release cycle of a third-party product (wxWidgets) which is *huge* in
and of itself-- you're now asking python-dev to effectively support
hundreds of thousands of lines of more code-- and a lot of it in a
language (C++) they may not be experts at (Python is C)! Not to mention
the only 'very-easy-wrapper' needs work, and there's no clear indication
anyone's willing to do the work
Why not include PyQT? Licensing makes it impossible.
Why not include PyGUI? Currently, its dependencies make it unsuitable,
but there's a question as to if its mature enough yet or not. I dunno,
I've never used it: it is *useless* to me. No offense to Greg meant.
Again: it has nothing at all to do with people not liking GUI's or
thinking GUI's are going the way of the dodo. It has to do with people's
ideas of what should or should not go in the standard library. Generally
speaking? Stuff that everyone or most people can make ready use of...
and while yes, doing GUI development is very, very common -- "GUI
development" is not a single monolithic thing. Different people have
some *very* different needs for what they get out of their GUI development.
For example: if you want to embed a CSS-capable web-browser into your
app? PyQT is actually your best option-- albeit a commercial one if
you're not open source.. wx/Python haven't yet finished WebKit
integration(*).
If you need some flexible or configuration-based user interfaces,
wxPython actually is a very solid solution, with its XML-based GUI
creation.
Neither of these things are very rare or even too terribly advanced.
The reason we do not embed any 'better' GUI then Tkinter into the
stdlib? There's several tools available for the job: and there is no
clear indication or agreement that one is better or more qualified for
inclusion over the others. At least, IMHO. I do not speak for python-dev.
It is fortunate that my Python is not ruled by the judgements of what
you think belongs in your Python.
There is clearly no "our" Python.
Not just rhetoric, but silly rhetoric.
PyGUI is indeed a solid project, and perhaps-- eventually-- a contender
for replacing Tkinter, once it works the kinks out and matures. Maybe it
is almost mature enough now? Maybe it needs more help? If so-- your time
would be better spent downloading it, using it, and offering some
patches, improving it -- then being silly and sounding like a religious nut.
Things don't go into the stdlib to mature.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMETV4AAoJEKcbwptVWx/lQZ0H/3J7fnaV4I4/G6e8mnevG8xI
HNrkdPrK9qw+ge715NjAbiJHCWGM6p2CFkhHBA+iO0QPn8fa8ENQGTQ7hBOBz9vh
k1RV6B7MYSMizVpCAKfmE/f7XmJDdpQ05KglngB3WtHEw8p2gGl9i2pgiWP9ghnq
YMhN/1NBR2QpshcolX5fDdxJQs1jh5hSavA1pMP2BVEqVVR5uExEmg1V2+V/c40i
hyKVAkUFp4j2KbuL7dgJlJH28yUddWuahua/5qaMrmtS6nda0F3aLxuAD2cN0/Ze
nsgNg+PqR3UZYjD2rr04wXLUNAoaWh1YfMMrkhYaMkiZR8ADfuL59WfcJRnaJzk=
=ddjU
-----END PGP SIGNATURE-----
B
Benjamin Kaplan
It probably doesn't have as much staying power as you think. The only
reason that having PyWin32 is a big deal and having PyObj-C, PyGTK, or
PyQT is not is because the operating systems that use the other 3 come
with Python pre-installed. If Microsoft ever decides to pre-install
Python on Windows, it's going to be IronPython, where PyWin32 becomes
a non-issue (unless you really really hate yourself).
R
rantingrick
And i 100% agree Emille. Just for the record i hate windows, I hate
win32 programming, i hate MS office, and I hate VB. I could rant for
hours about how Windows sucks but for the sake of this thread I will
stop it at that. Unfortunately the mindless masses use Windows
extensively so we are forced to support it...
"""It's not going away just because we put our heads in the sand""""
.... that was my point about win32.
E
Evan Plaice
<rant>This is my first foray into usenet and f*** the signal to crap
ratio in here is ridiculous. I can't believe that there are 150+
answers and little or no useful information yet</rant>
I was wondering the same thing since the subject of cross platform GUI
dev makes me cringe. I was wondering if there was a cross-platform
language-agnostic XML-based declarative language. Basically, what HTML/
CSS is to web browsers for the desktop.
Microsoft's WPF and more specifically XAML format accomplish the cross-
platform cross-language part but the technology is owned by Microsoft.
Here are my findings:
<a herf="http://stackoverflow.com/questions/2962874/what-are-the-open-
source-alternatives-to-wpf">
GTK+ & Glade
Glade is the actual XML format. It can be used on any platform or
language as long as GTK+ running on that system is adapted to it.
wxWidgets & XRC
XRC is the format. Libraries that use it vary on the language (ex.
wx.NET for C#, VB, and Managed C++).
If you want a desktop GUI that is cross-platform, language-agnostic,
and open source. Use and contribute to these projects.
ratio in here is ridiculous. I can't believe that there are 150+
answers and little or no useful information yet</rant>
I was wondering the same thing since the subject of cross platform GUI
dev makes me cringe. I was wondering if there was a cross-platform
language-agnostic XML-based declarative language. Basically, what HTML/
CSS is to web browsers for the desktop.
Microsoft's WPF and more specifically XAML format accomplish the cross-
platform cross-language part but the technology is owned by Microsoft.
Here are my findings:
<a herf="http://stackoverflow.com/questions/2962874/what-are-the-open-
source-alternatives-to-wpf">
GTK+ & Glade
Glade is the actual XML format. It can be used on any platform or
language as long as GTK+ running on that system is adapted to it.
wxWidgets & XRC
XRC is the format. Libraries that use it vary on the language (ex.
wx.NET for C#, VB, and Managed C++).
If you want a desktop GUI that is cross-platform, language-agnostic,
and open source. Use and contribute to these projects.
R
rantingrick
But what if Mark decided one day he no longer wants to support Python
or Win32? How many years will it be before someone writes another?
Both are not-starters for many reasons already discussed in this
thread. Maybe wax would have a chance if we made it more Pythonic as
Greg pointed out. All others are a non-starter due to the zen (import
this).
And again the opponents miss the whole point. It's not about including
a GUI that would make everyone happy. Its about including a GUI that
is complimentary to Python's stated goals. Not for you, Not for me,
Not for the x&lee... remember? ;-)
So i guess then the question becomes... Why keep supporting it? It's
time to say Bye-Bye to Tkinter.
i beg to differ my friend.
I am in the process of that right now!
Agreed! And likewise "things" should not be left to clutter the stdlib
needlessly only to wither and die a slow death just because no one has
the vision (or the motivation) to fix them or remove them for the sake
of Python's evolution.
S
Stephen Hansen
That's because the question wasn't really a question. Its a political
rallying cry to try to get us all to Do Something we don't really want
to do.
That said:
I'm only familiar with wxWidgets, and I have used XRC though not
terribly extensively. Its useful in certain contexts, but at least the
toolchains are a bit more 'dialog-focused' then 'design entire apps'.
Its still usable though. I usually design all my UI's by hand, just
because at this point, I use too many custom components and can do it
without thinking. But for certain 'custom' forms that I do make heavy
use of XRC.
Another thing you can look at is QT/PyQT. If you're doing GPL'd
software, that might be a very good solution for you-- you can design
your whole app in the beautiful QTDesigner, and the .ui files can be
used in any language with a QT binding, PyQT included. But you gotta be
GPL'd to use Python. (Although QT is now LGPL, the PyQT bindings
continue the GPL/commercial split... and PySide isn't cross platform yet)
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEUHJAAoJEKcbwptVWx/lB04IAJfaKehcuTHL78KeKMPQhuXP
h56CtDyUV6lYmt5dYB68U8TSHLj1kggbZGnjyk06Lc77IS2Xn6w5HpLQOD5h/Wvo
0iZZa86J7pxmWteC3eiOM6gf6r8docQasmydjO9X0AY6uaOTP6bmMvA9TbBwXe06
20vLBuL9bv8rucHPFTjZyIduaJhZ0V0aB1z8wgivvI5TlTufTRoIuqw96rOZSRXj
ETcldVtHB6rS7RRpkv2Grxess37DIElQBdX+KLZY1rUgZytg0w+mraRsu48/Y+kz
UjGnsJsckiug1QXNJtkp5WLvAPkbnHGJ6t1+otR1Gv2I/fklxs21y/bybWVp/eg=
=e1Zm
-----END PGP SIGNATURE-----
S
Stephen Hansen
Very few, I suspect.
There's very little you can do with pywin32 that you can't do with
ctypes. PyWin32 served a pretty important role once upon a time when you
might need to do certain low level win32 api's. These days, I just use
ctypes.
The primary purpose I use pywin32 for is documentation or to see how
someone solved a problem *using* pywin32: I then rewrite it in ctypes.
But, should some mythical occasion come and Mark decides not to support
either anymore-- we'll be in the exact same position now as to then.
Someone'll need to step up and maintain it.
Something being in the stdlib doesn't mean its maintained: in fact,
that's a very dangerous part about inclusion. There's a number of
modules already in the stdlib which don't have anyone responsible for
them, and its really, really hard to get bugfixes into them unless
someone is very interested or its a serious bug.
I like how you left out all my talk of dependencies. That's very
important when you're talking about stdlib inclusion: wax depends on
wxPython. Thus, non-includable, as wxPython is non-includable and so
something dependent upon it is as well.
You make a statement about GUI's not going away, and how all of us GUI
haters need to get on board-- then leave that statement out-- and say I
miss the whole point when I say its got nothing to do with that. Okay, well.
You want to include a GUI that's not for, well, anyone. But
ideologically sound. Okay, well.
Tkinter is complimentary to Python's stated goals. The method by which
that compliment happens (with TCL in the middle) is a bit strange, and
the syntax leaves something to be desired-- but its really not that bad,
and there's other modules in the stdlib more unpythonic.
Its easy to use, reasonably powerful, and if you use the new themed
widgets (which isn't terribly hard to do), not even too ugly.
Because there is no clearly superior alternative available. Didn't I
just say that? I swear I did.
Until there is, Tkinter is "good enough".
Tkinter is maintained, works, and is updated continually to make
available the latest things that become available in Tk.
And actually: things do go to the stdlib to die. Its actually a very apt
description of exactly how things work. Once a module gets added to the
stdlib, its sort of dead. Static. It might change, in this
excruciatingly slow pace, with strict rules for compatibility over
consistency. It takes years and years before you can fix a design error
-- you have to wait until the next major release to put a new option in,
do some deprecation (be it pending or regular, it depends), and then a
whole new major release before you can finally be fixed.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEcBAEBAgAGBQJMEUXpAAoJEKcbwptVWx/lLzAIAKQnFAAqfZFgPjghUUzTXNSc
9zW+nJFmbWKXDhpVf48Uzk7FmYt0J39jSryw23G3BPcK1jOWfFmpUsSVPfhIzLbn
tlJ08kBiMtWN2otLI9/D3VSwscp9cHWtE0eCswio1M9P+5MfKwb8t4PhZdu24+YL
iHkAXTrvw55/H2Q/5mFpOfjYdiVmHCn5FlVCbK95yLqEbsC/Tzf80s95on5WoUkS
vcpHvMflVDa6U3vDL7XFCL9bWL3YNDa0pom4IHRlpe9sSgDyvsoHsXbpZDZ+G1Ne
xnKgxSexpqkh4tGsmYkXOm4NUVstj/tgimydD/qN8cBO9+CAdzluxX3FeDiJLBU=
=4yGr
-----END PGP SIGNATURE-----
S
Stephen Hansen
Er, yes. I meant Python's PyQT bindings, without a commercial license. Oops!
Python's all <3 about any sort of use anyone wants to use it for.
--
Stephen Hansen
... me+list/python (AT) ixokai (DOT) io
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iQEbBAEBAgAGBQJMEUboAAoJEKcbwptVWx/l4KUH+My5XGyLl/CXHLK86bQo8jGj
ouknwReiJZfuTmD5PRhGTlGeR9stSUPca2r3/rF7s5rDJ9cmFhbTxQB8vDEcawzM
B+I0xFxARSnPl2B5SgnPcj1NgHRAlyJ3o+/anfeuDP34oDRxAJNPG1nxJof1LwbN
MthaZz04zErY57t0FctAaYDxaTK5c5H8XTxy08N+OmS0xk+f9pB+f3O8MS4vx7An
ywzgGpHHNXNOx/zmqik2M8fYWHVARPoDy5eFxfxAH3ZaqE0uJuqKEe/mJtFOb0a5
WUlojBi+QH2fm1A/SeJ/qC4murZi71aOOjaq2Z7jrZsddZttJ6j+tsdjxPynjQ==
=2AiH
-----END PGP SIGNATURE-----