Future Python Gui?

[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

[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

[Kevin Walzer]

bc*****@pobox.c om wrote:

>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

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

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.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[kirkjobsluder]

On Apr 18, 11:24 am, "bcwh...@pobox. com" <bcwh...@pobox. comwrote:

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!

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.pytho n 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.

>
-- Brian

[Kevin Walzer]

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

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/...windowsxp.html,
http://tktable.sourceforge.net/tile/...ts/macosx.html and
http://tktable.sourceforge.net/tile/...hots/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.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Cameron Laird]

In article <11************ **********@e65g 2000hsc.googleg roups.com>,
bc*****@pobox.c om <bc*****@pobox. comwrote:

[Paul Boddie]

bc*****@pobox.c om wrote:

>
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

[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

[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

[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

[Kevin Walzer]

bc*****@pobox.c om wrote:

>"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

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

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com