Re: ttk Scale: missing attributes

[eb303]

On Jun 23, 7:26 pm, Alan G Isaac  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

[eb303]

On Jun 21, 6:36 pm, rantingrick  wrote:
> On Jun 21, 12:36 am, Anthony Papillion  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/
>
>  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

[eb303]

On Jun 21, 7:36 am, Anthony Papillion  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
'x'.

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)

[eb303]

On Jun 12, 1:40 am, random joe  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: Tkinter library reference

[eb303]

On May 29, 3:11 pm, Pradeep B  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: tkinter function outout to text widget

[eb303]

On May 29, 10:51 pm, Johan Lans  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: GUI programs

[eb303]

On May 30, 5:21 pm, "Alf P. Steinbach"  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: Minor annoyances with properties

[eb303]

On May 28, 11:50 am, Christian Heimes  wrote:
> Am 28.05.2010 11:31, schrieb eb303:
>
>
>
> > On May 27, 3:24 pm, Christian Heimes  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 
> >     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

Re: Minor annoyances with properties

[eb303]

On May 27, 3:14 pm, Neil Cerutti  wrote:
> On 2010-05-27, eb303  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

[eb303]

On May 27, 8:56 pm, Francesco Bochicchio  wrote:
> On 27 Mag, 14:37, eb303  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

[eb303]

On May 27, 3:24 pm, Christian Heimes  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 
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

Minor annoyances with properties

[eb303]

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?

[eb303]

On May 15, 4:56 pm, technocake  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("", 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: py3 tkinter Text accepts what bytes?

[eb303]

On Apr 23, 2:00 pm, Matthias Kievernagel 
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

[eb303]

On Apr 23, 1:58 pm, Rotwang  wrote:
> eb303 wrote:
> > On Apr 22, 5:55 pm, Rotwang  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('', 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: Tkinter question

[eb303]

On Apr 22, 5:55 pm, Rotwang  wrote:
> James Mills wrote:
> > On Wed, Apr 21, 2010 at 8:45 PM, Rotwang  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

[eb303]

On Apr 21, 12:45 pm, Rotwang  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

[eb303]

On Apr 19, 6:35 pm, KL  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

[eb303]

On Apr 19, 2:20 pm, AlienBaby  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?

[eb303]

On Mar 3, 6:41 pm, Laszlo Nagy  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 # 
> 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 # 
> 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

[eb303]

On Oct 28, 4:52 pm, eb303  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: Tkinter callback arguments

[eb303]

On Nov 1, 8:53 pm, Lord Eldritch  wrote:
> Hi
>
> Maybe this is maybe something it has been answered somewhere but I haven't
> been able to make it work. I wanna pass one variable to a callback function
> and I've read the proper way is:
>
> Button(.., command=lambda: function(x))
>
> So with
>
> def function(a): print a
>
> I get the value of x. Ok. My problem now is that I generate the widgets in a
> loop and I use the variable to 'label' the widget:
>
> for x in range(0,3):  Button(.., command=lambda: function(x))
>
> so pressing each button should give me 0,1,2.
>
> But with the lambda, I always get the last index, because it gets actualized
> at each loop cycle. Is there any way to get that?

for x in range(0,3): Button(..., command=functools.partial(function,
x))

With the functools standard module that appeared in version 2.5, I
hardly ever use lambdas in Tkinter callbacks now.

> Thanks in advance!

HTH
-- 
http://mail.python.org/mailman/listinfo/python-list

PyGDChart2 module

[eb303]

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: Feedback wanted on programming introduction (Python in Windows)

[eb303]

On Oct 28, 11:57 am, "Alf P. Steinbach"  wrote:
> * eb303:
>
>
>
> > On Oct 28, 10:48 am, "Alf P. Steinbach"  wrote:
> >> * eb303:
>
> >>> On Oct 28, 7:52 am, "Alf P. Steinbach"  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

Re: "Hello, world"?

[eb303]

On Oct 28, 11:23 am, Francesco Bochicchio  wrote:
> On 28 Ott, 10:40, Gilles Ganault  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)

[eb303]

On Oct 28, 10:48 am, "Alf P. Steinbach"  wrote:
> * eb303:
>
> > On Oct 28, 7:52 am, "Alf P. Steinbach"  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: Feedback wanted on programming introduction (Python in Windows)

[eb303]

On Oct 28, 7:52 am, "Alf P. Steinbach"  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 and that such a language kind of automatically makes
the development faster and the quality higher is just not true from my
experience, 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.

Sorry if that sounds rough: I've seen this written too many times
(usually without any argumentation, BTW) and it has a tendency to make
me a little upset.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python GUI

[eb303]

On Oct 26, 3:53 am, Grant Edwards  wrote:
> On 2009-10-26, Philip Semanchuk  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

[eb303]

On Oct 8, 7:15 pm, J Wolfe  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

[eb303]

On Oct 8, 12:40 am, J Wolfe  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

[eb303]

On Sep 22, 7:45 am, Thomas Lehmann  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 
> 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

[eb303]

On Sep 19, 5:53 pm, Thomas Lehmann  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, u"This 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, u"This 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

[eb303]

On Sep 18, 11:57 am, Thomas Lehmann  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, u"This 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

[eb303]

On Sep 11, 10:40 am, Hendrik van Rooyen 
wrote:
> On Friday 11 September 2009 09:53:56 eb303 wrote:
>
> > On Sep 11, 9:14 am, Hendrik van Rooyen 
> > 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: New Tkinter windows don't get focus on OS X

[eb303]

On Sep 11, 9:14 am, Hendrik van Rooyen 
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: An assessment of Tkinter and IDLE

[eb303]

On Aug 28, 4:41 pm, r  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

[eb303]

On Aug 27, 11:22 pm, r  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
>   Cali