Future Python Gui?


B

bcwhite

I've been trying to find out what the future of Python is with regard
to Tk. It seems there are several interfaces that make use of new
functionality, including "Tile" and "Ttk".

If I want to write a program that will run under the standard Python
distribution of the future, what extension module should I work with
today?

Thanks!

-- Brian
 
Ad

Advertisements

K

kirkjobsluder

I've been trying to find out what the future of Python is with regard
to Tk. It seems there are several interfaces that make use of new
functionality, including "Tile" and "Ttk".

If I want to write a program that will run under the standard Python
distribution of the future, what extension module should I work with
today?

I've been doing a lot of reading this month.

At the moment, none of the toolkits available strike me as being in a
position to become the next tkinter, and it seems like core python
development is moving away from extensions that might be
better produced by other parties. Everyone and their cousin
have different ideas about how a GUI should be built including
how it hooks into other services. Cross-platform, it seems like
wxPython has a considerable edge over jython+SWT or Swing.
But platform-specific frameworks are also pretty important.

I'd say that the best bet is to learn swig and similar
bridging, expanding, and embedding mechanisms.
Python GUI programming is likely to involve either
python hooking into frameworks like Cocoa, Qt, or
wxWidgets, python embedded in frameworks
like Java or .NET, or flavors of python used
as domain-specific languages in applications such as
emacs, vim, and OpenOffice.org.
 
R

Richard Jones

kirkjobsluder said:
I'd say that the best bet is to learn swig and similar
bridging, expanding, and embedding mechanisms.

For GUI programming this would seem overkill. Pick a GUI toolkit and it's
almost guaranteed to be wrapped for use in Python already.


Richard
 
K

kirkjobsluder

For GUI programming this would seem overkill. Pick a GUI toolkit and it's
almost guaranteed to be wrapped for use in Python already.

Perhaps a bit. I'm not saying that everyone should wrap their own
code,
but many of the currently existing wrappers are quite thin, and
understanding
how to use and debug wrapped GUI code might put one in a better
position
over knowing a particular toolkit.
 
K

Kevin Walzer

I've been trying to find out what the future of Python is with regard
to Tk. It seems there are several interfaces that make use of new
functionality, including "Tile" and "Ttk".

If I want to write a program that will run under the standard Python
distribution of the future, what extension module should I work with
today?

Thanks!

-- Brian

Tile is available right now in Tk as an extension package, and a Tkinter
wrapper for it can be found here:

http://tkinter.unpythonic.net/wiki/TileWrapper

Tile will be integrated into Tk's core when 8.5 is released. It's
supposed to enter beta testing Real Soon Now. However, I imagine that
Python/Tkinter will depend on Tk 8.4 for the foreseeable
future--certainly 8.5 won't be supported officially before a full,
stable release is made. Perhaps in Python 2.6?
 
B

bcwhite

I'd say that the best bet is to learn swig and similar
bridging, expanding, and embedding mechanisms.
Python GUI programming is likely to involve either
python hooking into frameworks like Cocoa, Qt, or
wxWidgets, python embedded in frameworks
like Java or .NET, or flavors of python used
as domain-specific languages in applications such as
emacs, vim, and OpenOffice.org.

If this were just a tool for me, it wouldn't matter. My concern is
distribution. If anybody who wants to run my software then they also
have to go through all the trouble to install these extensions, none
of which seem to have decent instructions. I'm an old-time hack and I
have trouble getting them to work. A simple user won't have a chance!

If Python doesn't declare an official Gui system, then it'll be
fragmented, inconsistent, and unsupportable.

I wouldn't mind using just Tkinter, despite it's primative look,
except that it doesn't support more advanced widgets like "notebook".

-- Brian
 
Ad

Advertisements

K

Kevin Walzer

If this were just a tool for me, it wouldn't matter. My concern is
distribution. If anybody who wants to run my software then they also
have to go through all the trouble to install these extensions, none
of which seem to have decent instructions. I'm an old-time hack and I
have trouble getting them to work. A simple user won't have a chance!

This is what deployment tools such as py2app or py2exe are for--to wrap
all the bits up into a simple package that the end user just installs,
without worrying about dependencies.
 
H

hlubenow

If this were just a tool for me, it wouldn't matter. My concern is
distribution. If anybody who wants to run my software then they also
have to go through all the trouble to install these extensions, none
of which seem to have decent instructions. I'm an old-time hack and I
have trouble getting them to work. A simple user won't have a chance!

If Python doesn't declare an official Gui system, then it'll be
fragmented, inconsistent, and unsupportable.

I guess that's why Tkinter, despite its primitive look, has made its way
into the Python-distribution and I think, for the same reason it will stay
there, until it can be replaced by something similar consistent.

H.
 
B

bcwhite

Tile is available right now in Tk as an extension package, and a Tkinter

That site seems to be down (500 Internal Server Error).

Tile will be integrated into Tk's core when 8.5 is released. It's
supposed to enter beta testing Real Soon Now. However, I imagine that
Python/Tkinter will depend on Tk 8.4 for the foreseeable
future--certainly 8.5 won't be supported officially before a full,
stable release is made. Perhaps in Python 2.6?

That is okay with me. It'll be a long time before I get to a point
where I'll need easy release. But knowing that it will be part of a
future release will also mean I don't have to worry about refactoring
everything if the toolkit I'm using goes out of style and is replaced
by something else.

Out of curiosity... Did that page have install instructions for
Tile? Other pages I've seen talk about it but don't say how to
integrate it in to a python installation (under Windows or Linux).

-- Brian
 
J

Jarek Zgoda

(e-mail address removed) napisa³(a):
If this were just a tool for me, it wouldn't matter. My concern is
distribution. If anybody who wants to run my software then they also
have to go through all the trouble to install these extensions, none
of which seem to have decent instructions. I'm an old-time hack and I
have trouble getting them to work. A simple user won't have a chance!

I am not a hacker, just a software developer, but I'd have no problems
in either installing PyGTK on Ubuntu box (sudo apt-get install
python-gtk2, but it's installed by default anyway) or on Windows XP
machine (double click on installer icon). "Simple user" is not an idiot
either and if she can read English, she wouldn't have hard time too.

The rumours on "problems installing GUI toolkits" are greatly exagerated
IMO.
 
K

Kevin Walzer

That site seems to be down (500 Internal Server Error).



That is okay with me. It'll be a long time before I get to a point
where I'll need easy release. But knowing that it will be part of a
future release will also mean I don't have to worry about refactoring
everything if the toolkit I'm using goes out of style and is replaced
by something else.

Out of curiosity... Did that page have install instructions for
Tile? Other pages I've seen talk about it but don't say how to
integrate it in to a python installation (under Windows or Linux).

-- Brian

On Windows, the easiest way to install Tile is to grab it from
ActiveState's Tcl distribution
(http://www.activestate.com/products/activetcl/) and then place it with
the Tcl/Tk bits that come with Python. The Tcl/Tk build for Windows that
python.org provides doesn't ship with Tile. You'll also have to install
the Tile wrapper at the site I referenced earlier in your site-packages
directory.
 
Ad

Advertisements

S

Stef Mientki

The rumours on "problems installing GUI toolkits" are greatly exagerated

Not at all !!
As an experienced computer user,
I yesterday installed a well known Python package on a clean winXP machine,
and it costed me be about 1.5 .. 2 hours !!
There are always unexpected situations,
I think software developers call them "new features" ;-)

cheers,
Stef Mientki
 
C

Cameron Laird

.
.
.
I wouldn't mind using just Tkinter, despite it's primative look,
except that it doesn't support more advanced widgets like "notebook".
.
.
.
"Tile" has already been mentioned in this thread, and I know
there'll be at least one more follow-up on the subject. Tile
includes a ("native"!) notebook, as well as a combobox, tree-
view, ... <URL: http://wiki.tcl.tk/11075 >.

I recognize that Tile might not be widely installed until 2.6
or so.
 
K

kirkjobsluder

If this were just a tool for me, it wouldn't matter. My concern is
distribution. If anybody who wants to run my software then they also
have to go through all the trouble to install these extensions, none
of which seem to have decent instructions. I'm an old-time hack and I
have trouble getting them to work. A simple user won't have a chance!

Deployment has improved a lot in recent years, PyObjC is a simple
double-click on a package. Most windows libraries work the same way.
On the FOSS Unix world, you would add to a package system which will
install dependencies automatically. When I used a FOSS Unix, I really
only got burned when I decided to live on the bleeding edge. And as
someone else pointed out, package tools should take much of the work
out of delivery.

Meanwhile, things could work the other way around. If Apple extends
their support to PyObjC for example, python developers would know that
every new OS X system would be able to run their PyObjC.
If Python doesn't declare an official Gui system, then it'll be
fragmented, inconsistent, and unsupportable.

I don't see that as the case because many other languages don't have
an "official" GUI system including C, C++, Ruby, lisp, Basic and
perl. All of these have their active areas of deployment. For that
matter, Java has three "official" GUI systems with most development on
the server side.

And didn't comp.long.python have this same argument in regards to
MySQL support which was dropped from php? In addition to license
issues, the php core library just wasn't used, and lagged behind the
MySQL library.

My personal opinion is that GUI development is such a moving target
that toolkits are a poor choice for inclusion into the core standard
libraries. There does not appear to be a standards process involved,
and toolkits are expanding or changing parts of their API every few
years. Anything that could be added, is going to be obsolete by the
time it is incorporated into the standard. My feeling is that python
is better served by encouraging GUI developers to include python-
friendly bindings.
I wouldn't mind using just Tkinter, despite it's primative look,
except that it doesn't support more advanced widgets like "notebook".

I wouldn't mind seeing tkgrid and tkhtml added to the standard
library. But Tk is probably "good enough" for most simple
interfaces.
 
K

Kevin Walzer

When Tile becomes part of the core Tk library, it should be accessible
from Tkinter as well. Tile has a nice notebook widget. See
http://tktable.sourceforge.net/tile/screenshots/windowsxp.html,
http://tktable.sourceforge.net/tile/screenshots/macosx.html and
http://tktable.sourceforge.net/tile/screenshots/unix.html.
I wouldn't mind seeing tkgrid and tkhtml added to the standard
library. But Tk is probably "good enough" for most simple
interfaces.

I'm not sure what tkgrid is: isn't that the standard Tk "grid"
algorithm? If so, it's already accessible from Tkinter.

As for Tkhtml, it's undergoing *heavy* development: it's moving from a
lightweight, basic HTML renderer into a full-featured browser widget
with CSS support: see http://tkhtml.tcl.tk/ and
http://tkhtml.tcl.tk/hv3.html and http://tkhtml.tcl.tk/screenshot1.gif.
The drawbacks are that it's currently at an alpha stage, and while the
hv3 browser based on Tkhtml 3 is very impressive, it's overkill for the
simple display of HTML--and the API for constructing a simpler widget
seems to be very complex. As well, because it's still alpha, no one has
wrapped it for Tkinter as of yet.
 
P

Paul Boddie

If Python doesn't declare an official Gui system, then it'll be
fragmented, inconsistent, and unsupportable.

I don't agree. GUI frameworks are somewhat like Web frameworks, object-
relational mappers, and all the other things that work in different
ways, work better on various systems, appeal to different tastes and
so on. There are a number of cross-platform GUI frameworks which claim
some kind of native look and feel on every platform, but declaring one
the winner is not going to convince the satisfied users of the others
of its superiority. Meanwhile, some people don't care about more than
one platform and will quite happily target their chosen platform
intentionally, and it's worth remembering that anyone developing for,
say, a Free desktop environment will treat such an environment as the
means to provide "worthwhile" portability - targeting the Windows API,
for example, becomes an irrelevance.

There are a few technologies with an "official" GUI framework or APIs,
with Java being one of the more notorious at delivering either a
fairly weak set of features performing inconsistently across platforms
(AWT) or a more ambitious set of features wrapped up in a baroque
architecture, performing poorly and still managing to look alien on
most platforms (Swing). And before anyone mentions Delphi/Kylix, a
recent experience trying out a Kylix-based application on a Red Hat
system provided enough of an explanation as to why Borland dropped
that particular product.

As I've said often enough on the topic of Web frameworks, picking
winners gives only a temporary victory to those who want to avoid
making decisions. It's better to provide people with a means of making
an informed choice, and it should be realised that people will
approach this choice from rather different angles. It isn't always
going to be, "I want to write a Python application - what GUI should I
use?" Instead, it may be, "I want to write a KDE application - can I
do so in Python and what are my options?" Pretending that the answer
is always the same will frequently drive people to other technologies,
not attract them to a technology selling a vision that turns out to be
a mirage.

Paul
 
Ad

Advertisements

B

bcwhite

On Windows, the easiest way to install Tile is to grab it from
ActiveState's Tcl distribution
(http://www.activestate.com/products/activetcl/) and then place it with
the Tcl/Tk bits that come with Python. The Tcl/Tk build for Windows that
python.org provides doesn't ship with Tile. You'll also have to install
the Tile wrapper at the site I referenced earlier in your site-packages
directory.

For posterity's sake, here's what I did...

- install python http://www.python.org/download/
(use the Windows MSI install package)
- go to http://bruno.thoorens.free.fr/ and do the download
- instructions say to copy "tty.py" to "Tkinter" folder, but that
doesn't exist
- copy instead to C:\Python25\Lib
- copy folders as directed (to C:\Python25\Tcl)

This should also work with the ActivePython download at
http://www.activestate.com/products/activepython/ .

Within your program, you need:

# Import "Tile" theming engine
tkroot.tk.call('package', 'require', 'tile')
tkroot.tk.call('namespace', 'import', '-force', 'ttk::*')
tkroot.tk.call('tile::setTheme', 'xpnative')

after your call to "tkroot = Tk()" (or "tkroot = Tkinter.Tk()" if you
just "import Tkinter").

The frustrating part is that the main reason I wanted this is because
it says it wraps a "Notebook" widget. If it does, I can't find it!
<sigh>

-- Brian
 
B

bcwhite

"Tile" has already been mentioned in this thread, and I know
there'll be at least one more follow-up on the subject. Tile
includes a ("native"!) notebook, as well as a combobox, tree-
view, ... <URL:http://wiki.tcl.tk/11075>.

It seems that Tile does include a "notebook" widget but it's pure Tcl
code and so isn't available via the Python wrapper.

-- Brian
 
B

bcwhite

As I've said often enough on the topic of Web frameworks, picking
winners gives only a temporary victory to those who want to avoid
making decisions. It's better to provide people with a means of making
an informed choice, and it should be realised that people will
approach this choice from rather different angles. It isn't always
going to be, "I want to write a Python application - what GUI should I
use?" Instead, it may be, "I want to write a KDE application - can I
do so in Python and what are my options?" Pretending that the answer
is always the same will frequently drive people to other technologies,
not attract them to a technology selling a vision that turns out to be
a mirage.

This is getting off-topic, I guess, so I'll only comment once because
I don't want to get wrapped up in a flame war. This is the argument
used by people who think that having both KDE and GNOME is a good
thing because it promotes competition, etc. Personally, I believe
it's a bad thing because it duplicates effort and delivers an
inconsistent look & feel. Developers are forced to choose a
framework, not knowing if it will go away in favor of another choice
and rendering their own hard work obsolete. I don't want my work
dependent upon the framework. I'd rather have less good if it meant
longer-term stability and greater consistency.

But that's just me.

-- Brian
 
Ad

Advertisements

K

Kevin Walzer

It seems that Tile does include a "notebook" widget but it's pure Tcl
code and so isn't available via the Python wrapper.

-- Brian
That's not correct. When the Tkinter wiki is back up, see the page I
referred to.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top