Re: Future Python Gui?
Jarek Zgoda wrote: > 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. It might not be a big deal for your own computer, but if you are distributing software professionally to a bunch of customers, things get more complex. Let's say your customers use RHEL4 for instance. If you would like to use a recent PyGTK, this means that the GTK libs in RHEL4 aren't new enough. Upgrading GTK will force you to upgrade a bunch of other libraries as well. That means that the system will no longer be the vanilla RHEL4 with your additions. Bugs might pop up in other applications on the system than yours, because they assumed other versions of shared objects. You can (perhaps) install the newer versions of the libs in non-standard locations and set LD_LIBRARY_PATH to that location for your program, but that means that things brake fairly easy, and if you for instance have a larger system, where Python scripts relying on this new PyGTK are started from a Python interpreter embedded in some big application, this big application will also see the newer versions of all those shared objects that PyGKT pulled in. Unless you are very careful, other programs that you start up from within your application (maybe it's possible to spawn a new shell from your app with the embedded Python interpreter and start arbitrary applications from there) will also get the non-standard shared objects. If you just install the shared objects the new PyGTK rely on in the standard locations, you have probably removed security patches and bug fixes added to the software by Red Hat from the system. Any application might cease to work, and the customer might have problem getting support from Red Hat on the system. You might end up with a lot more support and maintenance work than intended, or get very unhappy customers. Now imagine that you have half a dozen other platforms besides RHEL4 on x86_64 that you need to support... This is a problem you need to deal with if you develop software for Unix. It's not impossible to solve all these problems, but there is certainly a cost in this. If you handle it well, there is a cost in testing and adapting the systems. If you don't handle it well, there might be a big cost in handling emergencies and dealing with unhappy customers or users. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] wrote: > What is the benefit of calling similar widgets for both modules within > the same code? Why wouldn't I call everything via Tile? (i.e. "from > Tile import *" and not import Tkinter at all) Because Tile depends on Tkinter, and also, not everything from Tkinter is in Tile (text widget, menus, etc). -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> It shouldn't change at all. I use Frame for Tkinter frames and > Tile.Frame for Tile frames, since a lot of the widgets have the same > names. Here's a sample: > > from Tkinter import * > import Tile Thanks for all the info. I'm a little confused about using both Tkinter and Tile at the same time. Do the calls to Tkinter now get themed? What is the benefit of calling similar widgets for both modules within the same code? Why wouldn't I call everything via Tile? (i.e. "from Tile import *" and not import Tkinter at all) Thanks! -- Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] wrote:
> However, that file is completely useless without instructions on how
> to use it, and there are no instructions within the page or file.
>
> That is:
> - exactly where does it get installed
In your Python site-packages directory.
> - what else needs to get installed (eg. some dll)
The Tile package. Install ActiveTcl from http://www.activestate.com,
find the Tile package, and copy it to Python's installation of Tcl/Tk
(find the libs directory--I'm not on a Windows box ATM and don't
remember exactly).
> - where do you find these other things
http://www.activestate.com
> - where does that something else get installed
See above.
> - how do you import this module
import Tile
> - how does use of Tkinter change (if at all) once imported
>
It shouldn't change at all. I use Frame for Tkinter frames and
Tile.Frame for Tile frames, since a lot of the widgets have the same
names. Here's a sample:
from Tkinter import *
import Tile
root = Tk()
root.tk.call('package', 'require', 'tile')
def printme():
print "You clicked me"
frame = Tile.Frame(root)
frame.pack(fill=BOTH, expand=TRUE)
button = Tile.Button(frame, text="Print", command=printme)
button.pack()
root.mainloop()
HTH,
Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> The wrapper I maintain works differently, and includes the notebook widget. I've seen the page. You can get to it via Google's cache; just put the url in the box and the one search result returned usually has a "cached" link. However, that file is completely useless without instructions on how to use it, and there are no instructions within the page or file. That is: - exactly where does it get installed - what else needs to get installed (eg. some dll) - where do you find these other things - where does that something else get installed - how do you import this module - how does use of Tkinter change (if at all) once imported I know all this stuff is obvious to those that have been working with it for a while, but for those of us just getting started with Python, it's immensely frustrating that we're assumed to know all these steps. -- Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
This should be saved as "Tile.py." Sorry.
###
November 2006: Posted by Kevin Walzer, [EMAIL PROTECTED] Based on
Tile wrapper by Martin Franklin. This version updates the wrapper to
reflect changes in Tile commands, and adds support for Tile-based frames
(ttk::frame). Freely reusable.
import Tkinter
from Tkconstants import *
class Style:
def default(self, style, **kw):
"""Sets the default value of the specified option(s) in style"""
pass
def map_style(self, **kw):
"""Sets dynamic values of the specified option(s) in style. See
"STATE MAPS", below."""
pass
def layout(self, style, layoutSpec):
"""Define the widget layout for style style. See "LAYOUTS" below
for the format of layoutSpec. If layoutSpec is omitted, return the
layout specification for style style. """
pass
def element_create(self, name, type, *args):
"""Creates a new element in the current theme of type type. The
only built-in element type is image (see image(n)), although
themes may define other element types (see
Ttk_RegisterElementFactory).
"""
pass
def element_names(self):
"""Returns a list of all elements defined in the current theme. """
pass
def theme_create(self, name, parent=None, basedon=None):
"""Creates a new theme. It is an error if themeName already
exists.
If -parent is specified, the new theme will inherit styles,
elements,
and layouts from the parent theme basedon. If -settings is
present,
script is evaluated in the context of the new theme as per
style theme
settings.
"""
pass
def theme_settings(self, name, script):
"""Temporarily sets the current theme to themeName, evaluate
script,
then restore the previous theme. Typically script simply
defines styles
and elements, though arbitrary Tcl code may appear.
"""
pass
def theme_names(self):
"""Returns a list of the available themes. """
return self.tk.call("style", "theme", "names")
def theme_use(self, theme):
"""Sets the current theme to themeName, and refreshes all
widgets."""
return self.tk.call("style", "theme", "use", theme)
class Widget(Tkinter.Widget, Style):
def __init__(self, master, widgetName=None, cnf={}, kw={}, extra=()):
if not widgetName:
## why you would ever want to create a Tile Widget is
behond me!
widgetName="ttk::widget"
Tkinter.Widget.__init__(self, master, widgetName, cnf, kw)
def instate(self, spec=None, script=None):
"""Test the widget's state. If script is not specified, returns 1
if the widget state matches statespec and 0 otherwise. If script
is specified, equivalent to if {[pathName instate stateSpec]}
script.
"""
return self.tk.call(self._w, "instate", spec, script)
def state(self, spec=None):
"""Modify or inquire widget state. If stateSpec is present, sets
the widget state: for each flag in stateSpec, sets the
corresponding
flag or clears it if prefixed by an exclamation point. Returns
a new
state spec indicating which flags were changed: ''set changes
[pathName state spec] ; pathName state $changes'' will restore
pathName to the original state. If stateSpec is not specified,
returns a list of the currently-enabled state flags.
"""
return self.tk.call(self._w, "state", spec)
class Button(Widget, Tkinter.Button):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::button", cnf, kw)
###add frame support here--KWs
class Frame(Widget, Tkinter.Frame):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::frame", cnf, kw)
class Checkbutton(Widget, Tkinter.Checkbutton):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::checkbutton", cnf, kw)
class Combobox(Widget, Tkinter.Entry):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::combobox", cnf, kw)
def current(self, index=None):
"""If index is supplied, sets the combobox value to the element
at position newIndex in the list of -values. Otherwise, returns
the index of the current value in the list of -values or -1 if
the current value does not appear in the list.
"""
return self.tk.call(self._w, "current", index)
class Entry(Widget, Tkinter.Entry):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::entry", cnf, kw)
def validate(self):
"""Force revalidation, independent of the conditions specified by
the -validate option. Returns 0 if t
Re: Future Python Gui?
Since the Tkinter wiki is still down, here is the Tile wrapper I maintain:
###
November 2006: Posted by Kevin Walzer, [EMAIL PROTECTED] Based on
Tile wrapper by Martin Franklin. This version updates the wrapper to
reflect changes in Tile commands, and adds support for Tile-based frames
(ttk::frame). Freely reusable.
import Tkinter
from Tkconstants import *
class Style:
def default(self, style, **kw):
"""Sets the default value of the specified option(s) in style"""
pass
def map_style(self, **kw):
"""Sets dynamic values of the specified option(s) in style. See
"STATE MAPS", below."""
pass
def layout(self, style, layoutSpec):
"""Define the widget layout for style style. See "LAYOUTS" below
for the format of layoutSpec. If layoutSpec is omitted, return the
layout specification for style style. """
pass
def element_create(self, name, type, *args):
"""Creates a new element in the current theme of type type. The
only built-in element type is image (see image(n)), although
themes may define other element types (see
Ttk_RegisterElementFactory).
"""
pass
def element_names(self):
"""Returns a list of all elements defined in the current theme. """
pass
def theme_create(self, name, parent=None, basedon=None):
"""Creates a new theme. It is an error if themeName already
exists.
If -parent is specified, the new theme will inherit styles,
elements,
and layouts from the parent theme basedon. If -settings is
present,
script is evaluated in the context of the new theme as per
style theme
settings.
"""
pass
def theme_settings(self, name, script):
"""Temporarily sets the current theme to themeName, evaluate
script,
then restore the previous theme. Typically script simply
defines styles
and elements, though arbitrary Tcl code may appear.
"""
pass
def theme_names(self):
"""Returns a list of the available themes. """
return self.tk.call("style", "theme", "names")
def theme_use(self, theme):
"""Sets the current theme to themeName, and refreshes all
widgets."""
return self.tk.call("style", "theme", "use", theme)
class Widget(Tkinter.Widget, Style):
def __init__(self, master, widgetName=None, cnf={}, kw={}, extra=()):
if not widgetName:
## why you would ever want to create a Tile Widget is
behond me!
widgetName="ttk::widget"
Tkinter.Widget.__init__(self, master, widgetName, cnf, kw)
def instate(self, spec=None, script=None):
"""Test the widget's state. If script is not specified, returns 1
if the widget state matches statespec and 0 otherwise. If script
is specified, equivalent to if {[pathName instate stateSpec]}
script.
"""
return self.tk.call(self._w, "instate", spec, script)
def state(self, spec=None):
"""Modify or inquire widget state. If stateSpec is present, sets
the widget state: for each flag in stateSpec, sets the
corresponding
flag or clears it if prefixed by an exclamation point. Returns
a new
state spec indicating which flags were changed: ''set changes
[pathName state spec] ; pathName state $changes'' will restore
pathName to the original state. If stateSpec is not specified,
returns a list of the currently-enabled state flags.
"""
return self.tk.call(self._w, "state", spec)
class Button(Widget, Tkinter.Button):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::button", cnf, kw)
###add frame support here--KWs
class Frame(Widget, Tkinter.Frame):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::frame", cnf, kw)
class Checkbutton(Widget, Tkinter.Checkbutton):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::checkbutton", cnf, kw)
class Combobox(Widget, Tkinter.Entry):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::combobox", cnf, kw)
def current(self, index=None):
"""If index is supplied, sets the combobox value to the element
at position newIndex in the list of -values. Otherwise, returns
the index of the current value in the list of -values or -1 if
the current value does not appear in the list.
"""
return self.tk.call(self._w, "current", index)
class Entry(Widget, Tkinter.Entry):
def __init__(self, master=None, cnf={}, **kw):
Widget.__init__(self, master, "ttk::entry", cnf, kw)
def validate(self):
"""Force revalidation, independent of the conditions specified by
the
Re: Future Python Gui?
[EMAIL PROTECTED] wrote:
>> 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!
>
>
> -- Brian
>
The wrapper I maintain works differently, and includes the notebook widget.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] 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, ... 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> "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, ... 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> 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!
-- Brian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
.
.
.
>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, ... http://wiki.tcl.tk/11075 >.
I recognize that Tile might not be widely installed until 2.6
or so.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
>> 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/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. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
On Apr 18, 11:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > 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.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. > > -- Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] 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. -- Jarek Zgoda http://jpa.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] wrote: > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] wrote: >> 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! > 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. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
[EMAIL PROTECTED] wrote: > 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? -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
On Apr 18, 2:07 am, Richard Jones <[EMAIL PROTECTED]> wrote: > kirkjobsluder wrote: > > 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. 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. > > Richard -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
kirkjobsluder wrote: > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Future Python Gui?
On Apr 17, 9:28 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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. > Thanks! > > -- Brian -- http://mail.python.org/mailman/listinfo/python-list
Future Python Gui?
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 -- http://mail.python.org/mailman/listinfo/python-list
