From python at bdurham.com  Sun Mar  3 19:26:17 2013
From: python at bdurham.com (python at bdurham.com)
Date: Sun, 03 Mar 2013 13:26:17 -0500
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
Message-ID: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>

I've been away from Tkinter for awhile. Curious if Tkinter is available
for iOS devices (iPad//iPhone)? My google searches have not come up
with anything interesting.



Thanks!

Malcolm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130303/21b3abea/attachment.html>

From python at bdurham.com  Sun Mar  3 19:28:39 2013
From: python at bdurham.com (python at bdurham.com)
Date: Sun, 03 Mar 2013 13:28:39 -0500
Subject: [Tkinter-discuss] Tkinter compatibility with and enhancements for
	Windows 8 Metro GUI
Message-ID: <1362335319.11863.140661199410433.5CBE168F@webmail.messagingengine.com>

Looking for feedback on Tkinter compatibility with Windows 8 Metro GUI
and if there are any 3rd party libraries that support Windows 8 Metro
touch screen enhancements.



Thank you,

Malcolm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130303/bff2ae46/attachment.html>

From kw at codebykevin.com  Sun Mar  3 19:47:47 2013
From: kw at codebykevin.com (Kevin Walzer)
Date: Sun, 03 Mar 2013 13:47:47 -0500
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
In-Reply-To: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
References: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
Message-ID: <51339AD3.6050203@codebykevin.com>

On 3/3/13 1:26 PM, python at bdurham.com wrote:
> I've been away from Tkinter for awhile. Curious if Tkinter is available
> for iOS devices (iPad//iPhone)? My google searches have not come up with
> anything interesting.
> Thanks!
> Malcolm

No, it's not. I imagine the work to port Tk (and Tcl) to iOS would be a 
massive undertaking.

--Kevinn


-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

From michael.odonnell at uam.es  Sun Mar  3 20:24:00 2013
From: michael.odonnell at uam.es (Michael O'Donnell)
Date: Sun, 3 Mar 2013 20:24:00 +0100
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
In-Reply-To: <51339AD3.6050203@codebykevin.com>
References: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
	<51339AD3.6050203@codebykevin.com>
Message-ID: <CABaQFFHKuTRTX3K4UiSg_vEiVXojOPSgQ0ka84BgrrWXwWeQQw@mail.gmail.com>

As I understand it, GUI can be used under Objective C,
but the only viable GUI is that used in Apple's Objective C.

One solution would be to provide a library called tkinter with
the same classes and methods as those provided by tkinter, but instead
mapped onto Apple's GUI (is it COCOA?)

This may or may not be difficult, based on the kinds
of metaphors Apple uses.

Of course, only the subset of Tkinter you actually use would need
to be mapped.

Mick



On Sun, Mar 3, 2013 at 7:47 PM, Kevin Walzer <kw at codebykevin.com> wrote:
>
> On 3/3/13 1:26 PM, python at bdurham.com wrote:
>>
>> I've been away from Tkinter for awhile. Curious if Tkinter is available
>> for iOS devices (iPad//iPhone)? My google searches have not come up with
>> anything interesting.
>> Thanks!
>> Malcolm
>
>
> No, it's not. I imagine the work to port Tk (and Tcl) to iOS would be a
> massive undertaking.
>
> --Kevinn
>
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss



-- 

Not sent from my iPhone

From kw at codebykevin.com  Sun Mar  3 21:10:52 2013
From: kw at codebykevin.com (Kevin Walzer)
Date: Sun, 03 Mar 2013 15:10:52 -0500
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
In-Reply-To: <CABaQFFHKuTRTX3K4UiSg_vEiVXojOPSgQ0ka84BgrrWXwWeQQw@mail.gmail.com>
References: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
	<51339AD3.6050203@codebykevin.com>
	<CABaQFFHKuTRTX3K4UiSg_vEiVXojOPSgQ0ka84BgrrWXwWeQQw@mail.gmail.com>
Message-ID: <5133AE4C.4000704@codebykevin.com>

On 3/3/13 2:24 PM, Michael O'Donnell wrote:
> This may or may not be difficult, based on the kinds
> of metaphors Apple uses.

It took Daniel Steffen, the previous maintainer of Tk on the Mac, nine 
months of full-time work (sponsored by Apple) to port Tk from its old 
Carbon base to its current Cocoa one.

Porting Tk to run on iOS would be a bigger job. First, there is not a 
one-to-one mapping between the traditional Cocoa API's and their iOS 
equivalents; there are differences. So there would be a lot of actual 
porting work to be done, new code written, by someone who had in-depth 
knowledge of Tk's internal API, its Cocoa API, and iOS's UI frameworks 
as well.

The second challenge is that there is no viable port of Tcl running on 
iOS that I'm aware of. Even if that port is somewhat simpler, it would 
still require time. Tk is not viable without a Tcl interpreter to 
undergird it. (Deep down, much of Tkinter simply involves calls to the 
Tcl interpreter from Python.)

The third challenge is who would do it. Daniel Steffen was the 
maintainer of Tk for nearly a decade, and had written a huge amount of 
the previous Carbon implementation, and so was well-qualified to take it 
on; Apple contracted with him to do the port on that basis. Daniel is 
now an Apple employee and would not be able to undertake such a project. 
As the current maintainer of Tk on the Mac, some might suggest that I 
take on the project, but I lack Daniel Steffen's expertise and would not 
have the time to pursue it. I do a lot of bug fixing and reviewing of 
patches--general maintainer stuff--but rewriting large swaths of Tk's 
Mac implementation from scratch is outside my brief.

So: yes, it would be difficult. It would be extremely difficult. I 
wouldn't hold my breath.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

From michael.odonnell at uam.es  Sun Mar  3 22:14:47 2013
From: michael.odonnell at uam.es (Michael O'Donnell)
Date: Sun, 3 Mar 2013 22:14:47 +0100
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
In-Reply-To: <5133AE4C.4000704@codebykevin.com>
References: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
	<51339AD3.6050203@codebykevin.com>
	<CABaQFFHKuTRTX3K4UiSg_vEiVXojOPSgQ0ka84BgrrWXwWeQQw@mail.gmail.com>
	<5133AE4C.4000704@codebykevin.com>
Message-ID: <CABaQFFFiCshheOe6UNmLHK6z_=WimBLd08Afkh0wcYMPc2k0DQ@mail.gmail.com>

Hi Kevin,

> So: yes, it would be difficult. It would be extremely difficult. I wouldn't
> hold my breath.

  I was not actually suggesting porting
Tk (or Tkinter).  Rather, building a set of classes
with the same names as those Tkinter uses,
and similar methods, but these instead call
the iOS GUI API classes and methods.

In some cases, this might be easy, but in others
difficult.

I did a lot of this in the early days of GUIs, where
I had to change GUIs quite often (starting 1990). I found it easier
to provide an abstraction layer between my code
and the actual underlying graphic engine.

But yes, I can see problems, for instance
if you used the pack geometry manager, it is unlikely
that iOS would use similar. But windows are windows,
buttons are buttons, and all GUI APIs need som way to
specify that elements should exist, and where they are placed.

Mick





On Sun, Mar 3, 2013 at 9:10 PM, Kevin Walzer <kw at codebykevin.com> wrote:
>
> On 3/3/13 2:24 PM, Michael O'Donnell wrote:
>>
>> This may or may not be difficult, based on the kinds
>> of metaphors Apple uses.
>
>
> It took Daniel Steffen, the previous maintainer of Tk on the Mac, nine
> months of full-time work (sponsored by Apple) to port Tk from its old Carbon
> base to its current Cocoa one.
>
> Porting Tk to run on iOS would be a bigger job. First, there is not a
> one-to-one mapping between the traditional Cocoa API's and their iOS
> equivalents; there are differences. So there would be a lot of actual
> porting work to be done, new code written, by someone who had in-depth
> knowledge of Tk's internal API, its Cocoa API, and iOS's UI frameworks as
> well.
>
> The second challenge is that there is no viable port of Tcl running on iOS
> that I'm aware of. Even if that port is somewhat simpler, it would still
> require time. Tk is not viable without a Tcl interpreter to undergird it.
> (Deep down, much of Tkinter simply involves calls to the Tcl interpreter
> from Python.)
>
> The third challenge is who would do it. Daniel Steffen was the maintainer of
> Tk for nearly a decade, and had written a huge amount of the previous Carbon
> implementation, and so was well-qualified to take it on; Apple contracted
> with him to do the port on that basis. Daniel is now an Apple employee and
> would not be able to undertake such a project. As the current maintainer of
> Tk on the Mac, some might suggest that I take on the project, but I lack
> Daniel Steffen's expertise and would not have the time to pursue it. I do a
> lot of bug fixing and reviewing of patches--general maintainer stuff--but
> rewriting large swaths of Tk's Mac implementation from scratch is outside my
> brief.
>
> So: yes, it would be difficult. It would be extremely difficult. I wouldn't
> hold my breath.
>
> --Kevin
>
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com



-- 

Not sent from my iPhone

From greg.ewing at canterbury.ac.nz  Sun Mar  3 23:20:19 2013
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 04 Mar 2013 11:20:19 +1300
Subject: [Tkinter-discuss] Tkinter for iOS (iPad//iPhone)
In-Reply-To: <CABaQFFFiCshheOe6UNmLHK6z_=WimBLd08Afkh0wcYMPc2k0DQ@mail.gmail.com>
References: <1362335177.11667.140661199409929.0F37B4F5@webmail.messagingengine.com>
	<51339AD3.6050203@codebykevin.com>
	<CABaQFFHKuTRTX3K4UiSg_vEiVXojOPSgQ0ka84BgrrWXwWeQQw@mail.gmail.com>
	<5133AE4C.4000704@codebykevin.com>
	<CABaQFFFiCshheOe6UNmLHK6z_=WimBLd08Afkh0wcYMPc2k0DQ@mail.gmail.com>
Message-ID: <5133CCA3.4000309@canterbury.ac.nz>

Michael O'Donnell wrote:
> But yes, I can see problems, for instance
> if you used the pack geometry manager, it is unlikely
> that iOS would use similar.

If iOS Cocoa is anything like regular Cocoa, there's
nothing remotely like it. You'd have to reimplement
the pack and grid geometry managers in their entirety,

Duplicating the exact behaviour of the text and
canvas widgets would be a lot of work, too.

> But windows are windows,
> buttons are buttons, and all GUI APIs need som way to
> specify that elements should exist, and where they are placed.

You'd think so, but from my experience with PyGUI,
it never seems to be as simple as that. And I have
the advantage that I get to design my own API.
Trying to wrap one GUI API to make it match another
existing one is even harder.

-- 
Greg

From woswwf at yahoo.co.uk  Tue Mar  5 17:26:12 2013
From: woswwf at yahoo.co.uk (Ian)
Date: Tue, 5 Mar 2013 16:26:12 +0000 (GMT)
Subject: [Tkinter-discuss] Ian
Message-ID: <1362500772.5276.YahooMailNeo@web171705.mail.ir2.yahoo.com>

gxou
http://www.pescamandeo.com/doquxzgo/n


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

From bob at passcal.nmt.edu  Thu Mar  7 01:49:49 2013
From: bob at passcal.nmt.edu (Bob Greschke)
Date: Wed, 6 Mar 2013 17:49:49 -0700
Subject: [Tkinter-discuss] StringVar() .trace(), .trace_vdelete() use
Message-ID: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>

Hi!

I'm messing with the .trace() function of StringVar()s to, in this case, check to see that the user has not entered more than an allowable number of characters (ckW() below does that).  I'm replacing a monstrous <KeyRelease> .bind method.

I'm using the line below and it seems to work fine, but I'm not sure I understand it.  lambdas really make my head hurt.  Var is a global StringVar() (the line below is in a function of mine that I call to create a Label():Entry() pair of widgets, like "Barcode: ___________").  A form (Toplevel with Entry() fields on it) with an Entry() associated with a StringVar() may be destroyed and brought up multiple times over the course of using the program, so the .trace() may be applied to a given StringVar() multiple times.  Is that a problem?  Do these calls "stack up", or does one identical .trace() cancel the previous one?  In case they do stack up I wanted to do a trace_vdelete() right before this .trace line, but I can't get it right.  Do I need to do it?  If so, how?

    ...
    [Var.trace_vdelete here?]
    Var.trace("w", lambda nm, idx, mode, var = Var: ckW(var, Max))
    ...

Thanks!

Bob


From bryan.oakley at gmail.com  Thu Mar  7 02:18:57 2013
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Wed, 6 Mar 2013 19:18:57 -0600
Subject: [Tkinter-discuss] StringVar() .trace(), .trace_vdelete() use
In-Reply-To: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>
References: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>
Message-ID: <CAKypQnyhhr4NAwKBhz5dxQ+x+hDQNtBtMu4pXgvreAR4o8C3kw@mail.gmail.com>

If you're doing this for input validation you should consider using
the built-in validation features of the entry widget instead of using
a trace. Here's a description of how to use it:

http://stackoverflow.com/a/4140988/7432


On Wed, Mar 6, 2013 at 6:49 PM, Bob Greschke <bob at passcal.nmt.edu> wrote:
> Hi!
>
> I'm messing with the .trace() function of StringVar()s to, in this case, check to see that the user has not entered more than an allowable number of characters (ckW() below does that).  I'm replacing a monstrous <KeyRelease> .bind method.

From bob at greschke.com  Thu Mar  7 04:11:39 2013
From: bob at greschke.com (Bob Greschke)
Date: Wed, 6 Mar 2013 20:11:39 -0700
Subject: [Tkinter-discuss] StringVar() .trace(), .trace_vdelete() use
In-Reply-To: <CAKypQnyhhr4NAwKBhz5dxQ+x+hDQNtBtMu4pXgvreAR4o8C3kw@mail.gmail.com>
References: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>
	<CAKypQnyhhr4NAwKBhz5dxQ+x+hDQNtBtMu4pXgvreAR4o8C3kw@mail.gmail.com>
Message-ID: <93EBB944-3D39-44EC-ADCF-228AFD9ECCD8@greschke.com>

I saw that earlier in the day (and a couple of weeks ago too).  I understand it just about as well as lambdas. :)  Do all of those values get passed each time a key is pressed?  Also, each Entry() field has a different max length.  Where do I pass that in all of this?  It would need to be an arg to vcmd in the Entry().  I couldn't see how to do that.  I have an old chunk of code that allows you to pass parameters to things like the functions associated with a Button widget's 'command=' callback, but I didn't see how that would fit in here.  I don't want to create a different vcmd for every possible allowed length. (there's dozens in the whole program).

On 2013-03-06, at 18:18, Bryan Oakley <bryan.oakley at gmail.com> wrote:

> If you're doing this for input validation you should consider using
> the built-in validation features of the entry widget instead of using
> a trace. Here's a description of how to use it:
> 
> http://stackoverflow.com/a/4140988/7432
> 
> 
> On Wed, Mar 6, 2013 at 6:49 PM, Bob Greschke <bob at passcal.nmt.edu> wrote:
>> Hi!
>> 
>> I'm messing with the .trace() function of StringVar()s to, in this case, check to see that the user has not entered more than an allowable number of characters (ckW() below does that).  I'm replacing a monstrous <KeyRelease> .bind method.
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
> 


From klappnase at web.de  Thu Mar  7 10:01:16 2013
From: klappnase at web.de (Michael Lange)
Date: Thu, 7 Mar 2013 10:01:16 +0100
Subject: [Tkinter-discuss] StringVar() .trace(), .trace_vdelete() use
In-Reply-To: <93EBB944-3D39-44EC-ADCF-228AFD9ECCD8@greschke.com>
References: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>
	<CAKypQnyhhr4NAwKBhz5dxQ+x+hDQNtBtMu4pXgvreAR4o8C3kw@mail.gmail.com>
	<93EBB944-3D39-44EC-ADCF-228AFD9ECCD8@greschke.com>
Message-ID: <20130307100116.39603651.klappnase@web.de>

Hi,

On Wed, 6 Mar 2013 20:11:39 -0700
Bob Greschke <bob at greschke.com> wrote:

> I saw that earlier in the day (and a couple of weeks ago too).  I
> understand it just about as well as lambdas. :)  Do all of those values
> get passed each time a key is pressed?  

Yes, when you register a function as validation callback, all the
registered values will be passed each time a validation occurs (which may
be every key press when validate='key', focus in/out events if
validate='focus(in/out)' or all of these if validate='all' .

> Also, each Entry() field has a
> different max length.  Where do I pass that in all of this?  It would
> need to be an arg to vcmd in the Entry().

This sounds like a job for a custom entry class. I wrote a
quick example to illustrate the usage of the Entry's vcmd that might be a
starting point for you:

#######################################################################
from Tkinter import *

class VEntry(Entry):
    def __init__(self, master=None, maxlength=5, value='foo', **kw):
        Entry.__init__(self, master, **kw)

        self._maxlength = maxlength
        self.insert('end', value)
        vcmd = (self.register(self._vcmd), '%s', '%P')
        self.configure(vcmd=vcmd, validate='all')

    def _vcmd(self, old, new):
        print old, new
        if len(new) > self._maxlength:
            return False
        return True

root = Tk()
e = VEntry(root, maxlength=7, value='bar')
e.pack(padx=100, pady=100)
e.focus_set()
root.mainloop()
#######################################################################

You see, the `%s' ("old value") parameter in this example is not really
needed, I added it just to illustrate how to pass multiple arguments to
the vcmd. See http://www.tcl.tk/man/tcl8.4/TkCmd/entry.htm#M16 for a list
of all possible percent substitutions and their meanings.
You could also try if validate='key' is sufficient for your needs.

The one thing one has to be very careful to keep in mind when writing a
validation command callback is that it must always return a boolean value
in any case, otherwise Tk will be "confused" and simply and silently turn
off validation altogether. This may especially easily happen when the vcmd
callback happens to throw an error, so one has to take care that all
possible exceptions are properly caught by try...except statements.


Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Compassion -- that's the one things no machine ever had.  Maybe it's
the one thing that keeps men ahead of them.
		-- McCoy, "The Ultimate Computer", stardate 4731.3

From bob at passcal.nmt.edu  Thu Mar  7 22:56:18 2013
From: bob at passcal.nmt.edu (Bob Greschke)
Date: Thu, 7 Mar 2013 14:56:18 -0700
Subject: [Tkinter-discuss] StringVar() .trace(), .trace_vdelete() use
In-Reply-To: <20130307100116.39603651.klappnase@web.de>
References: <B127B811-DD78-4DA3-BE0A-B20DAEB95B9A@passcal.nmt.edu>
	<CAKypQnyhhr4NAwKBhz5dxQ+x+hDQNtBtMu4pXgvreAR4o8C3kw@mail.gmail.com>
	<93EBB944-3D39-44EC-ADCF-228AFD9ECCD8@greschke.com>
	<20130307100116.39603651.klappnase@web.de>
Message-ID: <00E410CB-D727-47CB-9AF2-39C482E80312@passcal.nmt.edu>

Now I understand where "bloatware" comes from. :)
This will make your eye's water:

###################################
PROG_NAME = "Headache"

from Tkinter import *
PROG_SEARCHMODS = "><=#*~_"
PROGFw = {}
PROGFw["Qty"] = 7
PROGBar = {}

Root = Tk()
ROOTNameVar = StringVar()
ROOTQtyVar = StringVar()
ROOTQtyVar.set("HI")

Clr = {"R":"#FF0000", "D":Button().cget("bg")}



####################
class vEntry(Entry):
    def __init__(self, master=None, bar = "", **kw):
        Entry.__init__(self, master, **kw)
        VCmd = (self.register(self.VCmd), '%s', '%P')
        self.configure(vcmd = VCmd, validate='key')
        self.MaxLen = self.cget("width")-1
        self.icursor(END)
        self.VarSet = bar
    def VCmd(self, Old, New):
        Max = self.MaxLen
        if len(New) > 0:
# If the first character of the field's text is one of the search modifiers
# then allow one more character to be entered.
            if New[0] in PROG_SEARCHMODS:
		Max += 1
	if len(New) > Max:
            Root.bell()
            return False
        if self.VarSet != "":
            PROGBar[self.VarSet].configure(bg = Clr["R"])
            eval("%sBarSVar"%self.VarSet).set(1)
        return True



###########################################
def chgPROGChgBar(VarSet, State, e = None):
    if State == 1:
# This may be called upon to clear the change bar of a form that doesn't have
# a change bar, so try.
        try:
            PROGBar[VarSet].configure(bg = Clr["R"])
            eval("%sBarSVar"%VarSet).set(1)
	except:
            pass
    elif State == 0:
	try:
            PROGBar[VarSet].configure(bg = Clr["D"])
            eval("%sBarSVar"%VarSet).set(0)
	except:
            pass
# For some routines to use so they don't have to constantly check to see if
# the change bar state should be changed. The call gets made, but nothing
# happens.
    elif State == -1:
        return
    return



##################################################
def labelEntry(Sub, LabTx, TheVar, Max, Bar = ""):
    Label(Sub, text = LabTx).pack(side = LEFT)
    if isinstance(Max, basestring) or isinstance(Max, str):
        Max = PROGFw[Max]
    LEnt = vEntry(Sub, textvariable = TheVar, width = Max+1, bar = Bar)
    LEnt.pack(side = LEFT)
    return LEnt



######################
def rootDoSomething():
    print "Working..."
# Clean all input fields (mostly .strip()'ing)
# Verify what was entered (.upper() and/or look for missing info and/or make
# sure an integer is entrered where only an integer can be entered, etc.)
    try:
        int(ROOTQtyVar.get())
    except:
        print "Qty: Must be an integer."
        return
# Save to db, or use inputs to make an SQL command for a search, etc.
    ROOTNameVar.set("")
    ROOTQtyVar.set("")
    chgPROGChgBar("ROOT", 0)
    print "Done."
    return



##################
LFrm = Frame(Root)
ROOTBarSVar = IntVar()
PROGBar["ROOT"] = Frame(LFrm, height = 5)
PROGBar["ROOT"].pack(side = TOP, fill = X, expand = YES, pady = 3)
Sub = Frame(LFrm)
labelEntry(Sub, "Name:", ROOTNameVar, 20)
Sub.pack(side = TOP, pady = 20)
Sub = Frame(LFrm)
labelEntry(Sub, "Qty:", ROOTQtyVar, "Qty", "ROOT")
Sub.pack(side = TOP, padx = 20, pady = 20)
Sub = Frame(LFrm)
Button(Sub, text = "Go", command = rootDoSomething).pack(side = TOP)
Sub.pack(side = TOP)
LFrm.pack(side = TOP)

Root.mainloop()

######################################

It's micro-mini-chunks of code from a 42,000 line inventory and shipping program.

The class does what it needs to do and dovetails in with the rest of the program.  So we're telling a View object, the Entry() (you caught me -- trying to learn MVC stuff in iOS/OSX), to control the contents of a Model object, the StringVar(), instead of having model things, functions via .trace(), control the contents of a Model thing, the StringVar(), which would then automagically update the View.  Right?  Jobs would never approve. He probably wouldn't approve either way.

I might keep it if I can't figure out what happens when you StringVar.trace() on the same variable twice.  Using .trace() and just looking at the contents of the StringVar() seems way more straightforward (read non-obfuscated) to me.  The only thing that didn't make sense was the lambda. :)

Thanks!


On 2013-03-07, at 02:01, Michael Lange <klappnase at web.de> wrote:

> Hi,
> 
> On Wed, 6 Mar 2013 20:11:39 -0700
> Bob Greschke <bob at greschke.com> wrote:
> 
>> I saw that earlier in the day (and a couple of weeks ago too).  I
>> understand it just about as well as lambdas. :)  Do all of those values
>> get passed each time a key is pressed?  
> 
> Yes, when you register a function as validation callback, all the
> registered values will be passed each time a validation occurs (which may
> be every key press when validate='key', focus in/out events if
> validate='focus(in/out)' or all of these if validate='all' .
> 
>> Also, each Entry() field has a
>> different max length.  Where do I pass that in all of this?  It would
>> need to be an arg to vcmd in the Entry().
> 
> This sounds like a job for a custom entry class. I wrote a
> quick example to illustrate the usage of the Entry's vcmd that might be a
> starting point for you:
> 
> #######################################################################
> from Tkinter import *
> 
> class VEntry(Entry):
>    def __init__(self, master=None, maxlength=5, value='foo', **kw):
>        Entry.__init__(self, master, **kw)
> 
>        self._maxlength = maxlength
>        self.insert('end', value)
>        vcmd = (self.register(self._vcmd), '%s', '%P')
>        self.configure(vcmd=vcmd, validate='all')
> 
>    def _vcmd(self, old, new):
>        print old, new
>        if len(new) > self._maxlength:
>            return False
>        return True
> 
> root = Tk()
> e = VEntry(root, maxlength=7, value='bar')
> e.pack(padx=100, pady=100)
> e.focus_set()
> root.mainloop()
> #######################################################################
> 
> You see, the `%s' ("old value") parameter in this example is not really
> needed, I added it just to illustrate how to pass multiple arguments to
> the vcmd. See http://www.tcl.tk/man/tcl8.4/TkCmd/entry.htm#M16 for a list
> of all possible percent substitutions and their meanings.
> You could also try if validate='key' is sufficient for your needs.
> 
> The one thing one has to be very careful to keep in mind when writing a
> validation command callback is that it must always return a boolean value
> in any case, otherwise Tk will be "confused" and simply and silently turn
> off validation altogether. This may especially easily happen when the vcmd
> callback happens to throw an error, so one has to take care that all
> possible exceptions are properly caught by try...except statements.


From memilanuk at gmail.com  Fri Mar  8 06:38:52 2013
From: memilanuk at gmail.com (Monte Milanuk)
Date: Thu, 07 Mar 2013 21:38:52 -0800
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
Message-ID: <khbth8$226$1@ger.gmane.org>

So... I've been tinkering with python and Tkinter and ttk a bit lately, 
and because I've been using pylint which complains a lot if I do a 
wildcard import like I see in many (most?) Tkinter tutorials i.e.

from Tkinter import *
from ttk import *

I've been trying to avoid doing wildcare imports, but I was finding that 
if I imported in this form:

from Tkinter import Tk
from ttk import Frame, Label, Button, Entry

...that I started running into problems where my grid positioning info 
started causing warnings that the variables 'S' and 'E' were not 
defined.  Here is an example line:

labelCel = Label(frame, text="Celsius temperature:")
labelCel.grid(row=1, column=1, sticky=(S, E))
labelFar = Label(frame, text="Fahrenheit temperature:")
labelFar.grid(row=2, column=1, sticky=(S, E))

Furthermore, when I did try to run the program, the python interpreter 
objected as well and it crashed at the first undefined 'S'...

I dug around a little and found one resource that instead imported like 
this:

import Tkinter as tk

and then the code would look like this:

labelCel = tk.Label(frame, text="Celsius temperature:")
labelCel.grid(row=1, column=1, sticky=(tk.S, tk.E))
labelFar = tk.Label(frame, text="Fahrenheit temperature:")
labelFar.grid(row=2, column=1, sticky=(tk.S, tk.E))

Which worked and is all well and good... if I didn't want ttk widgets 
instead of Tkinter when possible.

Somewhere along the line I found yet another example/tutorial that 
showed something like this:

from Tkinter import Tk, S, E
from ttk import Frame, Label, Button, Entry

which works with the original code example, but thats where I get 
confused.

I have to import Label from ttk but the sticky parameters from Tkinter? 
  Pardon me for saying, but that doesn't appear to make a whole lot of 
sense at first glance.  Am I getting that correct, or is there some 
other way to do it that is more correct?

I'm starting to think it'd just be easier to put some tags in comments 
at the start of the file to tell pylint to disable warning me about 
wildcard imports, and just go back to using those!

Thanks,

Monte


From michael.odonnell at uam.es  Fri Mar  8 09:02:08 2013
From: michael.odonnell at uam.es (Michael O'Donnell)
Date: Fri, 8 Mar 2013 09:02:08 +0100
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <khbth8$226$1@ger.gmane.org>
References: <khbth8$226$1@ger.gmane.org>
Message-ID: <CABaQFFExnf+VCzYvHHeYUPMrULwWdL4RTh-BDsiePvq44dvo9w@mail.gmail.com>

Hi Monte,

> I'm starting to think it'd just be easier to put some tags in comments at
> the start of the file to tell pylint to disable warning me about wildcard
> imports, and just go back to using those!

Yes, a lot simpler.

A lot of symbols such as S, N, X, Y, BOTH etc.
are constants (well, variables which don't change value)
used within Tkinter.

Most of us do a blanket "from tkinter import *"
to get all of these symbols defined.

Wildcard imports are considered bad because of
possible conflicts, you might end up importing
a symbol from two modules, and then your code
might end up using the wrong one.

My solution to this is to ONLY do wildcard import
from tkinter, or any module I myself write, and
in which I avoid tkinter symbols.

Mick

From klappnase at web.de  Fri Mar  8 10:33:08 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 10:33:08 +0100
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <khbth8$226$1@ger.gmane.org>
References: <khbth8$226$1@ger.gmane.org>
Message-ID: <20130308103308.125d055d.klappnase@web.de>

Hi,

On Thu, 07 Mar 2013 21:38:52 -0800
Monte Milanuk <memilanuk at gmail.com> wrote:

(...)
> 
> from Tkinter import Tk, S, E
> from ttk import Frame, Label, Button, Entry
> 
> which works with the original code example, but thats where I get 
> confused.
> 
> I have to import Label from ttk but the sticky parameters from Tkinter? 
>   Pardon me for saying, but that doesn't appear to make a whole lot of 
> sense at first glance.  Am I getting that correct, or is there some 
> other way to do it that is more correct?
> 
> I'm starting to think it'd just be easier to put some tags in comments 
> at the start of the file to tell pylint to disable warning me about 
> wildcard imports, and just go back to using those!

you may want to have a look at the Tkconstants.py module, where all these
contants like S, N and so on are defined. If you do

	from Tkinter import *

all of these are added to the namespace automagically, however if you do

	import Tkinter

the constants have to be either addressed by Tkinter.S etc. *or* (and
that is what I would recommend) you can simply use the string values the
constants represent, like "s" for S, "left" for LEFT and so on, as in

	labelCel.grid(row=1, column=1, sticky="se")


Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Witch!  Witch!  They'll burn ya!
		-- Hag, "Tomorrow is Yesterday", stardate unknown

From bryan.oakley at gmail.com  Fri Mar  8 12:54:57 2013
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Fri, 8 Mar 2013 05:54:57 -0600
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <khbth8$226$1@ger.gmane.org>
References: <khbth8$226$1@ger.gmane.org>
Message-ID: <CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>

On Thu, Mar 7, 2013 at 11:38 PM, Monte Milanuk <memilanuk at gmail.com> wrote:
> So... I've been tinkering with python and Tkinter and ttk a bit lately, and
> because I've been using pylint which complains a lot if I do a wildcard
> import like I see in many (most?) Tkinter tutorials i.e.
>
> from Tkinter import *
> from ttk import *

The tutorials are all wrong.

My advice:

Always do it this way:

    import Tkinter as tk
    import ttk

There! Now there's no global namespace pollution, and everything's
accessible. Plus, it becomes immediately clear whether you're using
ttk widgets or tkinter widgets: ttk..Button(...) or tk.Button(...).
Your code becomes more self documenting. Also, if you switch to
python3 you have to change just the imports and everything should
continue to work.

As for the constants, with this scheme you would use tk.BOTH, etc.
Personally I'm in favor of never using the constants; I see no value
in them. These things truly are constants in the underlying tk
plumbing, so you can just use the literal string "both', "n", etc
rather than the constants. There's simply no need to use a constant
named BOTH when you can use "both".  Plus, isn't "nsew" better than
N+S+E+W?

From Cameron at phaseit.net  Fri Mar  8 15:02:54 2013
From: Cameron at phaseit.net (Cameron Laird)
Date: Fri, 8 Mar 2013 14:02:54 +0000
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
References: <khbth8$226$1@ger.gmane.org>
	<CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
Message-ID: <20130308140254.GB15742@lairds.us>

On Fri, Mar 08, 2013 at 05:54:57AM -0600, Bryan Oakley wrote:
> On Thu, Mar 7, 2013 at 11:38 PM, Monte Milanuk <memilanuk at gmail.com> wrote:
> > So... I've been tinkering with python and Tkinter and ttk a bit lately, and
> > because I've been using pylint which complains a lot if I do a wildcard
> > import like I see in many (most?) Tkinter tutorials i.e.
> >
> > from Tkinter import *
> > from ttk import *
> 
> The tutorials are all wrong.
> 
> My advice:
> 
> Always do it this way:
> 
>     import Tkinter as tk
>     import ttk
> 
> There! Now there's no global namespace pollution, and everything's
> accessible. Plus, it becomes immediately clear whether you're using
> ttk widgets or tkinter widgets: ttk..Button(...) or tk.Button(...).
> Your code becomes more self documenting. Also, if you switch to
> python3 you have to change just the imports and everything should
> continue to work.
> 
> As for the constants, with this scheme you would use tk.BOTH, etc.
> Personally I'm in favor of never using the constants; I see no value
> in them. These things truly are constants in the underlying tk
> plumbing, so you can just use the literal string "both', "n", etc
> rather than the constants. There's simply no need to use a constant
> named BOTH when you can use "both".  Plus, isn't "nsew" better than
> N+S+E+W?
			.
			.
			.
Me, too.

As much as I favor brevity, I have been consistent in my
career in eschewing "from Tkinter import *" in favor of
"import Tkinter ...", even though that--or because!--re-
sults in the need to qualify references.  My experience
is that the source code which follows, and the maintain-
ers who read it, are happier.

I so strongly believe this that I'm tempted to initiate
a project to reform, or at least counteract, the "many
(most?) Tkinter tutorials".  

[The problem is that following through would mean more
neglect of PyPDF2 and ..., where I'm *really* needed.]

From memilanuk at gmail.com  Fri Mar  8 17:18:16 2013
From: memilanuk at gmail.com (Monte Milanuk)
Date: Fri, 8 Mar 2013 16:18:16 +0000 (UTC)
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
References: <khbth8$226$1@ger.gmane.org>
	<CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
Message-ID: <loom.20130308T171525-501@post.gmane.org>

Bryan Oakley <bryan.oakley <at> gmail.com> writes:

> My advice:
> 
> Always do it this way:
> 
>     import Tkinter as tk
>     import ttk
> 
> There! Now there's no global namespace pollution, and everything's
> accessible. Plus, it becomes immediately clear whether you're using
> ttk widgets or tkinter widgets: ttk..Button(...) or tk.Button(...).
> Your code becomes more self documenting. Also, if you switch to
> python3 you have to change just the imports and everything should
> continue to work.

I had considered this... but was concerned that it might cause some
confusion with widgets having similar names such as 'tk.foo()' and
'ttk.foo()'.  I'll have to give it a try and see how it feels in
practice.

> 
> As for the constants, with this scheme you would use tk.BOTH, etc.
> Personally I'm in favor of never using the constants; I see no value
> in them. These things truly are constants in the underlying tk
> plumbing, so you can just use the literal string "both', "n", etc
> rather than the constants. There's simply no need to use a constant
> named BOTH when you can use "both".  Plus, isn't "nsew" better than
> N+S+E+W?
> 

I'm a little fuzzy here on exactly what you mean by 'constants'...
I thought 'both', S+E, etc. were parameters for a function call, not
constants...





From bryan.oakley at gmail.com  Fri Mar  8 17:26:10 2013
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Fri, 8 Mar 2013 10:26:10 -0600
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <loom.20130308T171525-501@post.gmane.org>
References: <khbth8$226$1@ger.gmane.org>
	<CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
	<loom.20130308T171525-501@post.gmane.org>
Message-ID: <CAKypQnyHbAdpfeAKAr5rG++LPEeJXRgjQueSCHK8+RK4xFdxxw@mail.gmail.com>

On Fri, Mar 8, 2013 at 10:18 AM, Monte Milanuk <memilanuk at gmail.com> wrote:
> Bryan Oakley <bryan.oakley <at> gmail.com> writes:
>
>> My advice:
>>
>> Always do it this way:
>>
>>     import Tkinter as tk
>>     import ttk
>>
>> There! Now there's no global namespace pollution, and everything's
>> accessible. Plus, it becomes immediately clear whether you're using
>> ttk widgets or tkinter widgets: ttk..Button(...) or tk.Button(...).
>> Your code becomes more self documenting. Also, if you switch to
>> python3 you have to change just the imports and everything should
>> continue to work.
>
> I had considered this... but was concerned that it might cause some
> confusion with widgets having similar names such as 'tk.foo()' and
> 'ttk.foo()'.  I'll have to give it a try and see how it feels in
> practice.

The advantage to this is that it _removes_ the confusion. With this,
it will always be clear which foo() you're working with.

>> As for the constants, with this scheme you would use tk.BOTH, etc.
>> Personally I'm in favor of never using the constants; I see no value
>> in them. These things truly are constants in the underlying tk
>> plumbing, so you can just use the literal string "both', "n", etc
>> rather than the constants. There's simply no need to use a constant
>> named BOTH when you can use "both".  Plus, isn't "nsew" better than
>> N+S+E+W?
>>
>
> I'm a little fuzzy here on exactly what you mean by 'constants'...
> I thought 'both', S+E, etc. were parameters for a function call, not
> constants...

They are just variables that contain strings. Yes, you can use them as
parameters to a function call, but the literal strings work just as
well.

From klappnase at web.de  Fri Mar  8 17:52:26 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 17:52:26 +0100
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
Message-ID: <20130308175226.5d738f2a.klappnase@web.de>

Hi,

I noticed that image data in ttk widgets seem to be updated only when the
widget receives keyboard focus or the mouse pointer enters the widget.
A simple example of what I mean:

#####################################################################
import Tkinter
import ttk

icon1 = ('R0lGODlhFQANAMIAAJaWlu/v7////wAAAP///////////////yH5BAEAAA'
            'QALAAAAAAVAA0AAANACLqsQTDCRsOTUYnNucUZIAwDRwofSGhk2aIXq'
            'I1tCauruL1bKus1mw/DOr2GkqKphAx1ns0JwEKtRlfWbAyTAAA7')
icon2 = ('R0lGODlhFQANAKEAAJaWlu/v7////////yH5BAEAAAMALAAAAAAVAA0AAA'
            'IyhI8Ww80Jw3LNiIuxpBXkv3GD9WkTR5ZCiHrqelJpycquWjszGOs33'
            'etIhsRcpYgMMgoAOw==')

root = Tkinter.Tk()
im = Tkinter.PhotoImage(data=icon1)

b = ttk.Button(image=im, text='ttk.Button', compound='left')
b.pack(padx=100, pady=30)
b2 = Tkinter.Button(image=im, text='Tkinter.Button', compound='left')
b2.pack(padx=100, pady=30)

root.bind('<F1>', lambda event: im.configure(data=icon2))
root.mainloop()
#####################################################################

When I start this and press F1, the icon in the Tkinter button is updated
immediately (as expected), the image in the ttk button only when I <Tab>
into the button or put the mouse pointer into the widget.
The system here is debian squeeze, Tk-8.5.8 . 

Can anyone confirm this behavior, and is there any known workaround?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

After a time, you may find that "having" is not so pleasing a thing,
after all, as "wanting."  It is not logical, but it is often true.
		-- Spock, "Amok Time", stardate 3372.7

From klappnase at web.de  Fri Mar  8 17:43:34 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 17:43:34 +0100
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <CAKypQnyHbAdpfeAKAr5rG++LPEeJXRgjQueSCHK8+RK4xFdxxw@mail.gmail.com>
References: <khbth8$226$1@ger.gmane.org>
	<CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
	<loom.20130308T171525-501@post.gmane.org>
	<CAKypQnyHbAdpfeAKAr5rG++LPEeJXRgjQueSCHK8+RK4xFdxxw@mail.gmail.com>
Message-ID: <20130308174334.bb21899d.klappnase@web.de>

On Fri, 8 Mar 2013 10:26:10 -0600
Bryan Oakley <bryan.oakley at gmail.com> wrote:

> > I had considered this... but was concerned that it might cause some
> > confusion with widgets having similar names such as 'tk.foo()' and
> > 'ttk.foo()'.  I'll have to give it a try and see how it feels in
> > practice.
> 
> The advantage to this is that it _removes_ the confusion. With this,
> it will always be clear which foo() you're working with.

and if the similarity between 'tk.foo()' and 'ttk.foo()' still looks
confusing for you, you could simply do 

import Tkinter

instead of 

import Tkinter as tk

and you have "Tkinter.foo()" which can hardly be confused with "ttk.foo()"
(in fact I personally prefer the latter, because "import Tkinter as tk"
leaves us with a "tk" module alias that resembles too close (for my
taste) the Tkinter widget's "tk" attribute.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There's nothing disgusting about it [the Companion].  It's just another
life form, that's all.  You get used to those things.
		-- McCoy, "Metamorphosis", stardate 3219.8

From bob at passcal.nmt.edu  Fri Mar  8 18:24:33 2013
From: bob at passcal.nmt.edu (Bob Greschke)
Date: Fri, 8 Mar 2013 10:24:33 -0700
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
In-Reply-To: <20130308175226.5d738f2a.klappnase@web.de>
References: <20130308175226.5d738f2a.klappnase@web.de>
Message-ID: <255EB996-F80C-4930-A57E-AF430B9BB661@passcal.nmt.edu>

Happens on

Python 2.7.2 (default, Jul 18 2011, 14:33:20) 
[GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2
TclVersion 8.5  TkVersion 8.5
with the program running on the above and the output being X'ed to an OSX Mountain Lion iMac.

I just have to mouse over the ttk button and it changes (even if, for example, Mail.app has the display focus).  When I mouse over the buttons they get slightly lighter color while the cursor is on them (the 'activebackground' color?)

Same with

Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
>>> import Tkinter
>>> Tkinter.TclVersion
8.5
>>> Tkinter.TkVersion
8.5

on my iMac.  Just running the mouse cursor over the button makes it change.  No activebackground color change on Mac.

Bob


>>> 

On 2013-03-08, at 09:52, Michael Lange <klappnase at web.de> wrote:

> Hi,
> 
> I noticed that image data in ttk widgets seem to be updated only when the
> widget receives keyboard focus or the mouse pointer enters the widget.
> A simple example of what I mean:
> 
> #####################################################################
> import Tkinter
> import ttk
> 
> icon1 = ('R0lGODlhFQANAMIAAJaWlu/v7////wAAAP///////////////yH5BAEAAA'
>            'QALAAAAAAVAA0AAANACLqsQTDCRsOTUYnNucUZIAwDRwofSGhk2aIXq'
>            'I1tCauruL1bKus1mw/DOr2GkqKphAx1ns0JwEKtRlfWbAyTAAA7')
> icon2 = ('R0lGODlhFQANAKEAAJaWlu/v7////////yH5BAEAAAMALAAAAAAVAA0AAA'
>            'IyhI8Ww80Jw3LNiIuxpBXkv3GD9WkTR5ZCiHrqelJpycquWjszGOs33'
>            'etIhsRcpYgMMgoAOw==')
> 
> root = Tkinter.Tk()
> im = Tkinter.PhotoImage(data=icon1)
> 
> b = ttk.Button(image=im, text='ttk.Button', compound='left')
> b.pack(padx=100, pady=30)
> b2 = Tkinter.Button(image=im, text='Tkinter.Button', compound='left')
> b2.pack(padx=100, pady=30)
> 
> root.bind('<F1>', lambda event: im.configure(data=icon2))
> root.mainloop()
> #####################################################################
> 
> When I start this and press F1, the icon in the Tkinter button is updated
> immediately (as expected), the image in the ttk button only when I <Tab>
> into the button or put the mouse pointer into the widget.
> The system here is debian squeeze, Tk-8.5.8 . 
> 
> Can anyone confirm this behavior, and is there any known workaround?
> 
> Regards
> 
> Michael
> 
> 
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
> 
> After a time, you may find that "having" is not so pleasing a thing,
> after all, as "wanting."  It is not logical, but it is often true.
> 		-- Spock, "Amok Time", stardate 3372.7
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
> 


From klappnase at web.de  Fri Mar  8 19:02:20 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 19:02:20 +0100
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
In-Reply-To: <255EB996-F80C-4930-A57E-AF430B9BB661@passcal.nmt.edu>
References: <20130308175226.5d738f2a.klappnase@web.de>
	<255EB996-F80C-4930-A57E-AF430B9BB661@passcal.nmt.edu>
Message-ID: <20130308190220.ab9bce2a.klappnase@web.de>

On Fri, 8 Mar 2013 10:24:33 -0700
Bob Greschke <bob at passcal.nmt.edu> wrote:

> Happens on
> 
> Python 2.7.2 (default, Jul 18 2011, 14:33:20) 
> [GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2
> TclVersion 8.5  TkVersion 8.5
> with the program running on the above and the output being X'ed to an
> OSX Mountain Lion iMac.
> 
(...)
> Same with
> 
> Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
> [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on
> darwin
> >>> import Tkinter
> >>> Tkinter.TclVersion
> 8.5
> >>> Tkinter.TkVersion
> 8.5

Ok, then it is at least not a bug specific for my version of Tk.

Experimenting a little I just found that it is possible to update the
image programatically if I force tk to redraw the button e.g. with this
modification of my example:

def test(event=None):
    im.configure(data=icon2)
    b.config(state=b['state'])

root.bind('<F1>', test)

It also works with b.config(image=b['image']) or
b.config(text=b['text']). Hmmm...

Another try, I changed my example callback into:

s = ttk.Style()
def test(event=None):
    im.configure(data=icon2)
    s.theme_use(s.theme_use())

root.bind('<F1>', test)

Here this works too, and this one might actually be usable!
Can you confirm that this does the trick?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
		-- Spock, "Assignment: Earth", stardate unknown

From bob at passcal.nmt.edu  Fri Mar  8 19:12:50 2013
From: bob at passcal.nmt.edu (Bob Greschke)
Date: Fri, 8 Mar 2013 11:12:50 -0700
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
In-Reply-To: <20130308190220.ab9bce2a.klappnase@web.de>
References: <20130308175226.5d738f2a.klappnase@web.de>
	<255EB996-F80C-4930-A57E-AF430B9BB661@passcal.nmt.edu>
	<20130308190220.ab9bce2a.klappnase@web.de>
Message-ID: <A8C32D0A-5CE7-40DA-BE8E-DF065B083696@passcal.nmt.edu>

>On 2013-03-08, at 11:02, Michael Lange <klappnase at web.de> wrote:

> On Fri, 8 Mar 2013 10:24:33 -0700
> Bob Greschke <bob at passcal.nmt.edu> wrote:
> 
>> Happens on
>> 
>> Python 2.7.2 (default, Jul 18 2011, 14:33:20) 
>> [GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2
>> TclVersion 8.5  TkVersion 8.5
>> with the program running on the above and the output being X'ed to an
>> OSX Mountain Lion iMac.
>> 
> (...)
>> Same with
>> 
>> Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
>> [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on
>> darwin
>>>>> import Tkinter
>>>>> Tkinter.TclVersion
>> 8.5
>>>>> Tkinter.TkVersion
>> 8.5
> 
> Ok, then it is at least not a bug specific for my version of Tk.
> 
> Experimenting a little I just found that it is possible to update the
> image programatically if I force tk to redraw the button e.g. with this
> modification of my example:
> 
> def test(event=None):
>    im.configure(data=icon2)
>    b.config(state=b['state'])
> 
> root.bind('<F1>', test)
> 
> It also works with b.config(image=b['image']) or
> b.config(text=b['text']). Hmmm...
> 
> Another try, I changed my example callback into:
> 
> s = ttk.Style()
> def test(event=None):
>    im.configure(data=icon2)
>    s.theme_use(s.theme_use())
> 
> root.bind('<F1>', test)
> 
> Here this works too, and this one might actually be usable!
> Can you confirm that this does the trick?

Yup.  The "Another try" works here on both systems.

Bob



From klappnase at web.de  Fri Mar  8 20:31:48 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 20:31:48 +0100
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
In-Reply-To: <A8C32D0A-5CE7-40DA-BE8E-DF065B083696@passcal.nmt.edu>
References: <20130308175226.5d738f2a.klappnase@web.de>
	<255EB996-F80C-4930-A57E-AF430B9BB661@passcal.nmt.edu>
	<20130308190220.ab9bce2a.klappnase@web.de>
	<A8C32D0A-5CE7-40DA-BE8E-DF065B083696@passcal.nmt.edu>
Message-ID: <20130308203148.5916f43d.klappnase@web.de>

On Fri, 8 Mar 2013 11:12:50 -0700
Bob Greschke <bob at passcal.nmt.edu> wrote:

> Yup.  The "Another try" works here on both systems.

Cool, then there seems to be at last a usable way to bring my playing
around with switchable icon themes to a successful end.

Regards

Michael



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

I realize that command does have its fascination, even under
circumstances such as these, but I neither enjoy the idea of command
nor am I frightened of it.  It simply exists, and I will do whatever
logically needs to be done.
		-- Spock, "The Galileo Seven", stardate 2812.7

From emilianogavilan at gmail.com  Fri Mar  8 20:50:33 2013
From: emilianogavilan at gmail.com (Emiliano Gavilan)
Date: Fri, 8 Mar 2013 16:50:33 -0300
Subject: [Tkinter-discuss] Lazy updating of image data in ttk widgets
In-Reply-To: <20130308175226.5d738f2a.klappnase@web.de>
References: <20130308175226.5d738f2a.klappnase@web.de>
Message-ID: <CAKmRqbZY+dsK9R71GmPwOmw5aPw9CfVjRi1ZatRL2ZRAXH++fA@mail.gmail.com>

2013/3/8 Michael Lange <klappnase at web.de>:
> Hi,
>
> I noticed that image data in ttk widgets seem to be updated only when the
> widget receives keyboard focus or the mouse pointer enters the widget.
> A simple example of what I mean:


This is Tk bug #3462273
(http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3462273&group_id=12997)

The workaround is to force the widget redraw. For example, sending an
<Expose> event.

Regards
Emiliano

From john at nmt.edu  Fri Mar  8 20:23:34 2013
From: john at nmt.edu (John W. Shipman)
Date: Fri, 8 Mar 2013 12:23:34 -0700 (MST)
Subject: [Tkinter-discuss] confused on grid positioning vs. imports
In-Reply-To: <CAKypQnyHbAdpfeAKAr5rG++LPEeJXRgjQueSCHK8+RK4xFdxxw@mail.gmail.com>
References: <khbth8$226$1@ger.gmane.org>
	<CAKypQnz26=+tHr4BxwpFdK9uja7j8SPN0mVoKToXX2VBTMnFcg@mail.gmail.com>
	<loom.20130308T171525-501@post.gmane.org>
	<CAKypQnyHbAdpfeAKAr5rG++LPEeJXRgjQueSCHK8+RK4xFdxxw@mail.gmail.com>
Message-ID: <alpine.LFD.2.03.1303081158020.13506@nmt.edu>

It's only been a few months since we released an updated Tkinter
8.5 Quick Reference (now with ttk widgets):

     http://www.nmt.edu/tcc/help/pubs/tkinter/

Please update your links if you are working from the old pre-ttk
version.  The older one was approaching ten years of age, and
much has changed in the new version.

With respect to the ongoing thread about how we should import the
Tkinter modules, this new reference guide now recommends what I
like to call "safe namespace hygiene".  Matters of style are and
should be both quite important and quite personal.  I'm not
trying to dictate anyone else's style, just to explain what I
need out of a style and how a given style delivers that.

I think that the type of import you use depends on whether you
are writing a serious production application or whether you're
still trying things out.

For example, the 'pylab' package dumps a bunch of names from four
or five plotting modules into your namespace using the 'from ...
import *' form of import.  But pylab is not for production
applications; it's for working scientists and engineers who just
want to get a look at their data.  Sandro Tosi's recent
"Matplotlib for Python developers" makes this point beautifully:
once you have some plots that are starting to look decent, in
your production applications that build publication-quality
graphics, you'll want to keep the namespaces separate, so you
know that np.x comes from numpy, mpl.y comes from matplotlib, and
so forth.

The recommended form of import in our little 160-page "pocket
guide":

     import Tkinter as tk
     import ttk

For the few widgets (e.g., Button) that exist in both packages,
you'll specify tk.Button or ttk.Button depending on whether
you're using the ttk styling system or not.  For the great
majority of bits that are shared by both packages, such as
alignment and anchor options, use tk, e.g., "tk.RIGHT".

My general policy is that the 'from ... import *' form is okay
for just playing around or cases where you use only one module.
But if you're using one or more of the monster modules like
Tkinter or matplotlib, with scores or hundreds of names in a
single scope, I find that safe namespace hygiene is the only way
to go.  You can keep your prefixes short with constructs like
'import ... as tk'.  The payoff is that when you or another
developer are trying to figure out where a particular function or
class comes from, deep inside a larger system.

I'd like to address a specific point in this thread.

On Fri, 8 Mar 2013, Bryan Oakley wrote (I hope I have this
attribution straight):

+--
| Personally I'm in favor of never using the constants; I see no value
| in them. These things truly are constants in the underlying tk
| plumbing, so you can just use the literal string "both', "n", etc
| rather than the constants. There's simply no need to use a constant
| named BOTH when you can use "both".  Plus, isn't "nsew" better than
| N+S+E+W?
+--

Indeed, if you use naked literals, there is zero risk that the
underlying package will change the semantics of the sticky option
and break your program.

The point is that if you're trying to understand some nontrivial
application and you see the string "s", it may not be immediately
clear why that value and not some other value.  A reference to
tk.S immediately tells you that this is some constant (because
it's in all caps) and that it is connected with the tk module.

Now, in the specific example you gave, yes, the Tkinter context is
pretty clear.  However my rule that all constants must be given
symbolic names is a general rule of my work, and I never even
consider breaking it in such cases just because someone might
consider it an unnecessary clarification.  In my experience,
over-clarification is pretty rare.

In my standard personal style, the overall outline of any
nontrivial Python script is like this:

1. #!/usr/bin/env python[3]
2. Block comment explaining what the script does and pointing
    to the documentation
3. Imports
4. Manifest constants of the form

       SOME_NAME = some_value

5. main() and its subfunctions in preorder
6. helper classes
7. Epilogue:

       if __name__ == '__main__':
           main()

Sometimes I'll put manifest constants inside a helper class but
only if they're not referenced outside the class.

Let me reiterate that style is an intensely personal choice, and
it depends on what works for you.

In any case, I have greatly enjoyed this thread.  All good
points.

Best regards,
John Shipman (john at nmt.edu), Applications Specialist
New Mexico Tech Computer Center, Speare 146, Socorro, NM 87801
(575) 835-5735, http://www.nmt.edu/~john
   ``Let's go outside and commiserate with nature.''  --Dave Farber

From klappnase at web.de  Fri Mar  8 23:27:25 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 8 Mar 2013 23:27:25 +0100
Subject: [Tkinter-discuss] Detecting third-party ttk themes
Message-ID: <20130308232725.63888048.klappnase@web.de>

Hi,

does any one know of a way to make ttk auto-detect third-party themes
(like the ones from the tile-themes project at
http://tktable.cvs.sourceforge.net/viewvc/tktable/tile-themes/ )?

Here I installed these (as I thought) properly on my system (debian
linux); "installed" means that I copied the whole tile-themes folder
to /usr/lib, and added a pkgIndex.tcl file that contains the following
two lines:

set themesdir [file join [pwd] [file dirname [info script]]]
lappend auto_path $themesdir

This works at least partially, but ttk now shows the following odd
behavior:

>>> import Tkinter, ttk
>>> root = Tkinter.Tk()
>>> s = ttk.Style()
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('classic', 'default', 'clam', 'alt')
>>> s.theme_use('winxpblue')
>>> s.theme_names()
('clam', 'alt', 'default', 'winxpblue', 'classic')
>>> root.tk.call('ttk::themes')
('keramik', 'plastik', 'clam', 'winxpblue', 'alt', 'Aquativo', 'classic',
'default', 'keramik_alt')
>>> 

Apparently here ttk::themes works better than theme_names(), although for
some reason it is not in ttk.py, but both fail to find the extra themes
before one is loaded for the first time.

Has any one an idea, is there a way to change the pkgIndex.tcl file so
that ttk will find the themes automagically or isn't this possible at all?

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Sometimes a man will tell his bartender things he'll never tell his
doctor.
		-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
		   stardate unknown.

From klappnase at web.de  Sun Mar 10 15:15:14 2013
From: klappnase at web.de (Michael Lange)
Date: Sun, 10 Mar 2013 15:15:14 +0100
Subject: [Tkinter-discuss] Detecting third-party ttk themes
In-Reply-To: <20130308232725.63888048.klappnase@web.de>
References: <20130308232725.63888048.klappnase@web.de>
Message-ID: <20130310151514.b70aa97d.klappnase@web.de>

On Fri, 8 Mar 2013 23:27:25 +0100
Michael Lange <klappnase at web.de> wrote:

> Has any one an idea, is there a way to change the pkgIndex.tcl file so
> that ttk will find the themes automagically or isn't this possible at
> all?

It is hard to find any docs a tcl-illiterate as me can use, so I made
some further experiments. First I added a third line to the tile-themes
pkgIndex.tcl file:

set themesdir [file join [pwd] [file dirname [info script]]]
lappend auto_path $themesdir
package provide tile-themes 0.6

Now I can do:

>>> import Tkinter, ttk
>>> root = Tkinter.Tk()
>>> s = ttk.Style()
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('classic', 'default', 'clam', 'alt')
>>> root.tk.call('package', 'require', 'tile-themes')
'0.6'
>>> s.theme_names()
('clam', 'alt', 'default', 'classic')
>>> root.tk.call('ttk::themes')
('keramik', 'plastik', 'clam', 'winxpblue', 'alt', 'Aquativo', 'classic',
'default', 'keramik_alt')
>>> 

which apears to be a step in the right direction. But why does
theme_names() still fail to find the themes?
Then I tried some more with the pkgIndex.tcl :

set themesdir [file join [pwd] [file dirname [info script]]]
lappend auto_path $themesdir
package provide tile-themes 0.6
source [file join $themesdir plastik plastik.tcl]

and actually:

root = Tkinter.Tk()
>>> root.tk.call('package', 'require', 'tile-themes')
'0.6'
>>> s = ttk.Style()
>>> s.theme_names()
('plastik', 'clam', 'alt', 'default', 'classic')
>>> 

However when trying to source the other theme files as I did with
plastik.tcl inside the pkgIndex.tcl I get strange errors:

>>> root.tk.call('package', 'require', 'tile-themes')
error reading package index file /usr/lib/tile-themes/pkgIndex.tcl: too
many nested evaluations (infinite loop?) error reading package index
file /usr/share/tcltk/tk8.3/pkgIndex.tcl: too many nested evaluations
(infinite loop?) error reading package index
file /usr/lib/tile-themes/pkgIndex.tcl: too many nested evaluations
(infinite loop?) error reading package index
file /usr/lib/tile-themes/pkgIndex.tcl: Theme Aquativo already exists
error reading package index file /usr/lib/tile-themes/pkgIndex.tcl: Theme
Aquativo already exists error reading package index
file /usr/lib/tile-themes/pkgIndex.tcl: Theme Aquativo already exists
(...)

where the amount of errors heavily depends on the order in which
the theme files are sourced.
I don't have an idea what's wrong here, but it seems like the first
solution is the best for now.
I think maybe I should file a bug report / patch to ad the missing
'ttk::themes' to ttk.py .

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Landru! Guide us!
		-- A Beta 3-oid, "The Return of the Archons", stardate
		   3157.4

From jepler at unpythonic.net  Mon Mar 11 02:55:46 2013
From: jepler at unpythonic.net (Jeff Epler)
Date: Sun, 10 Mar 2013 20:55:46 -0500
Subject: [Tkinter-discuss] Detecting third-party ttk themes
In-Reply-To: <20130310151514.b70aa97d.klappnase@web.de>
References: <20130308232725.63888048.klappnase@web.de>
	<20130310151514.b70aa97d.klappnase@web.de>
Message-ID: <20130311015545.GA7105@unpythonic.net>

ttk.Style.theme_names is using [ttk::style theme names].  This
enumerates the table of loaded themes only (ones that already exist in
the interpreter).

[ttk::themes] uses a different method: it searches [package names] for
loaded or available, but as far as I can tell there's no way to know
you've got the full list of [package names]!  For instance, I can get
several different combinations of values:

$ tclsh8.5
% package names
tcl::tommath Tcl
% package require xyzzy
can't find package xyzzy
% package names
http tcl::tommath ttk::theme::keramik_alt BLT opt tcltest ttk::theme::plastik BWidget msgcat tclreadline Expect ttk::theme::keramik Tcl platform Togl tile Tk
% package require ttk::theme::plastik
0.6.2
% package names
ttk::theme::classic http tcl::tommath ttk::theme::keramik_alt BLT Ttk ttk::theme::default opt tcltest ttk::theme::plastik BWidget msgcat tclreadline Expect ttk::theme::keramik ttk::theme::clam Tcl platform Togl tile ttk::theme::alt Tk

so I think the pattern would have to be:
 * do a dummy [package require impossible-package-name] to ensure that
   anything directly named in a pkgIndex.tcl gets pulled in
   (you'll either need a Tcl catch or a Python try/except around this)

 * do a [package require tile-themes] in case that package is installed
   (you'll either need a Tcl catch or a Python try/except around this)

 * and then prefer [ttk::themes] to ttk.Style().theme_names()

since I didn't observe any circumstance in which [ttk::themes] listed
fewer themes than [ttk::style theme names], I wonder whether that isn't
a candidate for a python bugreport for ttk.py.

After all these years I remain utterly bewildered at Tcl's system for
packages, particularly as compared to how straightforward Python's
are...

Jeff

From klappnase at web.de  Mon Mar 11 19:30:57 2013
From: klappnase at web.de (Michael Lange)
Date: Mon, 11 Mar 2013 19:30:57 +0100
Subject: [Tkinter-discuss] Detecting third-party ttk themes
In-Reply-To: <20130311015545.GA7105@unpythonic.net>
References: <20130308232725.63888048.klappnase@web.de>
	<20130310151514.b70aa97d.klappnase@web.de>
	<20130311015545.GA7105@unpythonic.net>
Message-ID: <20130311193057.f9979a1d.klappnase@web.de>

On Sun, 10 Mar 2013 20:55:46 -0500
Jeff Epler <jepler at unpythonic.net> wrote:

(...)
> so I think the pattern would have to be:
>  * do a dummy [package require impossible-package-name] to ensure that
>    anything directly named in a pkgIndex.tcl gets pulled in
>    (you'll either need a Tcl catch or a Python try/except around this)
> 
>  * do a [package require tile-themes] in case that package is installed
>    (you'll either need a Tcl catch or a Python try/except around this)
> 
>  * and then prefer [ttk::themes] to ttk.Style().theme_names()
> 

thanks for the explanation.
The strange thing here is that it seems like the first approach is better,
considering that there might be other theme packages we do not know about.
In fact this appears to come close to the "auto-magic" I have been
looking for.

> since I didn't observe any circumstance in which [ttk::themes] listed
> fewer themes than [ttk::style theme names], I wonder whether that isn't
> a candidate for a python bugreport for ttk.py.

I think so too, I filed a report at http://bugs.python.org/issue17397 .

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

The heart is not a logical organ.
		-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

From steven.r.glasgow.civ at mail.mil  Fri Mar 29 16:38:03 2013
From: steven.r.glasgow.civ at mail.mil (Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US))
Date: Fri, 29 Mar 2013 15:38:03 +0000
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
Message-ID: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>

Classification: UNCLASSIFIED
Caveats: NONE

I'm currently having problems using viewVC which depends on both python and Tkinter.

I was hoping anyone could tell me why I'm getting the following set of messages from the "viewvc/bin/standalone.py -g -r $CVSROOT" command.  I'm using version 1.1.18 of viewVC, and 2.6.6 of python...Not sure how to find the version of Tkinter I'm using.  We are in the process of upgrading from RHEL 5.4 to RHEL 6.3.  Everything works just fine on RHEL 5.4 but not RHEL 6.3.  In addition to the following messages, the ViewVC standalone window comes up, but always says "starting server" and the open browser button is never activated.

Here are the messages:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.?6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.?6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 421, in serve
    ViewVCHTTPServer(host, port, callback).serve_until_quit()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 349, in __init__
    BaseHTTPServer.HTTPS?erver.__init__(self,? self.address, self.handler)
  File "/usr/lib64/python2.?6/SocketServer.py", line 403, in __init__
    self.server_activate()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 361, in server_activate
    self.callback(self)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?-18/bin/standalone.p?y", line 671, in ready
    self.title_lbl.confi?g(text='ViewVC standalone server at\n' + server.url)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1202, in configure
    return self._configure('configure', cnf, kw)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1193, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: out of stack space (infinite loop?)

I first tried getting support from the viewVC community, but were told, "Looks like a problem in the Tcl/TK Python bindings."  They thought I might want to raise my issue with the community that maintains those bindings and that maybe someone there might quickly recognize the problem and give me (or the viewVC community) immediate feedback on a solution.

Any help would be appreciated.

Thank you,
Steve



Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5640 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130329/a009f407/attachment.bin>

From steven.r.glasgow.civ at mail.mil  Fri Mar 29 16:41:31 2013
From: steven.r.glasgow.civ at mail.mil (Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US))
Date: Fri, 29 Mar 2013 15:41:31 +0000
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
Message-ID: <6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>

Classification: UNCLASSIFIED
Caveats: NONE

When I said, "Everything works fine on RHEL 5.4...", that is with python version 2.4.3 and viewVC 1.1.18.

Thanks,
Steve


-----Original Message-----
From: Tkinter-discuss [mailto:tkinter-discuss-bounces+steven.r.glasgow.civ=mail.mil at python.org] On Behalf Of Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)
Sent: Friday, March 29, 2013 10:38 AM
To: tkinter-discuss at python.org
Cc: Gach, Terrence J CIV (US)
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm currently having problems using viewVC which depends on both python and Tkinter.

I was hoping anyone could tell me why I'm getting the following set of messages from the "viewvc/bin/standalone.py -g -r $CVSROOT" command.  I'm using version 1.1.18 of viewVC, and 2.6.6 of python...Not sure how to find the version of Tkinter I'm using.  We are in the process of upgrading from RHEL 5.4 to RHEL 6.3.  Everything works just fine on RHEL 5.4 but not RHEL 6.3.  In addition to the following messages, the ViewVC standalone window comes up, but always says "starting server" and the open browser button is never activated.

Here are the messages:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.?6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.?6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 421, in serve
    ViewVCHTTPServer(host, port, callback).serve_until_quit()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 349, in __init__
    BaseHTTPServer.HTTPS?erver.__init__(self,? self.address, self.handler)
  File "/usr/lib64/python2.?6/SocketServer.py", line 403, in __init__
    self.server_activate()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 361, in server_activate
    self.callback(self)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?-18/bin/standalone.p?y", line 671, in ready
    self.title_lbl.confi?g(text='ViewVC standalone server at\n' + server.url)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1202, in configure
    return self._configure('configure', cnf, kw)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1193, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: out of stack space (infinite loop?)

I first tried getting support from the viewVC community, but were told, "Looks like a problem in the Tcl/TK Python bindings."  They thought I might want to raise my issue with the community that maintains those bindings and that maybe someone there might quickly recognize the problem and give me (or the viewVC community) immediate feedback on a solution.

Any help would be appreciated.

Thank you,
Steve



Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5640 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130329/e6f26639/attachment.bin>

From steven.r.glasgow.civ at mail.mil  Fri Mar 29 17:01:46 2013
From: steven.r.glasgow.civ at mail.mil (Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US))
Date: Fri, 29 Mar 2013 16:01:46 +0000
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
Message-ID: <6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>

Classification: UNCLASSIFIED
Caveats: NONE

The versions of Tkinter I'm working with are (from rpm -qa):

RHEL 5.4 ---> 2.4.3-27.el5
THEL 6.3 ---> 2.6.6-36.el6.x86_64

Any help will be greatly appreciated,
Steve


-----Original Message-----
From: Tkinter-discuss [mailto:tkinter-discuss-bounces+steven.r.glasgow.civ=mail.mil at python.org] On Behalf Of Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)
Sent: Friday, March 29, 2013 10:42 AM
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

When I said, "Everything works fine on RHEL 5.4...", that is with python version 2.4.3 and viewVC 1.1.18.

Thanks,
Steve


-----Original Message-----
From: Tkinter-discuss [mailto:tkinter-discuss-bounces+steven.r.glasgow.civ=mail.mil at python.org] On Behalf Of Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)
Sent: Friday, March 29, 2013 10:38 AM
To: tkinter-discuss at python.org
Cc: Gach, Terrence J CIV (US)
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

I'm currently having problems using viewVC which depends on both python and Tkinter.

I was hoping anyone could tell me why I'm getting the following set of messages from the "viewvc/bin/standalone.py -g -r $CVSROOT" command.  I'm using version 1.1.18 of viewVC, and 2.6.6 of python...Not sure how to find the version of Tkinter I'm using.  We are in the process of upgrading from RHEL 5.4 to RHEL 6.3.  Everything works just fine on RHEL 5.4 but not RHEL 6.3.  In addition to the following messages, the ViewVC standalone window comes up, but always says "starting server" and the open browser button is never activated.

Here are the messages:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.?6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.?6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 421, in serve
    ViewVCHTTPServer(host, port, callback).serve_until_quit()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 349, in __init__
    BaseHTTPServer.HTTPS?erver.__init__(self,? self.address, self.handler)
  File "/usr/lib64/python2.?6/SocketServer.py", line 403, in __init__
    self.server_activate()
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 361, in server_activate
    self.callback(self)
  File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?-18/bin/standalone.p?y", line 671, in ready
    self.title_lbl.confi?g(text='ViewVC standalone server at\n' + server.url)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1202, in configure
    return self._configure('configure', cnf, kw)
  File "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1193, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: out of stack space (infinite loop?)

I first tried getting support from the viewVC community, but were told, "Looks like a problem in the Tcl/TK Python bindings."  They thought I might want to raise my issue with the community that maintains those bindings and that maybe someone there might quickly recognize the problem and give me (or the viewVC community) immediate feedback on a solution.

Any help would be appreciated.

Thank you,
Steve



Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5640 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130329/6305fd43/attachment-0001.bin>

From klappnase at web.de  Fri Mar 29 20:48:07 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 29 Mar 2013 20:48:07 +0100
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>
Message-ID: <20130329204807.99f05ded.klappnase@web.de>

Hi,

On Fri, 29 Mar 2013 16:01:46 +0000
"Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)"
<steven.r.glasgow.civ at mail.mil> wrote:

(...)
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.?6/threading.py", line 532, in
> __bootstrap_inner self.run()
>   File "/usr/lib64/python2.?6/threading.py", line 484, in run
>     self.__target(*self.__args, **self.__kwargs)
>   File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?
> y", line 421, in serve ViewVCHTTPServer(host, port,
> callback).serve_until_quit() File "/awars2a/Applicatio?
> ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 349, in __init__
> BaseHTTPServer.HTTPS?erver.__init__(self,? self.address, self.handler)
> File "/usr/lib64/python2.?6/SocketServer.py", line 403, in __init__
> self.server_activate() File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?
> .18/bin/standalone.p?y", line 361, in server_activate self.callback
> (self) File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?
> -18/bin/standalone.p?y", line 671, in ready self.title_lbl.confi?g
> (text='ViewVC standalone server at\n' + server.url) File
> "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1202, in configure
> return self._configure('configure', cnf, kw) File "/usr/lib64/python2.?
> 6/lib-tk/Tkinter.py"?, line 1193, in _configure self.tk.call(_flatten
> ((self._w, cmd)) + self._options(cnf)) TclError: out of stack space
> (infinite loop?)
> 
> I first tried getting support from the viewVC community, but were told,
> "Looks like a problem in the Tcl/TK Python bindings."  They thought I
> might want to raise my issue with the community that maintains those
> bindings and that maybe someone there might quickly recognize the
> problem and give me (or the viewVC community) immediate feedback on a
> solution.

I haven't looked deeply into this, but several sources suggest that this
error might be caused by a Tk that is compiled without thread support.
You can check if the Tk your Tkinter uses supports threads with:

    $ python
    Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
    [GCC 4.4.5] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from Tkinter import *
    >>> root = Tk()
    >>> root.tk.call('info', 'exists', 'tcl_platform(threaded)')
    1
    >>> 

Apparently, if this call returns 0 instead, threads are not suported.

I also found the following example:
http://stackoverflow.com/questions/14521319/tkinter-threads-exception-out-of-stack-space-infinite-loop
where the same error message was caused by a buggy implementation of
threads in a Tkinter app (they tried to call mainloop() from a child
thread there, which is certainly a bad idea ;) , so from the little I
know I would not bet my savings that the app in question is innocent
either; maybe you can look through their code, in case the application is
not too complex, to make sure that none of the program's child threads
does touch Tk (something that should be avoided at any rate because
it will make the app behave more or less unpredictable)?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Violence in reality is quite different from theory.
		-- Spock, "The Cloud Minders", stardate 5818.4

From steven.r.glasgow.civ at mail.mil  Fri Mar 29 21:38:31 2013
From: steven.r.glasgow.civ at mail.mil (Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US))
Date: Fri, 29 Mar 2013 20:38:31 +0000
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <20130329204807.99f05ded.klappnase@web.de>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>
	<20130329204807.99f05ded.klappnase@web.de>
Message-ID: <6132691E064DAC49B214555A634702745EA54B12@UTINHPZV.easf.csd.disa.mil>

Classification: UNCLASSIFIED
Caveats: NONE

Thank you for the reply.  In fact, my Tk does NOT have thread support (great example you provided on how to find out).  As I'm not the one that installs applications, I'll need to sound a little intelligent to our IT department to get them to do it correctly.  When Tkinter is installed is there an option provided that allows thread support to be added (or not)?  What do I need to tell them to do to get me the thread support that I need?

Also, don't know if this has anything to do with it or not...  When this RHEL 6.3 machine was initially built it only had 64-bit libraries, the 32-bit ones were added later.  I believe Tkinter was installed before the 32-bit libraries were added.  Could this be an issue, if viewVC requires 32-bit?  Should we just reinstall Tkinter?

I'm a software engineer, but work exclusively in c++ and java.  I know nothing about python.

Thank you for any help you can give me,
Steve

-----Original Message-----
From: Tkinter-discuss [mailto:tkinter-discuss-bounces+steven.r.glasgow.civ=mail.mil at python.org] On Behalf Of Michael Lange
Sent: Friday, March 29, 2013 2:48 PM
To: tkinter-discuss at python.org
Subject: Re: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)

Hi,

On Fri, 29 Mar 2013 16:01:46 +0000
"Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)"
<steven.r.glasgow.civ at mail.mil> wrote:

(...)
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.?6/threading.py", line 532, in 
> __bootstrap_inner self.run()
>   File "/usr/lib64/python2.?6/threading.py", line 484, in run
>     self.__target(*self.__args, **self.__kwargs)
>   File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?.18/bin/standalone.p?
> y", line 421, in serve ViewVCHTTPServer(host, port,
> callback).serve_until_quit() File "/awars2a/Applicatio? 
> ns/viewvc/viewvc-1.1?.18/bin/standalone.p?y", line 349, in __init__ 
> BaseHTTPServer.HTTPS?erver.__init__(self,? self.address, self.handler) 
> File "/usr/lib64/python2.?6/SocketServer.py", line 403, in __init__
> self.server_activate() File "/awars2a/Applicatio?ns/viewvc/viewvc-1.1?
> .18/bin/standalone.p?y", line 361, in server_activate self.callback
> (self) File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?
> -18/bin/standalone.p?y", line 671, in ready self.title_lbl.confi?g 
> (text='ViewVC standalone server at\n' + server.url) File 
> "/usr/lib64/python2.?6/lib-tk/Tkinter.py"?, line 1202, in configure 
> return self._configure('configure', cnf, kw) File 
> "/usr/lib64/python2.? 6/lib-tk/Tkinter.py"?, line 1193, in _configure 
> self.tk.call(_flatten ((self._w, cmd)) + self._options(cnf)) TclError: 
> out of stack space (infinite loop?)
> 
> I first tried getting support from the viewVC community, but were 
> told, "Looks like a problem in the Tcl/TK Python bindings."  They 
> thought I might want to raise my issue with the community that 
> maintains those bindings and that maybe someone there might quickly 
> recognize the problem and give me (or the viewVC community) immediate 
> feedback on a solution.

I haven't looked deeply into this, but several sources suggest that this error might be caused by a Tk that is compiled without thread support.
You can check if the Tk your Tkinter uses supports threads with:

    $ python
    Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
    [GCC 4.4.5] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from Tkinter import *
    >>> root = Tk()
    >>> root.tk.call('info', 'exists', 'tcl_platform(threaded)')
    1
    >>> 

Apparently, if this call returns 0 instead, threads are not suported.

I also found the following example:
http://stackoverflow.com/questions/14521319/tkinter-threads-exception-out-of-stack-space-infinite-loop
where the same error message was caused by a buggy implementation of threads in a Tkinter app (they tried to call mainloop() from a child thread there, which is certainly a bad idea ;) , so from the little I know I would not bet my savings that the app in question is innocent either; maybe you can look through their code, in case the application is not too complex, to make sure that none of the program's child threads does touch Tk (something that should be avoided at any rate because it will make the app behave more or less unpredictable)?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Violence in reality is quite different from theory.
		-- Spock, "The Cloud Minders", stardate 5818.4 _______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss at python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss

Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5640 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130329/e1ac64a6/attachment.bin>

From klappnase at web.de  Fri Mar 29 23:27:31 2013
From: klappnase at web.de (Michael Lange)
Date: Fri, 29 Mar 2013 23:27:31 +0100
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <6132691E064DAC49B214555A634702745EA54B12@UTINHPZV.easf.csd.disa.mil>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>
	<20130329204807.99f05ded.klappnase@web.de>
	<6132691E064DAC49B214555A634702745EA54B12@UTINHPZV.easf.csd.disa.mil>
Message-ID: <20130329232731.3def88f6.klappnase@web.de>

Hi,

On Fri, 29 Mar 2013 20:38:31 +0000
"Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)"
<steven.r.glasgow.civ at mail.mil> wrote:

> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Thank you for the reply.  In fact, my Tk does NOT have thread support
> (great example you provided on how to find out).  As I'm not the one
> that installs applications, I'll need to sound a little intelligent to
> our IT department to get them to do it correctly.  When Tkinter is
> installed is there an option provided that allows thread support to be
> added (or not)?  What do I need to tell them to do to get me the thread
> support that I need?
> 
> Also, don't know if this has anything to do with it or not...  When
> this RHEL 6.3 machine was initially built it only had 64-bit libraries,
> the 32-bit ones were added later.  I believe Tkinter was installed
> before the 32-bit libraries were added.  Could this be an issue, if
> viewVC requires 32-bit?  Should we just reinstall Tkinter?

I'm afraid the procedure is not trivial, if no precompiled packages are
available for the particular system; they would have to compile tcl and tk
with --enable-threads (iirc that's the name of the ./configure option) and
then compile python against the new Tcl/Tk.

However, when I take a second glance at the traceback, in particular the
following lines:

  File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?-18/bin/standalone.p?y",
    line 671, in ready self.title_lbl.confi?g(text='ViewVC standalone
    server at\n' + server.url)

I am beginning to suspect (though I admit that I was too lazy to
thoroughly look through the code) that in fact the code is buggy as it
seems to try to change the Tkinter.Label's text from the child thread.
Even better, when I look at:
http://viewvc.tigris.org/svn/viewvc/trunk/bin/standalone.py
these lines (resp. the use of Tkinter at all) are missing, so maybe they
actually found out about the bug and fixed it.

So I guess that maybe it is the best bet to try the latest
development version of viewVC.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

War is never imperative.
		-- McCoy, "Balance of Terror", stardate 1709.2

From Cameron at phaseit.net  Sat Mar 30 21:04:19 2013
From: Cameron at phaseit.net (Cameron Laird)
Date: Sat, 30 Mar 2013 20:04:19 +0000
Subject: [Tkinter-discuss] Tcl/TK issue with viewVC (UNCLASSIFIED)
In-Reply-To: <20130329232731.3def88f6.klappnase@web.de>
References: <6132691E064DAC49B214555A634702745EA539DE@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA539F4@UTINHPZV.easf.csd.disa.mil>
	<6132691E064DAC49B214555A634702745EA53A52@UTINHPZV.easf.csd.disa.mil>
	<20130329204807.99f05ded.klappnase@web.de>
	<6132691E064DAC49B214555A634702745EA54B12@UTINHPZV.easf.csd.disa.mil>
	<20130329232731.3def88f6.klappnase@web.de>
Message-ID: <20130330200419.GA32045@lairds.us>

On Fri, Mar 29, 2013 at 11:27:31PM +0100, Michael Lange wrote:
> On Fri, 29 Mar 2013 20:38:31 +0000
> "Glasgow, Steven R CIV USARMY TRADOC ANALYSIS CTR (US)"
> <steven.r.glasgow.civ at mail.mil> wrote:
			.
			.
			.
> > Thank you for the reply.  In fact, my Tk does NOT have thread support
> > (great example you provided on how to find out).  As I'm not the one
> > that installs applications, I'll need to sound a little intelligent to
> > our IT department to get them to do it correctly.  When Tkinter is
> > installed is there an option provided that allows thread support to be
> > added (or not)?  What do I need to tell them to do to get me the thread
> > support that I need?
> > 
> > Also, don't know if this has anything to do with it or not...  When
> > this RHEL 6.3 machine was initially built it only had 64-bit libraries,
> > the 32-bit ones were added later.  I believe Tkinter was installed
> > before the 32-bit libraries were added.  Could this be an issue, if
> > viewVC requires 32-bit?  Should we just reinstall Tkinter?
> 
> I'm afraid the procedure is not trivial, if no precompiled packages are
> available for the particular system; they would have to compile tcl and tk
> with --enable-threads (iirc that's the name of the ./configure option) and
> then compile python against the new Tcl/Tk.
> 
> However, when I take a second glance at the traceback, in particular the
> following lines:
> 
>   File "/awars2a/Applicatio?ns/viewvc/viewvc-1-1?-18/bin/standalone.p?y",
>     line 671, in ready self.title_lbl.confi?g(text='ViewVC standalone
>     server at\n' + server.url)
> 
> I am beginning to suspect (though I admit that I was too lazy to
> thoroughly look through the code) that in fact the code is buggy as it
> seems to try to change the Tkinter.Label's text from the child thread.
> Even better, when I look at:
> http://viewvc.tigris.org/svn/viewvc/trunk/bin/standalone.py
> these lines (resp. the use of Tkinter at all) are missing, so maybe they
> actually found out about the bug and fixed it.
> 
> So I guess that maybe it is the best bet to try the latest
> development version of viewVC.
			.
			.
			.
I'm a little foggy what we're trying to solve.  The parts of which
I'm certain are:
*)  Michael is (as always) giving good help;
*)  installation of ActivePython might be a
    good way to cut through a lot of noise;
    and
*)  in any case, even if it's occasionally,
    arcane, getting Tkinter to work *is* a
    solved problem, even on *.mil hosts.  I'm
    sure we can be successful at this, given
    enough information and attention.

From alejandroautalan at gmail.com  Sun Mar 31 08:58:53 2013
From: alejandroautalan at gmail.com (Alejandro Autalan)
Date: Sun, 31 Mar 2013 03:58:53 -0300
Subject: [Tkinter-discuss] class_ attribute on ttk widgets
Message-ID: <CAMicNw0qP8ch_LpOVj84r5kW-pwsFzX=n3brEC5RMiBs=hXOdA@mail.gmail.com>

Hello all.

I'm reading the tkinter reference at
http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html.

It says that the 'class_' attribute is available for ttk widgets.  But when
is set, some widgets become  unresponsive.

Example:

#uname -a   Linux vostro1 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64
GNU/Linux
# Python 3.2.3
#tkinter.TkVersion 8.5

import tkinter as tk
from tkinter import ttk

f = ttk.Frame()
f.grid()
entry = ttk.Entry(f, class_='CustomEntry')
entry.grid()
btn = ttk.Button(f, class_='CustomButton', text='Button')
btn.grid()
f.mainloop()

When I run the example, I can't enter text on entry widget or click a
button.
Is this the expected behaviour? Anyone know how this attribute should be
used for ttk widgets ?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130331/369e65d8/attachment.html>

From rovitotv at gmail.com  Sun Mar 31 20:04:00 2013
From: rovitotv at gmail.com (Todd Rovito)
Date: Sun, 31 Mar 2013 14:04:00 -0400
Subject: [Tkinter-discuss] Bug with Tk Text Widget hi-lights disappear when
 text widget loses focus on Windows
Message-ID: <CALZ1apy31XJd=A5ffFRbh4DKnP4v0EiU1Pbv17LBu6htX7RfrQ@mail.gmail.com>

Greetings,
     I was looking for some guidance on a issue(s) that popped up for IDLE
on the issue tracker here:
http://bugs.python.org/issue14146

But is starting to creep into other places such as the find and replace
dialogs:
http://bugs.python.org/issue17511

Recently I tested with Tk 8.5.13 and Tk 8.6 and both have the problem.  We
created a small test program to demonstrate the issue without IDLE:

from tkinter import *

main = Tk()
text = Text(main, width=40, height=10, wrap="char")
text.pack()
text.insert(INSERT, "".join(map(str, range(100))))
text.tag_add(SEL, "1.0", "end")
text.focus_set()

def jump():
    text.after(500, btn.focus_set)
    text.after(1000, text.focus_set)

btn = Button(main, text="Click me", command=jump)
btn.pack()
main.mainloop()

This program is for Python 3.x and behaves differently on Windows when
compared to Linux or Mac.  Earlier today I filed a bug report with the Tk
folks here:

https://sourceforge.net/tracker/?func=detail&aid=3609608&group_id=12997&atid=112997

But I also wanted to post something here in case it was a tkinter
issue.  Any feedback or help would be greatly appreciated thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130331/2753893f/attachment.html>

From bryan.oakley at gmail.com  Sun Mar 31 14:41:50 2013
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Sun, 31 Mar 2013 07:41:50 -0500
Subject: [Tkinter-discuss] class_ attribute on ttk widgets
In-Reply-To: <CAMicNw0qP8ch_LpOVj84r5kW-pwsFzX=n3brEC5RMiBs=hXOdA@mail.gmail.com>
References: <CAMicNw0qP8ch_LpOVj84r5kW-pwsFzX=n3brEC5RMiBs=hXOdA@mail.gmail.com>
Message-ID: <BDF6CF75-0D44-40A7-8D6C-DB400A7EDC68@gmail.com>

It is expected behavior. The built-in key and mouse bindings are bound to the class, so if you change the class of a widget it will no longer have these bindings.

Changing the class is mostly useful if you want to create a completely different set of bindings for a widget. 

--bryan


On Mar 31, 2013, at 1:58 AM, Alejandro Autalan <alejandroautalan at gmail.com> wrote:

> Hello all.
> 
> I'm reading the tkinter reference at http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html.
> 
> It says that the 'class_' attribute is available for ttk widgets.  But when is set, some widgets become  unresponsive.
> 
> Example:
> 
> #uname -a   Linux vostro1 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux
> # Python 3.2.3
> #tkinter.TkVersion 8.5
> 
> import tkinter as tk
> from tkinter import ttk
> 
> f = ttk.Frame()
> f.grid()
> entry = ttk.Entry(f, class_='CustomEntry')
> entry.grid()
> btn = ttk.Button(f, class_='CustomButton', text='Button')
> btn.grid()
> f.mainloop()
> 
> When I run the example, I can't enter text on entry widget or click a button.
> Is this the expected behaviour? Anyone know how this attribute should be used for ttk widgets ?
> 
> Thanks.
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20130331/88e1780f/attachment.html>