homepage

When trying to load third-party themes ttk.Style.theme_names() fails to list available themes. For example if the themes from the tile-themes project are installed one can do:
>>> from tkinter import *
>>> from tkinter import ttk
>>> root=Tk()
>>> s=ttk.Style()
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('classic', 'default', 'clam', 'alt')
>>> root.tk.call('package', 'require', 'tile-themes')
'0.6'
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('keramik', 'plastik', 'clam', 'winxpblue', 'alt', 'Aquativo', 'classic', 'default', 'keramik_alt')
>>> 
This has been discussed in more detail at tkinter-discuss:
http://code.activestate.com/lists/python-tkinter-discuss/3373/
As ttk::themes is described as being part of the Public API inside ttk.tcl and is also documented in the tcl wiki at http://wiki.tcl.tk/14796 resp. http://wiki.tcl.tk/23676 it appears safe to add it to ttk.py.
Considering this I prepared a patch (against b10a9d4f08eb) that adds the following method to ttk.Style():
 def themes(self, pattern=None):
 '''Returns a list of theme names available. It can be passed an
 argument which is used as an lsearch glob pattern while looking
 for the theme names.'''
 return self.tk.splitlist(self.tk.call('ttk::themes', pattern))

Can you provide some tests for the new method?

I am not familiar with python's test unit, but I tried my best.
As far as I see there are three possibilities to invoke the function:
* without pattern -> return tuple with all themes
* with pattern that matches one or more themes
* with pattern that matches no themes -> return empty tuple
So I tried to add a method to test_style.StyleTest() :
 def test_themes(self):
 installed_themes = self.style.themes()
 some_themes = self.style.themes('*e*')
 no_themes = self.style.themes('foobarbaz')
 self.assertTrue(isinstance(installed_themes, tuple))
 self.assertTrue(isinstance(some_themes, tuple))
 self.assertTrue(isinstance(no_themes, tuple))
Oddly enough this fails on my own system (debian squeeze, tk-8.5.8, python-3.1.3 / -2.6.6):
$ python3 test_style.py
test_configure (__main__.StyleTest) ... ok
test_layout (__main__.StyleTest) ... ok
test_lookup (__main__.StyleTest) ... ok
test_map (__main__.StyleTest) ... ok
test_theme_use (__main__.StyleTest) ... ok
test_themes (__main__.StyleTest) ... ERROR
======================================================================
ERROR: test_themes (__main__.StyleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "test_style.py", line 97, in test_themes
 no_themes = self.style.themes('foobarbaz')
 File "/usr/lib/python3.1/tkinter/ttk.py", line 536, in themes
 return self.tk.splitlist(self.tk.call('ttk::themes', pattern))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly
----------------------------------------------------------------------
Ran 6 tests in 0.086s
FAILED (errors=1)
Traceback (most recent call last):
 File "test_style.py", line 108, in <module>
 run_unittest(*tests_gui)
 File "/usr/lib/python3.1/test/support.py", line 955, in run_unittest
 _run_suite(suite)
 File "/usr/lib/python3.1/test/support.py", line 938, in _run_suite
 raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
 File "test_style.py", line 97, in test_themes
 no_themes = self.style.themes('foobarbaz')
 File "/usr/lib/python3.1/tkinter/ttk.py", line 536, in themes
 return self.tk.splitlist(self.tk.call('ttk::themes', pattern))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly
The same error occurs with python-2.6.6 (same tk). Apparently this is because:
$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from tkinter import *
>>> from tkinter import ttk
>>> r=Tk()
>>> s=ttk.Style()
>>> x = s.themes('foo')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python3.1/tkinter/ttk.py", line 536, in themes
 return self.tk.splitlist(self.tk.call('ttk::themes', pattern))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly
>>> x=r.tk.call('ttk::themes', 'foo')
>>> x
<StateSpec object at 0x9b1b6c8>
>>> str(x)
''
>>> 
Called from wish the same call returns an empty string as expected:
$ wish
% ttk::themes
classic default clam alt
% ttk::themes *e*
default
% ttk::themes foobarbaz
%
In python2.6, when setting Tkinter.wantobjects to 0, themes('foo') returns an empty tuple as expected.
So I guess this is due to a bug in debian's python/tkinter install. Can anyone confirm this?

Update: I just tried Python-3.3.0 on WinXP, the same error, so it is obviously _not_ a bug specific to the debian python install.

This looks similar to issue16809 and requires a similar solution.

Yes, I happen to encounter these TclObjects occasionally, e.g. (not tested with the latest python):
$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from tkinter import *
>>> from tkinter import ttk
>>> r=Tk()
>>> p=ttk.Progressbar(r)
>>> p.cget('mode')
<index object at 0x879d338>
>>> print(p.cget('mode'))
determinate
>>> p.cget('mode') == 'determinate'
False
>>> str(p.cget('mode')) == 'determinate'
True
>>> 
In Python2 the easiest way to work around this imho is to set wantobjects to 0, however this does not seem to work in Python3 anymore, not sure if this is for some reason intentional or deserves another bug report:
$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter.wantobjects = 0
>>> from tkinter import ttk
>>> r=tkinter.Tk()
>>> p=ttk.Progressbar(r)
>>> p.cget('mode')
''
>>>
To be honest, since these TclObjects never seem to work reliably I had preferred it a lot if they would have been turned off by default.

Since splitlist() works with Tcl_Obj-s, proposed test should pass.
klappnase, could you please sign a Contributor Licensing Agreement?
http://www.python.org/psf/contrib/contrib-form/
What is your real name? What should I add in the Misc/ACKS file?

> What is your real name?
Michael Lange
> What should I add in the Misc/ACKS file?
Hmm, personally I'd prefer the nick, but it seems to be common practice to use the real name; I think I'll leave it to you ;)

Now CPython trunk in feature freeze stage until 3.4 realease. So we should wait several months before commit this patch.

As a non-tcl/tk user except via tkinter, I am not convinced that we should add a near-duplicate function. The *Python* doc for ttk.Style.theme_names says "Returns a list of all known themes." If it does not do that, which it seems not to, it should be changed (whether the change is called a fix or enhancement).
From the referenced Epler post, the situation seems more complicated on the ttk side in that ttk has two similar functions: 'style theme_names', which only reports 'loaded' names, and 'themes' which reports 'loaded and available', though 'available' seems vague and dependent on strange package calls. For Python, a parameter for one function would suffice to restrict or augment the list returned, if indeed the option is needed.
Are 'unloaded but available' themes really available to use? Does Style.theme_use(available_name) work? If so, it seems to me that available_name should be reported by theme_names. If not, what is the use of knowing it?
Most any patch will need a doc patch.

> Are 'unloaded but available' themes really available to use?
Yes.
> Does Style.theme_use(available_name) work?
Yes.
> If so, it seems to me that available_name should
> be reported by theme_names.
I agree, one should think so. I am not 100% certain about that, but to me it seems that on the tcl side ttk:themes is newer and thus preferable to theme names which maybe is only still there for backwards compatibility.
Since as a Tkinter user I like Tkinter methods to behave like their Tcl/Tk counterparts (which, if nothing else, helps a lot in reading and understanding tcl code/documentation (and possibly "translating" tcl code into Python)) I had rather kept theme_names() intact to avoid confusion. Maybe there could simply a line like "Deprecated since Python-xy, use themes() instead." be added to theme_names' doc string ?

Mark, do you have any opinion of this? It apparently impinges on what themes we use or can offer as an option.

I believe the ttk::themes call is older, part of when it was still Tile. There are a bunch of those kind of API's that were kept around (for compatibility I presume) when the official API (style theme names) was created and documented.
As explained on the original mailing list thread, the difference has to do with Tcl's lazy loading of packages (i.e. it knows what package to load when you need a particular command, but will not necessarily load it until the command is used)
 http://code.activestate.com/lists/python-tkinter-discuss/3371/
To summarize, even now you can install themes and use them, they just won't appear in the list until they're used.
Because calls like ttk::themes are *not* part of the official, documented API, I would strongly suggest not adding a separate API in tkinter; instead, stay with Style.theme_names
I would suggest that the default behaviour of theme_names be changed to call ttk::themes (falling back on theme use if it generates an error). I would also suggest adding a tkinter-only optional keyword parameter to this call (e.g. loaded, defaulting to False; if True is would call 'ttk::style theme names'). Then document that loaded=True is not guaranteed to be only loaded ones in future, because I wouldn't be surprised if Tk changes this at some point.