From geoff.bache at gmail.com  Tue May  4 11:06:22 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Tue, 4 May 2010 11:06:22 +0200
Subject: [Tkinter-discuss] Menu.unpost not working on Windows?
Message-ID: <l2m6e9920951005040206r3d5bf0c0k320ddbaa1ab8c6ec@mail.gmail.com>

Hi all,

I've been trying to use the "unpost" method on a popup menu and I
cannot make it work on Windows. It works fine on Linux, but seems to
have no effect on Windows even in simple cases. For example this basic
example code the menu is not unposted in Windows and is shown as
without the "unpost" line. Can anyone confirm or shed any light on
this?

Regards,
Geoff

from Tkinter import *

root = Tk()

w = Label(root, text="Right-click to display menu", width=40, height=20)
w.pack()

def next(*args):
    print "Next"

# create a menu
popup = Menu(root, tearoff=0)
popup.add_command(label="Next", command=next)

def do_popup(event):
    # display the popup menu
    popup.post(event.x_root, event.y_root)
    popup.unpost()

w.bind("<Button-3>", do_popup)

root.mainloop()

From rowen at uw.edu  Tue May  4 23:11:36 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Tue, 04 May 2010 14:11:36 -0700
Subject: [Tkinter-discuss] constraining toplevel windows to be on screen?
Message-ID: <rowen-C1230C.14113604052010@news.gmane.org>

I've received a bug report that my application's windows can appear off 
screen. This happens when a user has two monitors and saves window 
positions, then runs again later with only one monitor. Tkinter is 
apparently perfectly happy to display toplevel windows entirely off 
screen. At least on Mac OS X.

The solution I've thought of is to get the full screen size using 
"root.wm_maxsize" and use that to constrain the geometry when restoring 
the window positions.

However, it is messy code because tk geometry strings are complex: they 
may be missing the extent, or the extent may be positive or negative.

So I was wondering if somebody had a simpler solution or had already 
written code they would be willing to share (and, preferably, allow me 
to redistribute in the RO package).

It would suffice to show part of each window on screen, though it would 
be better to show the whole thing.

Regards,

-- Russell


From markpete at gmx.com  Wed May  5 19:35:30 2010
From: markpete at gmx.com (Mark Peterson)
Date: Wed, 5 May 2010 13:35:30 -0400
Subject: [Tkinter-discuss]  refreshing images
Message-ID: <g2v22ce85a41005051035n4c8be351wd6c1ae66f809e6e@mail.gmail.com>

Hi, all.  I'm brand new to using Tkinter, and was hoping to get a tip
on getting images to refresh after pressing a button.  The complete
code I'm using is below.

Basically, when I click on the "Next image" button, it will delete the
original image (good) but the next image doesn't show up (bad).  Is
there a command that gets the canvas to redraw with the second image?

Since I'm very new to Tkinter, the more explicit you could be about
how to change the code, the more helpful it would be.  Thanks very
much for any help.

Best,
   Mark

def nextImage():

    global canvas
    global item

    canvas.delete(item)

    im = Image.open("image2.gif")
    photo = ImageTk.PhotoImage(im)
    item = canvas.create_image(10,10,anchor=NW, image=photo)


from Tkinter import *
import Image
import ImageTk

root = Tk()

im = Image.open("image1.gif")
canvas = Canvas(root, height=im.size[1]+20, width=im.size[0]+20)
canvas.pack(side=LEFT,fill=BOTH,expand=1)

photo = ImageTk.PhotoImage(im)
item = canvas.create_image(10,10,anchor=NW, image=photo)

b1 = Button(root, text="Next image", width=15, command=nextImage)
b1.pack()

mainloop()

From klappnase at web.de  Thu May  6 11:52:11 2010
From: klappnase at web.de (Michael Lange)
Date: Thu, 6 May 2010 11:52:11 +0200
Subject: [Tkinter-discuss] refreshing images
In-Reply-To: <g2v22ce85a41005051035n4c8be351wd6c1ae66f809e6e@mail.gmail.com>
References: <g2v22ce85a41005051035n4c8be351wd6c1ae66f809e6e@mail.gmail.com>
Message-ID: <20100506115211.daec265a.klappnase@web.de>

Hi Mark,

On Wed, 5 May 2010 13:35:30 -0400
Mark Peterson <markpete at gmx.com> wrote:

> Hi, all.  I'm brand new to using Tkinter, and was hoping to get a tip
> on getting images to refresh after pressing a button.  The complete
> code I'm using is below.
> 
> Basically, when I click on the "Next image" button, it will delete the
> original image (good) but the next image doesn't show up (bad).  Is
> there a command that gets the canvas to redraw with the second image?
> 
> Since I'm very new to Tkinter, the more explicit you could be about
> how to change the code, the more helpful it would be.  Thanks very
> much for any help.
> 

The problem with your code is that you forget to keep a reference to
the newly created PhotoImage object, so when the nextImage() function
is done, the photo will immediately be garbage collected. Adding a
"global photo" statement to nextImage() fixes this.
Besides this, there is no need to make cnvas and item global in
nextImage() and it is probably better to simply change the image of the
existing canvas image item instead of creating a new one, so a better
nextImage() func might look like:

def nextImage():
    global photo
    im = Image.open("image2.gif")
    photo = ImageTk.PhotoImage(im)
    canvas.itemconfigure(item, image=photo)

Another thing: I see you use gif images in your example; because you
say you are new to Tkinter I am not sure if you know taht if you only
need to display gif images you can use the PhotoImage class built into
Tkinter which would make changing the image even easier:

def nextImage():
    photo.configure(file='image2.gif')

The ImageTk.PhotoImage does not have a configure() method, but you need
it only if you want to display image formats other than gif.

I hope this helps

Michael

> Best,
>    Mark
> 
> def nextImage():
> 
>     global canvas
>     global item
> 
>     canvas.delete(item)
> 
>     im = Image.open("image2.gif")
>     photo = ImageTk.PhotoImage(im)
>     item = canvas.create_image(10,10,anchor=NW, image=photo)
> 
> 
> from Tkinter import *
> import Image
> import ImageTk
> 
> root = Tk()
> 
> im = Image.open("image1.gif")
> canvas = Canvas(root, height=im.size[1]+20, width=im.size[0]+20)
> canvas.pack(side=LEFT,fill=BOTH,expand=1)
> 
> photo = ImageTk.PhotoImage(im)
> item = canvas.create_image(10,10,anchor=NW, image=photo)
> 
> b1 = Button(root, text="Next image", width=15, command=nextImage)
> b1.pack()
> 
> mainloop()
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss

From rowen at uw.edu  Thu May  6 21:07:40 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Thu, 06 May 2010 12:07:40 -0700
Subject: [Tkinter-discuss] constraining toplevel windows to be on screen?
References: <rowen-C1230C.14113604052010@news.gmane.org>
Message-ID: <rowen-E17FA2.12074006052010@news.gmane.org>

In article <rowen-C1230C.14113604052010 at news.gmane.org>,
 "Russell E. Owen" <rowen at uw.edu> wrote:

> I've received a bug report that my application's windows can appear off 
> screen. This happens when a user has two monitors and saves window 
> positions, then runs again later with only one monitor. Tkinter is 
> apparently perfectly happy to display toplevel windows entirely off 
> screen. At least on Mac OS X.
> 
> The solution I've thought of is to get the full screen size using 
> "root.wm_maxsize" and use that to constrain the geometry when restoring 
> the window positions.
> 
> However, it is messy code because tk geometry strings are complex: they 
> may be missing the extent, or the extent may be positive or negative.
> 
> So I was wondering if somebody had a simpler solution or had already 
> written code they would be willing to share (and, preferably, allow me 
> to redistribute in the RO package).
> 
> It would suffice to show part of each window on screen, though it would 
> be better to show the whole thing.
> 
> Regards,
> 
> -- Russell

OK, I coded up a new class RO.TkUtil.Geometry with a method constrained 
to handle this. Code available at PyPI 
<http://pypi.python.org/pypi?:action=display&name=RO> in case anyone 
else needs this.

In the process of testing this I discovered an amusing Tk 8.4 bug on Mac 
OS X: toplevels with negative corner position (e.g. "200x200-20-20") are 
mis-handled; the corner position is the distance from the bottom right 
corner of the screen to the TOP LEFT corner of the toplevel, instead of 
the bottom right corner.

Anyone out there running Tk 8.5 willing to test if this bug still exists 
on Tk 8.5?

-- Russell


From geoff.bache at gmail.com  Mon May 10 12:01:44 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Mon, 10 May 2010 12:01:44 +0200
Subject: [Tkinter-discuss] What's the point of Toplevel.wait_window?
Message-ID: <AANLkTin_qngD071tWqhKZL_J4CEhNGwuwxZALbpt_jkv@mail.gmail.com>

Hi all,

I'm struggling to understand what the wait_window method on
Tkinter.Toplevel objects actually achieves.

It seemed on the surface like it would make the dialog modal, but it
doesn't do that. The "grab_set" method achieves that.

I realise that it starts some kind of local wait loop but I can't
actually discern any external effect from calling it.

Regards,
Geoff Bache

From rowen at uw.edu  Tue May 11 00:24:49 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Mon, 10 May 2010 15:24:49 -0700
Subject: [Tkinter-discuss] What's the point of Toplevel.wait_window?
References: <AANLkTin_qngD071tWqhKZL_J4CEhNGwuwxZALbpt_jkv@mail.gmail.com>
Message-ID: <rowen-ECBF83.15244910052010@news.gmane.org>

In article 
<AANLkTin_qngD071tWqhKZL_J4CEhNGwuwxZALbpt_jkv at mail.gmail.com>,
 Geoff Bache <geoff.bache at gmail.com> wrote:

> Hi all,
> 
> I'm struggling to understand what the wait_window method on
> Tkinter.Toplevel objects actually achieves.
> 
> It seemed on the surface like it would make the dialog modal, but it
> doesn't do that. The "grab_set" method achieves that.
> 
> I realise that it starts some kind of local wait loop but I can't
> actually discern any external effect from calling it.
> 
> Regards,
> Geoff Bache

According to <http://wiki.tcl.tk/10014> it waits for the window to be 
destroyed. Why do you ask?

-- Russell


From geoff.bache at gmail.com  Tue May 11 09:07:50 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Tue, 11 May 2010 09:07:50 +0200
Subject: [Tkinter-discuss] What's the point of Toplevel.wait_window?
In-Reply-To: <rowen-ECBF83.15244910052010@news.gmane.org>
References: <AANLkTin_qngD071tWqhKZL_J4CEhNGwuwxZALbpt_jkv@mail.gmail.com>
	<rowen-ECBF83.15244910052010@news.gmane.org>
Message-ID: <AANLkTikX05NbYzy5Dvt5_zfdStyORqISBABi0itHMAth@mail.gmail.com>

> According to <http://wiki.tcl.tk/10014> it waits for the window to be
> destroyed. Why do you ask?

Hi Russell,

I realise that, but if I just don't call it and return control to the
mainloop then much the same thing will happen anyway (i.e. the
application will wait for events in the window concerned and respond
to them appropriately)

All the examples I can find for it are in the context of a modal
dialog but "grab_set" causes dialogs to be modal with or without
"wait_window".

I'm trying to understand some code I've inherited and getting some
funny race conditions which I can't really pin down, related to calls
to after_idle. They seem to go away if I remove the call to
wait_window so I'd like to get my head round what the point of calling
it is. The code looks much like the sample code (tkSimpleDialog.py) at
http://effbot.org/tkinterbook/tkinter-dialog-windows.htm and in fact
may even have been copied from there.

Regards,
Geoff

From geoff.bache at gmail.com  Mon May 17 22:52:56 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Mon, 17 May 2010 22:52:56 +0200
Subject: [Tkinter-discuss] after and after_idle
Message-ID: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>

Hi all,

Is there actually any difference between

root.after_idle(foo)

and

root.after(0, foo)

?

(I've noticed that if I call after_idle and re-add it at the end of my
callbacks then any calls to "after" have no effect, and that I can
work around this by doing after(0, ...) instead, but wondered if there
were any drawbacks to doing this.)

Regards,
Geoff Bache

From Cameron at phaseit.net  Mon May 17 23:01:51 2010
From: Cameron at phaseit.net (Cameron Laird)
Date: Mon, 17 May 2010 21:01:51 +0000
Subject: [Tkinter-discuss] after and after_idle
In-Reply-To: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>
References: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>
Message-ID: <20100517210151.GA17715@lairds.us>

On Mon, May 17, 2010 at 10:52:56PM +0200, Geoff Bache wrote:
			.
			.
			.
> root.after_idle(foo)
> 
> and
> 
> root.after(0, foo)
> 
> ?
> 
> (I've noticed that if I call after_idle and re-add it at the end of my
> callbacks then any calls to "after" have no effect, and that I can
> work around this by doing after(0, ...) instead, but wondered if there
> were any drawbacks to doing this.)
			.
			.
			.
Does <URL: http://wiki.tcl.tk/9926 > help?

From geoff.bache at gmail.com  Mon May 17 23:17:31 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Mon, 17 May 2010 23:17:31 +0200
Subject: [Tkinter-discuss] after and after_idle
In-Reply-To: <20100517210151.GA17715@lairds.us>
References: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>
	<20100517210151.GA17715@lairds.us>
Message-ID: <AANLkTimctVdappWZej4C14Rs1LHgp9bfs_QdXFOUoSRz@mail.gmail.com>

On Mon, May 17, 2010 at 11:01 PM, Cameron Laird <Cameron at phaseit.net> wrote:
> On Mon, May 17, 2010 at 10:52:56PM +0200, Geoff Bache wrote:
> ? ? ? ? ? ? ? ? ? ? ? ?.
> ? ? ? ? ? ? ? ? ? ? ? ?.
> ? ? ? ? ? ? ? ? ? ? ? ?.
>> root.after_idle(foo)
>>
>> and
>>
>> root.after(0, foo)
>>
>> ?
>>
>> (I've noticed that if I call after_idle and re-add it at the end of my
>> callbacks then any calls to "after" have no effect, and that I can
>> work around this by doing after(0, ...) instead, but wondered if there
>> were any drawbacks to doing this.)
> ? ? ? ? ? ? ? ? ? ? ? ?.
> ? ? ? ? ? ? ? ? ? ? ? ?.
> ? ? ? ? ? ? ? ? ? ? ? ?.
> Does <URL: http://wiki.tcl.tk/9926 > help?
>

Hi Cameron,

Thanks for the tip, hadn't occurred to me to look for Tcl/Tk
documentation. It didn't really answer the question though and I must
admit I don't speak Tcl so didn't really follow the example (which
looked to me like it nested a call to "after" inside a call to
"after_idle", why would you want to do that?)

Regards,
Geoff

From Cameron at phaseit.net  Mon May 17 23:25:05 2010
From: Cameron at phaseit.net (Cameron Laird)
Date: Mon, 17 May 2010 21:25:05 +0000
Subject: [Tkinter-discuss] after and after_idle
In-Reply-To: <AANLkTimctVdappWZej4C14Rs1LHgp9bfs_QdXFOUoSRz@mail.gmail.com>
References: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>
	<20100517210151.GA17715@lairds.us>
	<AANLkTimctVdappWZej4C14Rs1LHgp9bfs_QdXFOUoSRz@mail.gmail.com>
Message-ID: <20100517212505.GB22218@lairds.us>

On Mon, May 17, 2010 at 11:17:31PM +0200, Geoff Bache wrote:
			.
			.
			.
> Thanks for the tip, hadn't occurred to me to look for Tcl/Tk
> documentation. It didn't really answer the question though and I must
> admit I don't speak Tcl so didn't really follow the example (which
> looked to me like it nested a call to "after" inside a call to
> "after_idle", why would you want to do that?)
			.
			.
			.
I quote two Masters of Tk:

    Idles run until the idle queue is drained.  If
    an [after idle] reschedules itself endlessly, it
    hangs the event loop.  [after idle [after 0 ...]]
    causes the idle to schedule a timer event that's
    immediately ready, so the rescheduled callback is
    NOT an idle event and the event loop can make
    progress.

    idle events are critical to doing a good job of a
    GUI; [I have] no idea if they are useful for
    anything else ...

One of us needs to write this in readable English.  I know *I* am already
backed up ...

From geoff.bache at gmail.com  Wed May 19 21:27:06 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Wed, 19 May 2010 21:27:06 +0200
Subject: [Tkinter-discuss] after and after_idle
In-Reply-To: <20100517212505.GB22218@lairds.us>
References: <AANLkTimbCnuIkdnarr-Y2sTy95lep9lbfRLAQCYHa86t@mail.gmail.com>
	<20100517210151.GA17715@lairds.us>
	<AANLkTimctVdappWZej4C14Rs1LHgp9bfs_QdXFOUoSRz@mail.gmail.com>
	<20100517212505.GB22218@lairds.us>
Message-ID: <AANLkTil9OB-0voTPIB9mUIj5gG5ux2bpHJBBlTPa_QXC@mail.gmail.com>

> ? ? ? ? ? ? ? ? ? ? ? ?.
> I quote two Masters of Tk:
>
> ? ?Idles run until the idle queue is drained. ?If
> ? ?an [after idle] reschedules itself endlessly, it
> ? ?hangs the event loop. ?[after idle [after 0 ...]]
> ? ?causes the idle to schedule a timer event that's
> ? ?immediately ready, so the rescheduled callback is
> ? ?NOT an idle event and the event loop can make
> ? ?progress.
>
> ? ?idle events are critical to doing a good job of a
> ? ?GUI; [I have] no idea if they are useful for
> ? ?anything else ...
>
> One of us needs to write this in readable English. ?I know *I* am already
> backed up ...

OK. It would help me if the example was in readable Python for a start...

Am I right in thinking it would translate as

root.after_idle(foo)

def foo():
     .....
     root.after(0, foo)

In this case I'm even more confused. What's the point of it being an
"idle event"
the first time but never thereafter? Wouldn't it be equivalent to also
add it the
same way the first time?

Thanks,
Geoff

From paul.lowe at ngc.com  Wed May 26 19:06:33 2010
From: paul.lowe at ngc.com (Lowe, Paul J (AS))
Date: Wed, 26 May 2010 12:06:33 -0500
Subject: [Tkinter-discuss] OptionMenu Cannot Receive Keyboard Focus?
Message-ID: <7E3E3DC087DBF04C8D7C7AA00735AECF01F353C2@XMBTX141.northgrum.com>

Hi,

I've made a Tkinter gui composed of labels, entries, and optionmenus.

When I enter data on the keyboard and use the tab key to switch to the
next widget in the GUI, it always skips the OptionMenus entirely. For
example, if I have a GUI composed of an entry, an optionmenu, and
another entry, in that order, if I type text in the first entry, then
hit the tab key, the cursor will go straight to the other text entry -
skipping the optionmenu entirely.

Has anyone else observed this phenomenon? Is there a workaround? Is it a
formally documented bug?



Kindest Regards and Thank You,

Paul Lowe
Simulation Engineer
Northrop-Grumman Corporation, Aerospace Systems, CWIN
Telephone: (858) 618-4499
San Diego (Rancho Bernardo), California, USA
http://www.ngc.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20100526/5c57f7ec/attachment.html>

From klappnase at web.de  Wed May 26 20:34:32 2010
From: klappnase at web.de (Michael Lange)
Date: Wed, 26 May 2010 20:34:32 +0200
Subject: [Tkinter-discuss] OptionMenu Cannot Receive Keyboard Focus?
In-Reply-To: <7E3E3DC087DBF04C8D7C7AA00735AECF01F353C2@XMBTX141.northgrum.com>
References: <7E3E3DC087DBF04C8D7C7AA00735AECF01F353C2@XMBTX141.northgrum.com>
Message-ID: <20100526203432.6ab0bdaa.klappnase@web.de>

Hi,

On Wed, 26 May 2010 12:06:33 -0500
"Lowe, Paul J (AS)" <paul.lowe at ngc.com> wrote:

> Hi,
> 
> I've made a Tkinter gui composed of labels, entries, and optionmenus.
> 
> When I enter data on the keyboard and use the tab key to switch to the
> next widget in the GUI, it always skips the OptionMenus entirely. For
> example, if I have a GUI composed of an entry, an optionmenu, and
> another entry, in that order, if I type text in the first entry, then
> hit the tab key, the cursor will go straight to the other text entry -
> skipping the optionmenu entirely.
> 
> Has anyone else observed this phenomenon? Is there a workaround? Is
> it a formally documented bug?
> 

I think the OptionMenu's takefocus option is set to false by default,
so a simple

    your_option_menu.configure(takefocus=1)

should do the trick.

I hope this helps

Michael

 

From paul.lowe at ngc.com  Wed May 26 21:07:39 2010
From: paul.lowe at ngc.com (Lowe, Paul J (AS))
Date: Wed, 26 May 2010 14:07:39 -0500
Subject: [Tkinter-discuss] OptionMenu Cannot Receive Keyboard Focus?
In-Reply-To: <20100526203432.6ab0bdaa.klappnase@web.de>
References: <7E3E3DC087DBF04C8D7C7AA00735AECF01F353C2@XMBTX141.northgrum.com>
	<20100526203432.6ab0bdaa.klappnase@web.de>
Message-ID: <7E3E3DC087DBF04C8D7C7AA00735AECF01F35458@XMBTX141.northgrum.com>

Thanks! This really worked!

-Paul Lowe

-----Original Message-----
From: tkinter-discuss-bounces+paul.lowe=ngc.com at python.org
[mailto:tkinter-discuss-bounces+paul.lowe=ngc.com at python.org] On Behalf
Of Michael Lange
Sent: Wednesday, May 26, 2010 11:35
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] OptionMenu Cannot Receive Keyboard Focus?

Hi,

On Wed, 26 May 2010 12:06:33 -0500
"Lowe, Paul J (AS)" <paul.lowe at ngc.com> wrote:

> Hi,
> 
> I've made a Tkinter gui composed of labels, entries, and optionmenus.
> 
> When I enter data on the keyboard and use the tab key to switch to the
> next widget in the GUI, it always skips the OptionMenus entirely. For
> example, if I have a GUI composed of an entry, an optionmenu, and
> another entry, in that order, if I type text in the first entry, then
> hit the tab key, the cursor will go straight to the other text entry -
> skipping the optionmenu entirely.
> 
> Has anyone else observed this phenomenon? Is there a workaround? Is
> it a formally documented bug?
> 

I think the OptionMenu's takefocus option is set to false by default,
so a simple

    your_option_menu.configure(takefocus=1)

should do the trick.

I hope this helps

Michael

 
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss

From geoff.bache at gmail.com  Thu May 27 22:26:51 2010
From: geoff.bache at gmail.com (Geoff Bache)
Date: Thu, 27 May 2010 22:26:51 +0200
Subject: [Tkinter-discuss] ANN: PyUseCase 3.3: GUI testing for Tkinter (and
	PyGTK)
Message-ID: <AANLkTinyr2GBh70KA5lLXA4_Kc7SA-e_KiF_nds7Z9DR@mail.gmail.com>

Hi all,

Tkinter support in PyUseCase, introduced in March, is coming along and
 has matured a fair amount in this release with support also added for three
new widget types (Canvas, Checkbutton and Listbox).

It's still quite new though and I could really use some feedback and for it
to be tried a wider range of test applications. It should be easy to download
and try out...

Regards,
Geoff Bache

A bit more detail:

PyUseCase is an unconventional GUI testing tool for PyGTK and Tkinter,
along with a framework for testing Python GUIs in general.

Instead of recording GUI mechanics directly, it asks the user for
descriptive names and hence builds up a "domain language" along with a
"UI map file" that translates this language into actions on the
current GUI widgets. The point is to reduce coupling, allow very
expressive tests, and ensure that GUI changes mean changing the UI map
file but not all the tests.

Instead of an "assertion" mechanism, it auto-generates a log of the
GUI appearance and changes to it. The point is then to use that as a
baseline for text-based testing, using e.g. TextTest.

It also includes support for instrumenting code so that "waits" can be
recorded, making it far easier for a tester to record correctly
synchronized tests without having to explicitly plan for this.

Homepage: http://www.texttest.org/index.php?page=ui_testing
Download: http://sourceforge.net/projects/pyusecase
Mailing list: https://lists.sourceforge.net/lists/listinfo/pyusecase-users (new)
Bugs: https://bugs.launchpad.net/pyusecase/
Source: https://code.launchpad.net/pyusecase/

From Gary.Scorby at harlandfs.com  Fri May 28 00:33:59 2010
From: Gary.Scorby at harlandfs.com (Gary Scorby)
Date: Thu, 27 May 2010 15:33:59 -0700
Subject: [Tkinter-discuss] OptionMenu text justification
Message-ID: <35060D8B9453294F98923B7F6FAA2DAD0AA70A33@pdx-srv-ex1.harlandfs.com>

I'm new to Tkinter.  I need a drop down box to display a selection list
to an end user.  It appears the best option for this is "OptionMenu" (If
not, please suggest other options).  I have it working like we want
except for one thing, after selecting something from the list and
closing the list, the text is centered in the window.  We have some very
long lines of text to choose from.  When the choice is made we would
like the chosen text to be left justified in the window.  I've tried
ever option I can find, but the text remains centered.  Any assistance
will be appreciated.

 

Thank you

 

Gary  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20100527/99d19dc1/attachment.html>

From klappnase at web.de  Fri May 28 12:56:50 2010
From: klappnase at web.de (Michael Lange)
Date: Fri, 28 May 2010 12:56:50 +0200
Subject: [Tkinter-discuss] OptionMenu text justification
In-Reply-To: <35060D8B9453294F98923B7F6FAA2DAD0AA70A33@pdx-srv-ex1.harlandfs.com>
References: <35060D8B9453294F98923B7F6FAA2DAD0AA70A33@pdx-srv-ex1.harlandfs.com>
Message-ID: <20100528125650.cf10338f.klappnase@web.de>

Hi Gary,

On Thu, 27 May 2010 15:33:59 -0700
Gary Scorby <Gary.Scorby at harlandfs.com> wrote:

> I'm new to Tkinter.  I need a drop down box to display a selection
> list to an end user.  It appears the best option for this is
> "OptionMenu" (If not, please suggest other options).  I have it
> working like we want except for one thing, after selecting something
> from the list and closing the list, the text is centered in the
> window.  We have some very long lines of text to choose from.  When
> the choice is made we would like the chosen text to be left justified
> in the window.  I've tried ever option I can find, but the text
> remains centered.  Any assistance will be appreciated.
> 
>  

I admit, I am not sure what exactly you want to achieve. Does

    your_option_menu.configure(wraplength=150, justify='left')

do what you want?

I hope this helps

Michael

From jmcmonagle at velseis.com  Mon May 31 01:12:05 2010
From: jmcmonagle at velseis.com (John McMonagle)
Date: Mon, 31 May 2010 09:12:05 +1000
Subject: [Tkinter-discuss] OptionMenu text justification
In-Reply-To: <35060D8B9453294F98923B7F6FAA2DAD0AA70A33@pdx-srv-ex1.harlandfs.com>
References: <35060D8B9453294F98923B7F6FAA2DAD0AA70A33@pdx-srv-ex1.harlandfs.com>
Message-ID: <4C02F0C5.30800@velseis.com.au>

Gary Scorby wrote:
> I?m new to Tkinter.  I need a drop down box to display a selection list
> to an end user.  It appears the best option for this is ?OptionMenu? (If
> not, please suggest other options).  I have it working like we want
> except for one thing, after selecting something from the list and
> closing the list, the text is centered in the window.  We have some very
> long lines of text to choose from.  When the choice is made we would
> like the chosen text to be left justified in the window.  I?ve tried
> ever option I can find, but the text remains centered.  Any assistance
> will be appreciated.
> 
>  

In what widget are you displaying the text ?   Label, Entry, Text ?


For example, the following code displays two labels with varying lengths
of text, aligned to the left:

from Tkinter import *
r = Tk()
t1 = 'Short text'
t2 = 'Long line of meaningless text to illustrate problem'
l1 = Label(r, text=t1)
l2 = Label(r, text=t2)

l1.pack(anchor=W)
l2.pack(anchor=W)

r.mainloop()

Now, if you wish to restrict the text to some horizontal distance and
keep it left justified, you would use wraplength=distance, justify=LEFT
as extra options to the Label widget.

I hope this provides some assistance.

Regards,

John