Re: ttk Scale: missing attributes
On Jun 23, 7:26 pm, Alan G Isaac alan.is...@gmail.com wrote: Tkinter's Scale widget had a `label` and a `resolution` attribute. These appear to be missing from the Ttk Scale widget. Is there a reason? These were important attributes. Thanks, Alan Isaac As you might know, the new ttk widgets are not intenteded to be drop- in replacements for older tk widgets, so some of them do not have the same options indeed. For your particular problem, the options were probably dropped because they are not absolutely needed: you can do by yourself what the 'resolution' option did automatically, and you can just add a label widget near the scale if you want to. Just a guess… - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: tkInter Listbox question
On Jun 21, 6:36 pm, rantingrick rantingr...@gmail.com wrote:
On Jun 21, 12:36 am, Anthony Papillion papill...@gmail.com wrote:
So I'm trying to add a Listbox to my window. I want it to be the width
of my window and the height of my window. I'm using the following
code ('root' is my toplevel window):
gsItems = Listbox(root, width=root.winfo_width(),
height=root.winfo_height())
gsItems.pack()
While you would think this code would set the height and width of
gsItems to the height and width of root, it doesn't. Instead it puts a
little tiny listbox in the middle of the form.
eb303 answered your question perfectly however he failed to point you
toward the proper documentation. The Python docs you need are here...
http://effbot.org/tkinterbook/
FYI Remember Guys, this is a Python mailing list. Always give
reference FIRST to docs that are Python specific. *Then* if you want
to show off your multi lingual-ness by all means post extra links. /
FYI
Thanks for the condescendent tone in your post. And FYI, remember that
this is not Microsoft Support here: people are helping freely and
because they want to, so they might not have the time to look for
documentation they just don't have at hand, because they never use it.
If you want to provide pointers to better stuff, you're welcome. Your
unpleasant remarks are not.
Go on like this and you'll just discourage everyone to give some of
their time to help people.
--
http://mail.python.org/mailman/listinfo/python-list
Re: tkInter Listbox question
On Jun 21, 7:36 am, Anthony Papillion papill...@gmail.com wrote:
So I'm trying to add a Listbox to my window. I want it to be the width
of my window and the height of my window. I'm using the following
code ('root' is my toplevel window):
gsItems = Listbox(root, width=root.winfo_width(),
height=root.winfo_height())
gsItems.pack()
While you would think this code would set the height and width of
gsItems to the height and width of root, it doesn't. Instead it puts a
little tiny listbox in the middle of the form.
I've been Googling for almost an hour. Can anyone help me figure this
out? Point me in the right direction?
Thanks!
Anthony
The problem you have in your script is probably simple: at the time
when you put the listbox in it, the windows still contains nothing, or
very little. And what you're doing is to take its _current_ size and
assign it to the listbox. So the listbox will be very small, since at
the time you ask for its dimensions, the window itself is very small.
Basically, you're taking the wrong approach there: you should put the
listbox in the window telling it to adapt its size to its parent
container, and then resize the window if you want to.
The first step is done via the geometry manager, which can be pack or
grid. Please refer to your documentation to know how to use them to
make a widget adapt its size to its container. The documentation I use
myself is the plain tcl/tk documentation, that you can find at
http://www.tcl.tk/man/tcl8.5/contents.htm. The documentation for pack
is at http://www.tcl.tk/man/tcl8.5/TkCmd/pack.htm and the one for grid
at http://www.tcl.tk/man/tcl8.5/TkCmd/grid.htm. Please note this
documentation might not be suitable for you, as it is not a Python/
Tkinter documentation.
The second step can be done with the method called geometry on your
window. The size you want should then be specified as a string
'widthxheight'.
Here is an example, using the pack geometry manager:
from Tkinter import *
root = Tk()
gsItems = Listbox(root)
gsItems.pack(fill=BOTH, expand=TRUE)
root.geometry('400x300')
root.mainloop()
HTH
- Eric -
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter Toplevel sizing issue (using a grid)
On Jun 12, 1:40 am, random joe pywi...@gmail.com wrote: Hello all, Hi this i my first post here. I would like to create a tkinter toplevel window with a custom resize action based on a grid. From the Tk docs it say you can do this but for the life of me i cannot figure out how? In my app i wish for the main window to only resize in 20 pixel jumps (if you will). I have tried using the toplevel.grid() and setgrid option and no luck! ## here is the tk doc page about setGridhttp://www.tcl.tk/man/tcl/TkLib/SetGrid.htm ## here is the Tkinter method from wm class def wm_grid(self, baseWidth=None, baseHeight=None, widthInc=None, heightInc=None): Instruct the window manager that this widget shall only be resized on grid boundaries. WIDTHINC and HEIGHTINC are the width and height of a grid unit in pixels. BASEWIDTH and BASEHEIGHT are the number of grid units requested in Tk_GeometryRequest. return self._getints(self.tk.call( 'wm', 'grid', self._w, baseWidth, baseHeight, widthInc, heightInc)) grid = wm_grid ## Here is my code. from Tkinter import * class TopWin(Tk): def __init__(self): Tk.__init__(self)#, setgrid=1) #self.maxsize(width=50, height=50) #self.minsize(width=1, height=1) self.grid(10, 10, 20, 20) topwin = TopWin() topwin.mainloop() Please help. I am going nuts trying to make this work for three hours already :( Works for me on Linux with WindowMaker, but not on the Mac. What is your platform, and your window manager if applicable? Seems tk just passes the options to the window manager, so if the wm decides to ignore them, you're stuck, I'd say. By the way, you should use more drastic values for your tests. I tried with self.grid(10, 10, 20, 20) and I hardly saw that it worked. Using self.grid(0, 0, 100, 100) made it obvious. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI programs
On May 30, 5:21 pm, Alf P. Steinbach al...@start.no wrote: PS: Tkinter on its own does not provide image resizing and does not on its own support common image formats like JPEG or PNG (it does support GIF). Native PNG support in tcl/tk and hence Tkinter is planned for the next release (8.6), which is in beta stage, so should be official soon. -- http://mail.python.org/mailman/listinfo/python-list
Re: tkinter function outout to text widget
On May 29, 10:51 pm, Johan Lans johan.l...@apspektakel.com wrote:
Hi
I'm totally new on python and I'm doing an assignement where I'm doing
a class that manipulates a text. The program is also supposed to have
a GUI, for which I have used tkinter.
So far I have entry widgets for file names and buttons, its all
working like I want it to.
What is missing is a way to output the changes to the text. I was
thinking that a text-widget would be suitable. Is there a reasonably
easy way to do this?
I tried inserting a string to the textwidget and letting the class
method change this string, but the inserted string isn't updated in
the text-widget.
Would be very happy for any hints.
You won't be able to do exactly what you want with the text widget.
There is a possibility to have to auto-updating in the GUI indeed, but
it can only be made via other widgets than the text.
Here is an example of what you can do:
from Tkinter import *
root = Tk()
var = StringVar()
var.set('aaa')
lbl = Label(root, textvariable=var)
lbl.pack(side=LEFT)
def next():
var.set(''.join(chr(ord(c) + 1) for c in var.get()))
Button(root, text='Next', command=next).pack()
root.mainloop()
As you can see, I'm using a Label here. This should be enough if the
text you want to display is read-only. The Label will also adapt its
size if there are several lines in your text. The biggest limitation
is probably that you can't make it scrollable (not easily, at least…).
HTH
- Eric -
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter library reference
On May 29, 3:11 pm, Pradeep B pradeepb...@gmail.com wrote: Do we have a standard reference library for Tkinter available? -- Pradeep Short answer: no, at least not a complete one for Tkinter itself. However, there is a complete reference for tcl/tk here: http://www.tcl.tk/man/tcl8.5/ Once you're used to converting tcl/tk's commands and options into Tkinter classes and methods, it is the best one around. If you really need Python/Tkinter syntax, there are some good documents here: http://www.tkdocs.com/widgets/index.html http://effbot.org/tkinterbook/ But these are not complete or rather old. However, you can use them as a starting point before diving into the tcl/tk reference above. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Minor annoyances with properties
On May 27, 3:24 pm, Christian Heimes li...@cheimes.de wrote: Do I miss something? Is this the way to do it, or is there a better one? A better way was introduced in Python 2.6. Seehttp://docs.python.org/library/functions.html?highlight=property#prop... I have a Python only version around if you are still using Python 2.5. Christian Mmmm, I might still miss something. OK, I can replace my initial property using @property and @p.setter, but it doesn't seem to work in subclasses: class A(object): @property def p(self): return self._p @p.setter def _set_p(self, p): self._p = p class B(A): @p.setter def _set_p(self, p): … results in: Traceback (most recent call last): File toto.py, line 8, in module class B(A): File toto.py, line 9, in B @p.setter NameError: name 'p' is not defined -- http://mail.python.org/mailman/listinfo/python-list
Re: Minor annoyances with properties
On May 27, 8:56 pm, Francesco Bochicchio bieff...@gmail.com wrote: On 27 Mag, 14:37, eb303 eric.brunel.pragma...@gmail.com wrote: Hello all, I've been using Python properties quite a lot lately and I've found a few things that are a bit annoying about them in some cases. I wondered if I missed something or if anybody else has this kind of problems too, and if there are better solutions than the ones I'm using ATM. The first annoyance is when I want to specialize a property in a subclass. This happens quite often actually, and it is even sometimes the reason why a plain attribute is turned into a property: a subclass needs to do more things than the superclass when the property is updated for example. So, of course, my first try was: class A(object): def __init__(self): self._p = None def _get_p(self): return self._p def _set_p(self, p): self._p = p p = property(_get_p, _set_p) class B(A): def _set_p(self, p): ## Additional things here… super(B, self)._set_p(p) And of course, it doesn't work: the property has been bound to A._set_p in A, so any new definition of _set_p in any subclass does not replace the set method for the property. So I always have to add a line: p = property(A._get_p, _set_p) in the subclass too. This is a bit awkward to me, since I have to specify the superclass's name (super(…) can't be used, since it should take B as an argument, and B isn't defined yet…). Do I miss something? Is this the way to do it, or is there a better one? Don't know if is better, but you could add a level of indirection to solve it class A(object): def __init__(self): self._p = None def _get_p(self): return self._p def _set_p(self, p): self._p = p def _virtual_get_p (self): _get_p(self) def _virtual_set_p (self,v): _set_p(self, v) p = property(_virtual_get_p, _virtual_set_p) At this point, the subclasses of A can reimplement _get_p and _set_p as they like (I think) Ciao - FB Well, I've thought about that too and it should work, but that makes 2 function calls instead of one for every property access… I'd really like to avoid that. By the way, I think your 'virtual' methods should be written as: def _virtual_get_p (self): return self._get_p() def _virtual_set_p (self,v): self._set_p(v) Thanks anyway. - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Minor annoyances with properties
On May 27, 3:14 pm, Neil Cerutti ne...@norwich.edu wrote: On 2010-05-27, eb303 eric.brunel.pragma...@gmail.com wrote: I've been using Python properties quite a lot lately and I've found a few things that are a bit annoying about them in some cases. I wondered if I missed something or if anybody else has this kind of problems too, and if there are better solutions than the ones I'm using ATM. The first annoyance is when I want to specialize a property in a subclass. See: URI:http://infinitesque.net/articles/2005/enhancing%20Python%27s%20proper... -- Neil Cerutti *** You found a dead moose-rat. You sell the hide for $200. *** Thanks for the suggestion, but it looks a bit heavy… Performing the name lookup on the specialized object each time the property is accessed seems a bit overkill. I'd really just like a simple way to tell in the subclass: now, the setter methof for property p is this one, only that… Thanks again anyway. - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Minor annoyances with properties
On May 28, 11:50 am, Christian Heimes li...@cheimes.de wrote: Am 28.05.2010 11:31, schrieb eb303: On May 27, 3:24 pm, Christian Heimes li...@cheimes.de wrote: Do I miss something? Is this the way to do it, or is there a better one? A better way was introduced in Python 2.6. Seehttp://docs.python.org/library/functions.html?highlight=property#prop... I have a Python only version around if you are still using Python 2.5. Christian Mmmm, I might still miss something. OK, I can replace my initial property using @property and @p.setter, but it doesn't seem to work in subclasses: class A(object): @property def p(self): return self._p @p.setter def _set_p(self, p): self._p = p class B(A): @p.setter def _set_p(self, p): … results in: Traceback (most recent call last): File toto.py, line 8, in module class B(A): File toto.py, line 9, in B @p.setter NameError: name 'p' is not defined It doesn't work because p is not in the scope of B's body while B is created. You have to write class B(A): # access the p property from class A @A.p.setter def p(self, p): pass # once p is in the class body scope, you must not use A.p again @p.deleter def p(self): pass Christian Well, I still have to explicitely specify the superclass's name then, so IMHO it's not a big improvement over repeating: p = property(A._get_p, _set_p) Thanks anyway… - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Minor annoyances with properties
Hello all, I've been using Python properties quite a lot lately and I've found a few things that are a bit annoying about them in some cases. I wondered if I missed something or if anybody else has this kind of problems too, and if there are better solutions than the ones I'm using ATM. The first annoyance is when I want to specialize a property in a subclass. This happens quite often actually, and it is even sometimes the reason why a plain attribute is turned into a property: a subclass needs to do more things than the superclass when the property is updated for example. So, of course, my first try was: class A(object): def __init__(self): self._p = None def _get_p(self): return self._p def _set_p(self, p): self._p = p p = property(_get_p, _set_p) class B(A): def _set_p(self, p): ## Additional things here… super(B, self)._set_p(p) And of course, it doesn't work: the property has been bound to A._set_p in A, so any new definition of _set_p in any subclass does not replace the set method for the property. So I always have to add a line: p = property(A._get_p, _set_p) in the subclass too. This is a bit awkward to me, since I have to specify the superclass's name (super(…) can't be used, since it should take B as an argument, and B isn't defined yet…). Do I miss something? Is this the way to do it, or is there a better one? The second annoyance is when I have a property that is a list of something. I often have to do something when the contents of the list is modified. So basically, I often end up doing the following: def C(object): def __init__(self): self._l = [] def _get_l(self): return list(self._l) def _set_l(self, l): self._l = list(l) l = property(_get_l, _set_l) But then, I have to do: o = C() l = o.l l.append(42) o.l = l instead of just doing: o.l.append(42) which would seem much more natural IMHO. Is there any not too complicated way to have o.l.append(…) call something in C? And the same for o.l.remove(…), o.l[i] = …, and everything else updating the list contents? Thanks! - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: platform-independent image copy/paste with Tkinter?
On May 15, 4:56 pm, technocake robin.ga...@gmail.com wrote: Hi. Is there a good way to copy from or paste to the clipboard on all systems running python using Tkinter? started a small road too it here: #!/usr/bin/python __author__=technocake __date__ =$15.mai.2010 15:53:39$ from Tkinter import * if __name__ == __main__: def displayClipboard(event): try: data = event.widget.clipboard_get(type=STRING) except : #Need a method for displaying a image here.. data = Image # finally: #Updates the textlabel lbl.config(text=data) root = Tk() lbl= Label(root, width=20) lbl.bind(Button-1, displayClipboard) #binding to leftclick lbl.pack() root.mainloop() The copy part is done via the methods clipboard_clear and clipboard_append, available on all Tkinter widgets. By the way, the default value for the 'type' option is 'STRING', so you actually don't need it here, and neither do you in clipboard_append. To be able to copy/paste images is much more platform dependent. There are actually types for clipboard contents that handle images, but they will vary from platform to platform and sometimes from application to application. You can even have several types for the same contents. To get these, you can use: widget.selection_get(selection='CLIPBOARD', type='TARGETS') You can try to copy an image on various platforms with various applications, then print the value for this expression to figure out what you can do with it. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter question
On Apr 22, 5:55 pm, Rotwang sg...@hotmail.co.uk wrote: James Mills wrote: On Wed, Apr 21, 2010 at 8:45 PM, Rotwang sg...@hotmail.co.uk wrote: [...] From reading the documentation myself (pydoc)... It would seem your only option is to make a thread out of this (not my preferred way - I was hoping it was possible to poll the Tk event system...). Thanks, I don't know anything about threading at the moment but I'll look into it. From my experience, mixing Tkinter with threads is a bad idea. As most GUI toolkits, it really doesn't like to be manipulated from different threads, so you might end up getting weird problems or even crashes. By the way, did you try to remove the line out.mainloop() from your 'draw' function? This is the line that blocks the IDLE GUI, since it initiates a secondary event loop that will only exit when you do a out.quit(), so that might be a solution. BTW, another problem: whenever I call a widget.quit() method, the widget in question crashes. IDLE carries on working but the widget window stays there, not responding, and if I tell my OS to kill it then IDLE restarts. Is this a bug? I'm using Windows 7 and Python 2.6.4. The 'quit' method just exits the mainloop. It doesn't destroy the widget. So if your application doesn't actually exit, the widget will just stay there. If you want to destroy the it too, you have to call explicitely widget.destroy(). HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter question
On Apr 23, 1:58 pm, Rotwang sg...@hotmail.co.uk wrote:
eb303 wrote:
On Apr 22, 5:55 pm, Rotwang sg...@hotmail.co.uk wrote:
[...]
From my experience, mixing Tkinter with threads is a bad idea. As most
GUI toolkits, it really doesn't like to be manipulated from different
threads, so you might end up getting weird problems or even crashes.
By the way, did you try to remove the line out.mainloop() from your
'draw' function?
I didn't. How do I get Python to display the draw window, other than by
using mainloop()?
Well, mainloop doesn't actually display anything. It's just the event
loop for tk. So since you run your program within IDLE, there is
already one running. What does it do if you delete the mainloop()
line? Doesn't your window appear at all?
This is the line that blocks the IDLE GUI, since it
initiates a secondary event loop that will only exit when you do a
out.quit(), so that might be a solution.
BTW, another problem: whenever I call a widget.quit() method, the widget
in question crashes. IDLE carries on working but the widget window stays
there, not responding, and if I tell my OS to kill it then IDLE
restarts. Is this a bug? I'm using Windows 7 and Python 2.6.4.
The 'quit' method just exits the mainloop. It doesn't destroy the
widget. So if your application doesn't actually exit, the widget will
just stay there. If you want to destroy the it too, you have to call
explicitely widget.destroy().
That worked like a charm, thanks!
Here's another problem I've run into today: I've just added a bit of
code so that it's possible to resize the draw window and the contents
will be resized automatically. The method now looks something like this:
out = Tkinter.Tk()
slave = Tkinter.Canvas(out, width = wh[0], height = wh[1])
slave.grid()
# I put the canvas widget inside a tk widget instead of just
# using the former because I want keypresses to do things, and
# it doesn't seem to be possible to bind keyboard events to a
# canvas
# draw something
slave.pack()
(Hope this line is a mistake: gridding *and* packing slave will
probably result in tk thinking for ages how it should display it in
its parent…)
def resize(b):
wh[:] = [b.width, b.height]
slave.config(width = wh[0], height = wh[1])
# resize the contents of slave
You don't need at all to resize the slave explicitely. You should do
the following:
- Tell 'out' that its first row and first column should resize
themselves when the window is resized by doing:
out.grid_rowconfigure(1, weight=1)
out.grid_columnconfigure(1, weight=1)
- Make sure slave is actually put in the cell in first row and column,
and that all its sides will stick to the cell borders:
slave.grid(row=1, column=1, sticky='nswe')
If you do that, the slave.config in the resize function shouldn't be
needed anymore.
out.bind('Configure', resize)
If using the grid options, better do a slave.bind(…) here, which will
call the binding when the canvas is resized, which is obvioulsy when
you want to update its contents.
out.mainloop()
The trouble is, when I call the method the window it spawns slowly grows
larger, until I move or resize it myself by grabbing one of the edges;
after this everything works as intended. If I add the line print wh
after wh[:] = [b.width, b.height], the output looks like this (the
default value of wh is [640,480]:
[644, 484]
[648, 488]
[648, 488]
[648, 488]
[652, 492]
[652, 492]
[652, 492]
[656, 496]
[656, 496]
[656, 496]
[660, 500]
etc.
My only guess as to why this is happening is that Tkinter is resizing
out to be 4 pixels wider and taller than slave, and the line
slave.config(...) consequently leads to resize being called again. But
this doesn't explain why it stops happening when I resize the window
intentionally, nor why the window apparently only gets larger every
third time resize is called. The problem goes away if I replace wh[:] =
[b.width, b.height] with
wh[:] = [b.width - 4, b.height - 4]
but this seems like a rather ad-hoc and ugly solution, and I'd rather
understand what's going on. Can anyone help?
You get the size for the outer window and apply it to the canvas
inside it. Since the canvas has a border which is 2 pixels wide by
default, this resizes the window containing it to take this border
into account. So your binding is called again, and so on… But using
the options to grid described above, there should never be any need to
resize the canvas explicitely.
HTH
- Eric -
--
http://mail.python.org/mailman/listinfo/python-list
Re: py3 tkinter Text accepts what bytes?
On Apr 23, 2:00 pm, Matthias Kievernagel mkie...@pirx.sirius.org wrote: Hello, I stumbled upon this one while porting some of my programs to Python 3.1. The program receives messages from a socket and displays them in a tkinter Text. Works fine in Python 2 and Python 3.1. The problems arrived when I wanted to know the details... First surprise: Text.insert accepts not only str but also bytes. So I looked into the sources to see how it is done. I found no magic in 'tkinter.__init__.py'. All python objects seem to go unchanged to _tkinter.c. There they are turned into Tcl objects using Tcl_NewUnicodeObj (for str) and Tcl_NewStringObj (for bytes). The man page for Tcl_NewStringObj says that it creates a tcl string from utf-8 encoded bytes. So I continued to test... Second surprise: Text.insert also works for latin-1 encoded bytes. It even works with mixed utf-8 and latin-1 encoded bytes. At least it works for me. Anyone can enlighten me, where this magic is done? Is it tcl magic or did I miss something in the python sources? Is this somewhere documented? Thanks for any hints, Matthias Kievernagel Let me guess: you're on Windows? ;-) There is nothing in the Python sources that can help you here. Everything is handled by the underlying tcl/tk interpreter. The default encoding for strings in tcl happens to be UTF-8. So putting bytestrings with a UTF-8 encoding in a Text widget will just work. For latin-1 strings, there is some magic going on, but apparently, this magic happens only on Windows (hence my guess above…), which seems to recognize its default encoding by some means. My advice is: don't count on it. It won't work on any other platform, and it might even stop working on Windows one day. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter question
On Apr 21, 12:45 pm, Rotwang sg...@hotmail.co.uk wrote: Apologies in advance if this is a totally stupid question, I've tried looking at the Tkinter documentation on the web but since I'm something of an ignoramus when it comes to programming generally I didn't understand what I was reading. Anyway... I've written a module that allows me to manipulate sound data, and I've been trying to add a method to my sound class that shows me what a waveform looks like while I'm working on it in IDLE. After reading a bit about Tkinter, and via some trial and error, I came up with something a bit like this: def draw(self, w, h): out = Tkinter.Canvas(width = w, height = h) # a load of out.create_line(...)'s go here out.pack() out.mainloop() It works, but the problem is that I can't do anything else with IDLE until I close the image window. Is there a way around this, so that I can leave the image open while I continue to do other stuff? Just run your program directly, either from a terminal or a DOS console or by double-clicking on it in a file manager if the proper file associations have been defined (they are by default on Windows). There might be some IDLE trick to make it work, but I don't use IDLE myself. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter scrollbar background color doesn't work
On Apr 19, 6:35 pm, KL klu1...@gmail.com wrote: Tkinter scrollbar widget's background and relief options seem not work. The below is the codes I tried and the python/tk information: === ActivePython 2.6.4.8 (ActiveState Software Inc.) based on Python 2.6.4 (r264:75706, Nov 3 2009, 13:23:17) [MSC v.1500 32 bit (Intel)] on win32 from Tkinter import * r=Tk() s=Scrollbar(r,bg=#000) s.grid() s['activebackground'] = #000 s['relief'] = sunken TkVersion 8.5 import sys sys.version '2.6.4 (r264:75706, Nov 3 2009, 13:23:17) [MSC v.1500 32 bit (Intel)]' On Windows, tk scrollbars are actually native scrollbars. So if native scrollbars don't allow changing their background or active background color, tk won't allow it either. Your script works as expected on Linux, but neither on Windows, nor on a Macintosh (where native scrollbars are used too). This is just how tk/Tkinter works, so I don't think there's any solution for it, except creating your own scrollbar widget by yourself. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: default value in list comprehension
On Apr 19, 2:20 pm, AlienBaby matt.j.war...@gmail.com wrote: Hi, just a quick one, Is it possible to achieve a default value in a list comprehension where the if-clause is false? Ie, something similar to: [ a for a in b if something(a) else 'default' ] the idea being that, rather than skip a value if the if-clause is false, to place a default value at that position in the returned list instead. ? Thanks, Matt. [a if something(a) else 'default' for a in b] HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: Instance factory - am I doing this right?
On Mar 3, 6:41 pm, Laszlo Nagy gand...@shopzeus.com wrote: This is just an interesting code pattern that I have recently used: class CacheStorage(object): Generic cache storage class. @classmethod def get_factory(cls,*args,**kwargs): Create factory for a given set of cache storage creation parameters. class CacheStorageFactory(cls): _construct_args = args _construct_kwargs = kwargs def __init__(self): cls.__init__(self, *self._construct_args,**self._construct_kwargs) return CacheStorageFactory Then, I can create subclasses like: class GdbmCacheStorage(CacheStorage): Gdbm cache storage class. @param basedir: Base directory where gdbm files should be stored. @param basename: Base name for logging and creating gdbm files. def __init__(self,basedir,basename): . blablabla place initialization code here class MemoryCacheStorage(CacheStorage): In-Memory cache storage class. Please note that keys and values are always mashal-ed. E.g. when you cache an object, it makes a deep copy. def __init__(self): . blablabla place initialization code here And the finally, I can create a factory that can create cache storage instances for storing data in gdbm in a given directory: cache_factory = GdbmCacheStorage.get_factory(~gandalf/db,test) print cache_factory # class '__main__.CacheStorageFactory' print cache_factory() OR I can create a factory that can create instances for storing data in memory: cache_factory = MemoryCacheStorage.get_factory() print cache_factory # class '__main__.CacheStorageFactory' print cache_factory() # __main__.CacheStorageFactory object at 0x8250c6c Now, here is my question. Am I right in doing this? Or are there better language tools to be used in Python for the same thing? This whole thing about creating factories looks a bit odd for me. Is it Pythonic enough? Thanks, Laszlo Seems you try to reinvent functools: class GdbmCacheStorage(object): def __init__(self,basedir,basename): ... cache_factory = functools.partial(GdbmCacheStorage, ~gandalf/db, test) print cache_factory() Is it what you're after? I didn't see the point in creating a cached factory for MemoryCacheStorage though, since it has no constructor parameters to cache anyway. So doing 'cache_factory = MemoryCacheStorage' in your example would do exactly the same thing as what you did. HTH - Eric - -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGDChart2 module
On Oct 28, 4:52 pm, eb303 eric.brunel.pragma...@gmail.com wrote: Hi all, I was looking for a simple chart drawing Python module and as a user of the gd library and its Python interface, I was interested in the Python interface to the gdchart library (http://www.fred.net/brv/ chart/). Unfortunately, this module seems to have disappeared: its former URL (http://www.nullcube.com/software/pygdchart2.html) gives a 404 and a Google search did not return any other source. Does anyone know where I can find a copy of this module's source code? Thanks. Replying to myself: finally found the source package at http://ftp.de.debian.org/debian/pool/main/p/pygdchart2/pygdchart2_0.beta1.orig.tar.gz Seems to work quite well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Oct 28, 10:48 am, Alf P. Steinbach al...@start.no wrote: * eb303: On Oct 28, 7:52 am, Alf P. Steinbach al...@start.no wrote: [snip] But since I don't know much Python -- I'm *learning* Python as I write -- I know that there's a significant chance of communicating misconceptions, non-idiomatic ways to do things, bad conventions, etc., in addition to of course plain errors of fact and understanding in general, to which I'm not yet immune... So I would would be very happy for feedback. OK, I'll start the flame war then: I can see the purpose of section 1.5, but from the end of the 3rd paragraph, you seem to go into religious matters rather than actual facts, which seems to me a bit out of place in a book only supposed to teach programming. Basically saying that any serious program has to be written in a statically typed language No, I didn't write that. and that such a language kind of automatically makes the development faster and the quality higher No, I didn't write that. Well, honestly, this is really what I understood when I've read: the compiler can detect a lot of errors and save you from having to painstakingly laboriously test every little detail. For a large program or system that really cuts down on the work (and hence time) and really increases quality which what you did write, right? So maybe it is an understanding problem on my side, but even if it is, other people may have the same as I had, don't you think? is just not true from my experience, Yes, that's a strawman -- nearly always good in flame wars. ;-) and from the experience of many people on this group, I guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is highly subjective and should be completely rewritten, if not simply removed. Just to fuel the flame war, consider a million line Python system. It's not uncommon with C++. :-) Well, I won't go into how C++ code tends to be quite longer than their Python equivalent (maybe I'm not too good at flame wars after all... ;-) ). But the application I'm working on right now includes nearly 30 lines of Python (among other languages). That's not a million indeed, but I wouldn't call it a small application. I've done a lot of C, Java, and some C++ as well before. And so far, what I'm seeing is that if you organize your work properly (TDD mainly...), the development goes faster, with no significant decrease in quality for the final product. So yes: I would consider a million line Python system without fear. -- http://mail.python.org/mailman/listinfo/python-list
Re: Hello, world?
On Oct 28, 11:23 am, Francesco Bochicchio bieff...@gmail.com wrote:
On 28 Ott, 10:40, Gilles Ganault nos...@nospam.com wrote:
Hello
I'm reading O'Reily's Python Programming on Win32, but couldn't find
a simple example on how to create a window with just a label and
pushbutton.
This is probably because maybe the book addresses how to use python to
do windows-specific
stuff (like using a COM interface) and presumes a basic knowledge of
python in the reader
(just guessing, never read the book )
If someone has such a basic example handy, I'm interested.
Thank you.
There are as many way to do it as many GUI toolkits for python you can
find (and there are
many) although they all share a similar structure. Here is the one for
Tkinter, which is the
default python GUI toolkit. The example is copied verbatim from
the python on-line documentation ( section Graphical User Interfaces
with Tk of The Python Standard Library).
Ciao
--
FB
from Tkinter import *
class Application(Frame):
def say_hi(self):
print hi there, everyone!
def createWidgets(self):
self.QUIT = Button(self)
self.QUIT[text] = QUIT
self.QUIT[fg] = red
self.QUIT[command] = self.quit
self.QUIT.pack({side: left})
self.hi_there = Button(self)
self.hi_there[text] = Hello,
self.hi_there[command] = self.say_hi
self.hi_there.pack({side: left})
def __init__(self, master=None):
Frame.__init__(self, master)
self.pack()
self.createWidgets()
root = Tk()
app = Application(master=root)
app.mainloop()
root.destroy()
Or way simpler:
---
from Tkinter import *
root = Tk()
Label(root, text='Hello world!').pack(side=TOP)
Button(root, text='Quit', command=root.quit).pack(side=BOTTOM)
root.mainloop()
---
HTH
--
http://mail.python.org/mailman/listinfo/python-list
Re: Feedback wanted on programming introduction (Python in Windows)
On Oct 28, 11:57 am, Alf P. Steinbach al...@start.no wrote: * eb303: On Oct 28, 10:48 am, Alf P. Steinbach al...@start.no wrote: * eb303: On Oct 28, 7:52 am, Alf P. Steinbach al...@start.no wrote: [snip] But since I don't know much Python -- I'm *learning* Python as I write -- I know that there's a significant chance of communicating misconceptions, non-idiomatic ways to do things, bad conventions, etc., in addition to of course plain errors of fact and understanding in general, to which I'm not yet immune... So I would would be very happy for feedback. OK, I'll start the flame war then: I can see the purpose of section 1.5, but from the end of the 3rd paragraph, you seem to go into religious matters rather than actual facts, which seems to me a bit out of place in a book only supposed to teach programming. Basically saying that any serious program has to be written in a statically typed language No, I didn't write that. and that such a language kind of automatically makes the development faster and the quality higher No, I didn't write that. Well, honestly, this is really what I understood when I've read: the compiler can detect a lot of errors and save you from having to painstakingly laboriously test every little detail. For a large program or system that really cuts down on the work (and hence time) and really increases quality which what you did write, right? Yes that's what I wrote. What I intended to communicate was literally what I wrote (which is true), but that's very far from what you understood, e.g. it seems that you read my word can as, quoting you, will automatically, apparently with an implied always. Well, sorry to keep the topic going, but I have a really hard time understanding your text as you claim you mean it. The word 'can' is actually there, but in the first sentence, not in the second. And when I read For a large program or system that really cuts down on the work (and hence time) and really increases quality after stating the supposed benefits of statically typed compiled languages, I do understand that a large program or system just has to be written in such a language, and certainly not in Python, which - again according to my experience - I know is just not true. But well, it seems I'm the only one around bothered by this text, so I guess the problem is with me. So if I ever get to teach programming, I guess I'll just have to find another book than yours... ;-) So maybe it is an understanding problem on my side, but even if it is, other people may have the same as I had, don't you think? Some will have the same misreading, and some will probably have other misreadings. I could reformulate it to cater for people who'd tend to read it your way and other ways, but one the problem with that is that there are so many possible ways to read a text when one s/can/will automatically/g, insert frivoluous claims about a serious (what's that?) category of programs, etc., and, being a fallible human being, I would be bound to miss some of them. ;-). Another problem is that delving into such details about possible things that I've *not* intended to write, listing all possible such things I could imagine, like, note: I'm not claiming XYZ, even though that claim, made by some, is vaguely associated with some of what I'm discussing, would make the first get started chapter not 9 pages or whatever this one is, but 150 pages and going. is just not true from my experience, Yes, that's a strawman -- nearly always good in flame wars. ;-) and from the experience of many people on this group, I guess. IMNSHO, the 4th paragraph of section 1.5 in its current form is highly subjective and should be completely rewritten, if not simply removed. Just to fuel the flame war, consider a million line Python system. It's not uncommon with C++. :-) Well, I won't go into how C++ code tends to be quite longer than their Python equivalent (maybe I'm not too good at flame wars after all... ;-) ). But the application I'm working on right now includes nearly 30 lines of Python (among other languages). That's not a million indeed, but I wouldn't call it a small application. I've done a lot of C, Java, and some C++ as well before. And so far, what I'm seeing is that if you organize your work properly (TDD mainly...), the development goes faster, with no significant decrease in quality for the final product. So yes: I would consider a million line Python system without fear. Uhm. :-) I'm serious. And even more: I'd fear a *lot* more a million lines application written in C++... But I do have a problem with C++... ;-) -- http://mail.python.org/mailman/listinfo/python-list
PyGDChart2 module
Hi all, I was looking for a simple chart drawing Python module and as a user of the gd library and its Python interface, I was interested in the Python interface to the gdchart library (http://www.fred.net/brv/ chart/). Unfortunately, this module seems to have disappeared: its former URL (http://www.nullcube.com/software/pygdchart2.html) gives a 404 and a Google search did not return any other source. Does anyone know where I can find a copy of this module's source code? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI
On Oct 26, 3:53 am, Grant Edwards inva...@invalid.invalid wrote: On 2009-10-26, Philip Semanchuk phi...@semanchuk.com wrote: On Oct 25, 2009, at 8:39 PM, Ronn Ross wrote: I need to create a gui for python. I'm looking for something that is easy to learn and cross platform. Any suggestions? If you have any good tutorials please send along. Thanks in advance. wxPython (which wraps wxWidgets) is popular and IMO reasonably well laid out. I wouldn't call wxPython easy to learn. (It is, however, what I use when I need a cross-platform GUI.) IMO, Tkinter is much easier to learn. But, it doesn't use native widgets, so Tkinter apps look like Tkinter apps rather than like other native apps. Not anymore: tcl/tk 8.5 now includes the ttk themed widget set, which can be made to use native widgets by setting the proper theme. I hear great things about PyQt (which wraps QT) but I haven't used it. PySide is a new wrapper for QT that has generated a lot of excitement but is still its infancy, I think. I've always intended to look into pyFLTK, but have never had time to do more than a simple hello world program. Does FLTK support native widgets? Last time I looked, it didn't seem to... But it was quite a long time ago. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter -- the best way to make a realtime loop
On Oct 8, 7:15 pm, J Wolfe vorticitywo...@gmail.com wrote: Thank you both for your replies. I had something similar to this: def incr(): var.set(1 + var.get()) root.after(1000, incr) except I had an extra set of parenthesis... def incr(): var.set(1 + var.get()) root.after(1000, incr()) on the function which was screwing it up. Also needed to have a root.update() to refresh the GUI. M, no? The root.update() should not be necessary: the triggering of the action specified in after(...) is done by the tk mainloop when it's idle, and if it's idle, it means that it already has updated the display. So no update() should be needed. What happens if you remove it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter -- the best way to make a realtime loop
On Oct 8, 12:40 am, J Wolfe vorticitywo...@gmail.com wrote: What's the best way to make a realtime loop in Tkinter? I know in perl you can use repeat and it will call a function every x seconds, in python it seems like after may be the equivalent though it doesn't seem to behave like the perl repeat function. Any ideas? Thanks, Jonathan Well, I don't know the Perl 'repeat' function, but AFAICT, after seems to be the way to go in Tkinter. Maybe something like this: --- from Tkinter import * root = Tk() var = IntVar() def incr(): var.set(1 + var.get()) root.after(1000, incr) Label(root, width=10, textvariable=var).pack() Button(root, text='Go!', command=incr).pack() root.mainloop() --- HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter - Text - bullets
On Sep 22, 7:45 am, Thomas Lehmann iris-und-thomas-lehm...@t-
Online.de wrote:
This is probably why you had all these alignment problems. But it's
weird, because the script I posted is copied and pasted from a really
script that I've run, and which doesn't cause any error. What is the
version of tcl/tk used by your Tkinter module? And what is your Python
version?
Using python 2.5 (with Tcl/Tk 8.4):
Traceback (most recent call last):
File Text1.py, line 10, in module
txt.tag_configure('bulleted_list', font=('Times', 18),
lmargin1='10m', lmargin2='15m', tabs=['15m'])
File E:\Python25\lib\lib-tk\Tkinter.py, line 3066, in
tag_configure
return self._configure(('tag', 'configure', tagName), cnf, kw)
File E:\Python25\lib\lib-tk\Tkinter.py, line 1188, in _configure
self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: bad screen distance ['15m']
Try tabs='15m' instead. Seems the list is not handled properly.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter - Text - bullets
On Sep 19, 5:53 pm, Thomas Lehmann iris-und-thomas-lehm...@t-
Online.de wrote:
Something like this maybe?
from Tkinter import *
root = Tk()
txt = Text(root, wrap='word')
txt.pack()
txt.tag_configure('text_body', font=('Times', 18), lmargin1=0,
lmargin2=0)
txt.tag_configure('bulleted_list', font=('Times', 18), lmargin1='10m',
lmargin2='15m', tabs=['15m'])
txt.insert(END, uThis is a normal paragraph. Let's make it a bit long
to see that it wraps as expected.\n, 'text_body')
txt.insert(END, u\u00B7\tThis is the first item in the list.\n,
'bulleted_list')
txt.insert(END, u\u00B7\tThis is the second item in the list. Let's
make this one quite long too to see how it wraps.\n, 'bulleted_list')
Thank you very much!
However, the result is not that pretty as I have expected. The bullets
are really small. When separating bullet and text then I can increase
the font size for the bullet but then it does not fit to the text -
vertical alignment is wrong. Also it's pretty unhandy to adjust the
margins so that the text continues on next line starting at the same
position as the first character from previous line.
But it is a starting. I will check whether it is possible to place an
image for a bullet. The size and position handling will be still there
then - I think so.
You can also use another font for bullets:
from Tkinter import *
import tkFont
root = Tk()
txt = Text(root, wrap='word')
txt.pack()
txt.tag_configure('text_body', font=('Times', 18), lmargin1=0,
lmargin2=0)
txt.tag_configure('bulleted_list', font=('Times', 18), lmargin1='10m',
lmargin2='15m', tabs=['15m'])
txt.tag_configure('bullets', font=('Dingbats', 18))
txt.insert(END, uThis is a normal paragraph. Let's make it a bit long
to see that it wraps as expected.\n, 'text_body')
txt.insert(END, u'\u25C6', 'bullets')
txt.insert(END, u\tThis is the first item in the list.\n,
'bulleted_list')
txt.insert(END, u'\u25C6', 'bullets')
txt.insert(END, u\tThis is the second item in the list. Let's make
this one quite long too to see how it wraps.\n, 'bulleted_list')
root.mainloop()
Also note: The tab value from your example has not been accepted (s.th
like. invalid screen distance)
This is probably why you had all these alignment problems. But it's
weird, because the script I posted is copied and pasted from a really
script that I've run, and which doesn't cause any error. What is the
version of tcl/tk used by your Tkinter module? And what is your Python
version?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter - Text - bullets
On Sep 18, 11:57 am, Thomas Lehmann iris-und-thomas-lehm...@t-
Online.de wrote:
My intention is to write a small custom widget displaying text where
the text can have a simple wiki syntax. The main interest is to
support heading, bold, italic, underline, itemization and enumeration.
How can I implement itemization using the Tkinter.Text widget?
(bullets)
Something like this maybe?
from Tkinter import *
root = Tk()
txt = Text(root, wrap='word')
txt.pack()
txt.tag_configure('text_body', font=('Times', 18), lmargin1=0,
lmargin2=0)
txt.tag_configure('bulleted_list', font=('Times', 18), lmargin1='10m',
lmargin2='15m', tabs=['15m'])
txt.insert(END, uThis is a normal paragraph. Let's make it a bit long
to see that it wraps as expected.\n, 'text_body')
txt.insert(END, u\u00B7\tThis is the first item in the list.\n,
'bulleted_list')
txt.insert(END, u\u00B7\tThis is the second item in the list. Let's
make this one quite long too to see how it wraps.\n, 'bulleted_list')
root.mainloop()
HTH
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Tkinter windows don't get focus on OS X
On Sep 11, 9:14 am, Hendrik van Rooyen hend...@microcorp.co.za wrote: On Thursday 10 September 2009 18:19:09 Joshua Bronson wrote: True, but it'll still be a lot less painful for me to test my app if I can get it to steal focus when launched from the command line. If anyone knows how to do this in Tkinter, help would be much appreciated. look for widget.focus_force() and look for widget.grab_set_global() Doesn't work. BTW, forcing the focus or setting the grab globally are usually considered very annoying and I don't know any windowing system or window manager honouring those. For the OP: the problem comes from the tcl/tk level. Running a tcl script just opening a window from the terminal shows the same behaviour. You might want to forward the question to the tcl guys. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Tkinter windows don't get focus on OS X
On Sep 11, 10:40 am, Hendrik van Rooyen hend...@microcorp.co.za wrote: On Friday 11 September 2009 09:53:56 eb303 wrote: On Sep 11, 9:14 am, Hendrik van Rooyen hend...@microcorp.co.za wrote: look for widget.focus_force() and look for widget.grab_set_global() Doesn't work. BTW, forcing the focus or setting the grab globally are usually considered very annoying and I don't know any windowing system or window manager honouring those. I have to confess I have never used the stuff - just remembered seeing it in the manual and pointed it out. What does it do? At tcl level, focus_force() and grab_set_global() are translated as options to the equivalents of focus_set() and grab_set() [1][2]. If these are not honoured, the options are simply ignored. That's what seems to happen on Mac OS X. So focus_force() does the same as focus_set(), and grab_set_global() the same as grab_set(). No use for the OP's problem... [1] http://www.tcl.tk/man/tcl8.5/TkCmd/focus.htm [2] http://www.tcl.tk/man/tcl8.5/TkCmd/grab.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of Tkinter and IDLE
On Aug 28, 4:41 pm, r rt8...@gmail.com wrote:
Thanks eb303 for the wonderful post
I have looked over the new ttk widgets and everything looks nice. I am
very glad to see the death of Tix as i never much liked it anyhow and
always believed these widgets should have been in the main Tkinter
module to start with. The tree widget has been needed for some time.
However, i am not sure about the new style separation. Previously a
simple command like root.option_add('*Label.Font'...) accomplished the
same thing with less typing, but there may be a future method to this
current madness that i am unaware of...???
The new widgets have been made mainly to make tk look better by making
it possible to use native widgets. The drawback is that it limits a
lot the possibilities of configuration you can have: on many
platforms, the looks of the widgets are decided by the user via a
system preference, not by the application programmer. This is why ttk
widgets are not configurable directly, because 'native' styles usually
don't allow it at application level anyway.
Keep in mind that the new ttk widgets are not replacements for former
widgets, but an addition to them. 'Old' widgets are still here, and
there is no plan I know of to remove them. If you want to do an
application with a very specific look, you can still use these.
--
http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of Tkinter and IDLE
On Aug 27, 11:22 pm, r rt8...@gmail.com wrote: - Python offical docs and Tkinter - *The Python docs barely cover anything related to actual Tkinter coding. At the minimum the Tkinter doc page should have a subpage for all the widgets available --which is very small(approx 15) and each subpage should list the available methods on that wiget. I think the general idea behind the 'lack' of documentation is that it would only double tcl/tk's own documentation. I've always used Tkinter using the tcl/tk docs here: http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm and once you get used to how you transform tcl syntax to Python syntax, it works pretty well. Maintaining a documentation for Tkinter in the official Python docs would force people to run after tcl. I understand why they don't want to do that, even if I'd love to see a better Tkinter documentation too. - from Tkinter import * - *Too many noobs start out with the from Tkinter import * idiom, unknowing that they are horribly polluting their namespace. I feel that all (tkinter) code should follow the import Tkinter as tk policy and never use from Tkinter import *. To push this agenda i propose all docs be modified so that no one should see such global import blasphemy again. We should at least keep all example code in the latter non-polluting form and frown heavily upon global imports in Tkinter code or any code for that matter. Well, I just don't agree with you on this one. AFAIK, Tkinter has been made to make the 'from Tkinter import *' idiom work without too much namespace pollution. I've always used it, still use it today, and never seen any problem with it. I do agree that this might lead newbies to think it's ok for all modules, and end up doing 'from os import *' and wonder why opening a file with 'open' no more works. But this is the only problem I can see. - Tkinter Constants - *The Tkconstants module needs to be removed *yesterday* because i think it reinforces sloppy coding styles. The main problem is with subtle bugs that are created when someone rebinds one or more of the constants, for example W=20. At first i thought the constants were great but I quickly found out the shortfalls of such a Utopian approach . Since Tkinter allows strings to be passed-into widget constructors, we should remove the TkConstants immediately and force everyone to use strings instead... #-- instead of this --# w.pack(side=LEFT,fill=BOTH,anchor=W) #-- do this --# w.pack(side='left',fill='both',anchor='w') The few extra keystrokes are well worth the effort! Well, again, I don't agree. I prefer having well defined constants than having to type strings. If the values for the fill option could be anything, well, OK. But they can't: they have to be either 'x' or 'y' or 'both'. So I prefer to have them defined in constants. [snip comments on IDLE, which I don't use] - Tkinter Canvas - *The Tkinter Canvas widget should return (X,Y) pairs when calling canvas.coords(obj). The current implementation returns a flat array that is pretty much useless outside of canvas calls. Of course one could zip the coords into pairs, but it seems clumsy to call zip() on 2 LC's when Tkinter could, and should, do it for you. We agree on this one, but it's a minor flaw. *Canvas needs a canvas.rotate() method for polygons, lines -- (easy). All Canvas methods are actually forwarded to the underlying tcl interpreter. So you might want to suggest that to the tcl guys. - Tkinter ComboBox -- where's Waldo? - *As much as i hate to support anything related to M$, Tkinter needs an M$ stlye combobox. Yes, I know Tix has combobox (*puke*), however using it is like pulling teeth. I have coded up an far more elegant/ simple solution -- and yes, i know about the OptionMenu widget which serves a useful purpose but is NOT a good replacement for a REAL M$ style combobox ;). You don't seem to be aware of the new widgets in tk, which do include a combo-box (and a lot of others BTW). See the ttk:: commands in the tcl/tk documentation (link above). These widgets already have a Python wrapper (see http://pypi.python.org/pypi/pyttk/0.3). *For instance, ComboBoxes need values that the user can select from, this is as universal as humans and oxygen. But sometimes you want to give the user a detailed set of values in the dropdown listbox and then insert an abbrieation of the value once selected, such as the case with state names... New Mexico - MN California - CA Florida - FL ...instead of the
[issue4961] Inconsistent/wrong result of askyesno function in tkMessageBox
New submission from eb303 eric.bru...@pragmadev.com: Scenario to reproduce the problem: - Run the attached script. - Click the 'Ask confirm' button and answer 'Yes'; it should print True, which is the expected answer. - Click the 'Ask file' button, select any file and confirm. - Click the 'Ask confirm' button and answer 'Yes'. The script prints False, which is obviously wrong. Problem reproduced on Linux Red Hat Fedora Core 4, Suse Enterprise Linux 9, Solaris 8 for Sparc and Solaris 10 on Intel. The script works as expected on Windows 2000, so it seems to be Unix-specific. Possible cause: the result of the _show function in tkMessageBox is not always a string, apparently depending on what happened before. Changing the last line to: return str(res) seemed to correct the problem for me. -- components: Tkinter files: dialog-bug.py messages: 79944 nosy: eb303 severity: normal status: open title: Inconsistent/wrong result of askyesno function in tkMessageBox type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12761/dialog-bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
