From alexxx.magni at gmail.com Wed Oct 5 14:40:30 2011 From: alexxx.magni at gmail.com (Alessandro Magni) Date: Wed, 5 Oct 2011 14:40:30 +0200 Subject: [Tkinter-discuss] tag insertion while writing Message-ID: Hi everybody, I'm looking for some directions, while programming a very simple editor (supporting basic formatting) The window where the user writes is a Text widget (named: text), where I put a tag 'b' to set the text where this tag applies to bold. This is not a problem when I apply the bold to a selection: text.tag_add('b', SEL_FIRST,SEL_LAST) I have instead two problems when I just want to switch on/off the bold while typing. To switch it on the only way I found is this: text.insert(INSERT, ' ', 'b' ) text.mark_set("insert", INSERT+'-1c') notice that I have to insert TWO spaces. If I insert one, the bold doesnt apply. If I insert '', my cursor goes back one char! My second problem is how to switch it off, when I'm writing within a bolded region - and for this I havent the slightest idea... Thanks for any help! alessandro From klappnase at web.de Wed Oct 5 16:48:13 2011 From: klappnase at web.de (Michael Lange) Date: Wed, 5 Oct 2011 16:48:13 +0200 Subject: [Tkinter-discuss] tag insertion while writing In-Reply-To: References: Message-ID: <20111005164813.7c17d116.klappnase@web.de> Hi, Thus spoketh Alessandro Magni unto us on Wed, 5 Oct 2011 14:40:30 +0200: > Hi everybody, > I'm looking for some directions, while programming a very simple > editor (supporting basic formatting) > > The window where the user writes is a Text widget (named: text), where > I put a tag 'b' to set the text where this tag applies to bold. > > This is not a problem when I apply the bold to a selection: > > text.tag_add('b', SEL_FIRST,SEL_LAST) > > I have instead two problems when I just want to switch on/off the bold > while typing. To switch it on the only way I found is this: > > text.insert(INSERT, ' ', 'b' ) > text.mark_set("insert", INSERT+'-1c') > > notice that I have to insert TWO spaces. If I insert one, the bold > doesnt apply. If I insert '', my cursor goes back one char! > > My second problem is how to switch it off, when I'm writing within a > bolded region - and for this I havent the slightest idea... The following appears to work here: >>> t = Text(font='courier -12') >>> t.pack(fill='both', expand=1) >>> t.tag_configure('b', font='courier -12 bold') >>> t.tag_add('b', 'insert-1c', 'end') ... type something, it is bold... >>> t.tag_remove('b', 'insert', 'end') ... now it is normal again... except that it doesn't seem to be possible to begin editing an empty text widget with the bold font and that on tag_add() the character *before* the insertion cursor is bold'ed which looks a little odd to me. So, you have to type the first character that is supposed to be bold and then switch the font. OTOH, if you bind these commands to some key events it might be something that one can live with. Best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. The games have always strengthened us. Death becomes a familiar pattern. We don't fear it as you do. -- Proconsul Marcus Claudius, "Bread and Circuses", stardate 4041.2 From kalman_g at msn.com Wed Oct 5 18:26:28 2011 From: kalman_g at msn.com (GKalman) Date: Wed, 5 Oct 2011 09:26:28 -0700 (PDT) Subject: [Tkinter-discuss] Where is place for "Events" in an OOP script? Message-ID: <32595471.post@talk.nabble.com> I'm trying to separate the GUI and Non-GUI type classes in my script. For example: Say, I have a Spring class ( with all the non-GUI type attributes of a mechanical Spring) and a DisplayBoard class (for all the Tkinter type displays on a Canvas object). For simplicity, assume I want to drag an instance of the Spring across the Canvas. Questions: (1) Do the actions defined thru the "bindings" and associated callback-functions "belong" to the Spring class or the GUI class? (2)Should there be a separate "Actions" class that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class together? -- View this message in context: http://old.nabble.com/Where-is-place-for-%22Events%22-in-an-OOP-script--tp32595471p32595471.html Sent from the Python - tkinter-discuss mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From klappnase at web.de Wed Oct 5 18:33:07 2011 From: klappnase at web.de (Michael Lange) Date: Wed, 5 Oct 2011 18:33:07 +0200 Subject: [Tkinter-discuss] tag insertion while writing In-Reply-To: <20111005164813.7c17d116.klappnase@web.de> References: <20111005164813.7c17d116.klappnase@web.de> Message-ID: <20111005183307.f466c935.klappnase@web.de> Hi again, Thus spoketh Michael Lange unto us on Wed, 5 Oct 2011 16:48:13 +0200: (...) > The following appears to work here: > (...) I found a much better implementation here: http://wiki.tcl.tk/4018 "Translated" into python this might look like: #################### root = Tk() t = Text(root, font='courier -14') t.pack(fill='both', expand=1) t.tag_configure('b', font='courier -14 bold') def modTextInsert(event): if event.char == '' or event.widget['state'] == 'disabled': return try: if event.widget.compare('sel.first', '<=', 'insert') and \ event.widget.compare('sel.last', '>=', 'insert'): event.widget.delete('sel.first', 'sel.last') except TclError: pass event.widget.insert('insert', event.char, event.widget.tag_names('insert-1c')) event.widget.see('insert') for seq in root.bind_class('Text'): root.bind_class('modText', seq, root.bind_class('Text', seq)) root.bind_class('modText', '', modTextInsert) t.bindtags((t, 'modText', t.winfo_toplevel(), 'all')) def bold(event): t.tag_add('b', 'insert-1c') def normal(event): t.tag_remove('b', 'insert-1c') t.bind('', bold) t.bind('', normal) root.mainloop() #################### This seems to work quite well, except that the changed tag still applies to the character left to the cursor and that still the handling of <> events is missing ;) Regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown From waynejwerner at gmail.com Wed Oct 5 19:15:20 2011 From: waynejwerner at gmail.com (Wayne Werner) Date: Wed, 5 Oct 2011 12:15:20 -0500 Subject: [Tkinter-discuss] Where is place for "Events" in an OOP script? In-Reply-To: <32595471.post@talk.nabble.com> References: <32595471.post@talk.nabble.com> Message-ID: On Wed, Oct 5, 2011 at 11:26 AM, GKalman wrote: > I'm trying to separate the GUI and Non-GUI type classes in my script. *For example: > * Say, I have a Spring class ( with all the non-GUI type attributes of a > mechanical Spring) and a DisplayBoard class (for all the Tkinter type > displays on a Canvas object). For simplicity, assume I want to drag an > instance of the Spring across the Canvas. *Questions:* (1) Do the actions > defined thru the "bindings" and associated callback-functions "belong" to > the Spring class or the GUI class? (2)Should there be a separate "Actions" > class that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class > together? Helpful tip: proper formatting (spaces between lines, numbered lists on separate lines) is helpful to us when we try to read your email. To answer your questions, it depends on what pattern you're using. You might want to take a look at the Model-View-Presenter design pattern. There are several other patterns that help decouple your design, but to me this pattern sounds like it answers your questions. If you use the MVP pattern, the View would be your GUI (at least in this case). From what I understand, in the most "pure" version of MVP, the only thing the view does is display data, and pass events to the presenter. The presenter is where all the logic (i.e. "Doing stuff") happens. In your particular example, it sounds as if you have "things" that you're moving around on a "board". So from an MVP standpoint, your presenter might have a Board instance. That Board would have its dimensions and any other attributes it might need, and possibly a collection of items that are on the board. Then the View will have access to the Board via the presenter, and based on the data in the Board object and the items it contains, it will draw certain things. Then depending on how strict you want to adhere to the MVP pattern, when you click and drag an item, you might bind the MouseDown event to presenter.selectItem(x, y) - and the presenter would set its .active_item to the item at (x,y). Then you would bind the MouseMove event to presenter.move_item() that might take either an absolute x,y position or a delta-x/y. Finally, you would bind the MouseUp event to presenter.release_item() that would set the .active_item to None. The beauty of this pattern is that now you can easily plug-and-play with different views. Instead of using Tkinter, maybe you want to use PyGTK - that's fine, no real problems. Just implement the right events that call the right methods. Maybe instead you want to create a text based interface like the old RPG, so you could have something like this: > look around You see a spring. > eat spring You cannot eat spring. > touch spring Spring is hard and metallic. > grab spring You are now holding a spring. > move north You are standing in front of the door. > drop spring The spring bounces in front of you, coming to a halt. > taunt spring The spring does not respond to your taunts. And grab, move, and drop springs would simply call functions on your presenter. Or on a more serious nature, you could also write automated test cases using unittest or nose or one of the other automated test tools, which are invaluable when you want to make sure that your program works correctly. It takes a little practice to get the hang of writing code that way - Test/Behavior Driven Development helps - but the payoff of having decoupled code is quite valuable. HTH, Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Oct 6 04:10:50 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 06 Oct 2011 15:10:50 +1300 Subject: [Tkinter-discuss] Where is place for "Events" in an OOP script? In-Reply-To: <32595471.post@talk.nabble.com> References: <32595471.post@talk.nabble.com> Message-ID: <4E8D0E2A.7080804@canterbury.ac.nz> On 06/10/11 05:26, GKalman wrote: > (1) Do the actions > defined thru the "bindings" and associated callback-functions "belong" to the > Spring class or the GUI class? The functions bound directly to input events such as mouse clicks and movements should probably be part of the GUI. You will probably want to perform some processing on them before doing anything to the model, such as transforming from pixel coordinates to model space coordinates and maybe other things. > (2)Should there be a separate "Actions" class > that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class together? That's hard to answer without knowing a lot more details about the application. Use one if it helps, but don't feel obliged to include one if it doesn't seem to be adding any value. -- Greg From kevin at kevinturnercareer.com Wed Oct 12 05:08:52 2011 From: kevin at kevinturnercareer.com (Kevin Turner) Date: Tue, 11 Oct 2011 20:08:52 -0700 Subject: [Tkinter-discuss] Tkinter for Python 3.2.2 on Ubuntu Message-ID: <000a01cc888c$46defe80$d49cfb80$@kevinturnercareer.com> Hello, Can anyone point me to a version of Tkinter that I can install on a Ubuntu system? I am trying to get IDLE to work on this system using python 3.2.2 but it is complaining that I need Tkinter for it to run. I have it working on Mac and Windows 7 but I can't figure this out on my Ubuntu system. I do see a version for Python 2.x. Thanks, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From waynejwerner at gmail.com Wed Oct 12 15:13:08 2011 From: waynejwerner at gmail.com (Wayne Werner) Date: Wed, 12 Oct 2011 08:13:08 -0500 Subject: [Tkinter-discuss] Tkinter for Python 3.2.2 on Ubuntu In-Reply-To: <000a01cc888c$46defe80$d49cfb80$@kevinturnercareer.com> References: <000a01cc888c$46defe80$d49cfb80$@kevinturnercareer.com> Message-ID: On Tue, Oct 11, 2011 at 10:08 PM, Kevin Turner wrote: > Hello,**** > > Can anyone point me to a version of Tkinter that I can install on a Ubuntu > system? I am trying to get IDLE to work on this system using python 3.2.2 > but it is complaining that I need Tkinter for it to run. **** > > I have it working on Mac and Windows 7 but I can?t figure this out on my > Ubuntu system. I do see a version for Python 2.x > I believe you want the python3-tk package: http://packages.ubuntu.com/search?keywords=python3-tk You should be able to simply do $ sudo apt-get install python3-tk Presuming of course that you have the right repositories enabled. HTH, Wayne > ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strider1066 at gmail.com Thu Oct 13 19:49:30 2011 From: strider1066 at gmail.com (Steve Solomon) Date: Thu, 13 Oct 2011 10:49:30 -0700 Subject: [Tkinter-discuss] Limit to the number of canvases in a top_level object? Message-ID: Hello, Is there a limit to the number of canvases in a top_level object -- one maybe ? I have been trying to solve this problem with an application for several weeks. In the application I have two canvases, each with a grid of rectangle objects. They display perfectly but when I try to interact with the rectangles they behave anomalously. Using canvas.find_closest(event.x, event.y) the rectangles in the first drawn canvas behave normally, allowing configuring each, but within the second canvas the rectangles report back the id of only one of the rectangles and an attempt to change the fill-color of any one is applied only to the last item in the grid. Your thoughts would be appreciated, thank you Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From lionkimbro at gmail.com Thu Oct 13 21:27:36 2011 From: lionkimbro at gmail.com (Lion Kimbro) Date: Thu, 13 Oct 2011 12:27:36 -0700 Subject: [Tkinter-discuss] Limit to the number of canvases in a top_level object? In-Reply-To: References: Message-ID: Would you (or someone) attach some sample code? That would make it easier to see if we can repro. On Thu, Oct 13, 2011 at 10:49 AM, Steve Solomon wrote: > Hello, > > Is there a limit to the number of canvases in a top_level object -- one > maybe ? I have been trying to solve this problem with an application for > several weeks. In the application I have two canvases, each with a grid of > rectangle objects. They display perfectly but when I try to interact with > the rectangles they behave anomalously. Using canvas.find_closest(event.x, > event.y) the rectangles in the first drawn canvas behave normally, allowing > configuring each, but within the second canvas the rectangles report back > the id of only one of the rectangles and an attempt to change the fill-color > of any one is applied only to the last item in the grid. > > Your thoughts would be appreciated, thank you > > Steve > > _______________________________________________ > 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: From strider1066 at gmail.com Fri Oct 14 20:03:24 2011 From: strider1066 at gmail.com (Steve Solomon) Date: Fri, 14 Oct 2011 11:03:24 -0700 Subject: [Tkinter-discuss] Limit to the number of canvases in a top_level object? In-Reply-To: References: Message-ID: Hi, I'm a bit in the tall weeds, please excuse the mess (in the attached code). steve On Thu, Oct 13, 2011 at 12:27 PM, Lion Kimbro wrote: > > Would you (or someone) attach some sample code? > > That would make it easier to see if we can repro. > > > On Thu, Oct 13, 2011 at 10:49 AM, Steve Solomon wrote: > >> Hello, >> >> Is there a limit to the number of canvases in a top_level object -- one >> maybe ? I have been trying to solve this problem with an application for >> several weeks. In the application I have two canvases, each with a grid of >> rectangle objects. They display perfectly but when I try to interact with >> the rectangles they behave anomalously. Using canvas.find_closest(event.x, >> event.y) the rectangles in the first drawn canvas behave normally, allowing >> configuring each, but within the second canvas the rectangles report back >> the id of only one of the rectangles and an attempt to change the fill-color >> of any one is applied only to the last item in the grid. >> >> Your thoughts would be appreciated, thank you >> >> Steve >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: palettebuilder.py Type: application/octet-stream Size: 8128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: application/octet-stream Size: 2359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: colorservices.py Type: application/octet-stream Size: 661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: classpoint.py Type: application/octet-stream Size: 1197 bytes Desc: not available URL: From __peter__ at web.de Sun Oct 16 15:43:26 2011 From: __peter__ at web.de (Peter Otten) Date: Sun, 16 Oct 2011 15:43:26 +0200 Subject: [Tkinter-discuss] Limit to the number of canvases in a top_level object? References: Message-ID: Steve Solomon wrote: >>> Is there a limit to the number of canvases in a top_level object -- one >>> maybe ? I have been trying to solve this problem with an application for >>> several weeks. In the application I have two canvases, each with a grid >>> of rectangle objects. They display perfectly but when I try to interact >>> with the rectangles they behave anomalously. Using >>> canvas.find_closest(event.x, event.y) the rectangles in the first drawn >>> canvas behave normally, allowing configuring each, but within the second >>> canvas the rectangles report back the id of only one of the rectangles >>> and an attempt to change the fill-color of any one is applied only to >>> the last item in the grid. >>> >>> Your thoughts would be appreciated, thank you > I'm a bit in the tall weeds, please excuse the mess (in the attached > code). The best time to clean up your code is always right now; the second best time is when you run into an error ;) > from Tkinter import * > import random > import palettebuilder as pb > from colorservices import getHSV > > def randomColors(count=1, sorted=False): > "returns list of color strings in #nnnnnn hexidecimal format" > rtn = [] > for x in range(count): > intgr = random.randrange(0, 16777215, 1) > hex = "#{:0>6X}".format(intgr) > rtn.append(hex) > if sorted: > "the folowing should be sorted by ..." > # rtn.sort(key=lambda rtn: getHSV(rtn)[2]) #...value > rtn.sort(key=lambda rtn: getHSV(rtn)) #...full HSV > return rtn > > class test(Toplevel): > def __init__(self): > Toplevel.__init__(self) > self.config(height = 500, width = 500) > self.activeCanvas = None > self.bind("", self.reportXY) > size = 180 > frameOne = Frame(self, height = 200, width =200, bg = "pink") > self.canvasOne = Canvas(frameOne, height=size, width=size, background="#bababa") > self.canvasOne.grid(row = 0, column = 0, sticky = W ) > frameTwo = Frame(self, height = 200, width =200, bg="light blue") > self.canvasTwo = Canvas(frameTwo, height=size, width=size, bg='#bababa') > self.canvasTwo.grid(row = 1, column = 1) > self.canvasOne.bind("", self.makeOneActive) > self.canvasTwo.bind("", self.makeTwoActive) > frameOne.grid(row = 0, column = 0, sticky = W ) > frameTwo.grid(row = 1, column = 1, sticky = E ) > colors = randomColors(64, sorted = True) > pb.DrawPalette(self.canvasOne, colors, columns = 8) > colors = randomColors(64, sorted = True) > pb.DrawPalette(self.canvasTwo, colors, columns = 8) > > def makeOneActive(self, event): > self.activeCanvas = self.canvasOne > print "one = active self.activeCanvas>>>", type(self.activeCanvas) > > def makeTwoActive(self, event): > self.activeCanvas = self.canvasTwo > print "two = active self.activeCanvas>>>", type(self.activeCanvas) > > def reportXY(self, event): > print event.x, event.y > item=self.activeCanvas.find_closest(event.x, event.y) > print self.activeCanvas.itemcget(item, "tags"), "item>>", item > self.activeCanvas.itemconfigure(item, fill = "red") > > root = Tk() > root.withdraw() > test() > #for x in range(10): > # print randomColors(10) > # print "\n" > root.mainloop() > You bind the reportXY() method to an event triggered by your Toplevel subclass, so the event instance contains coordinates relative to the test widget. On the other hand the Canvas.find_closest() method expects coordinates in terms of the canvas widget. The difference doesn't matter for canvasOne which is located at the origin of the toplevel, but gives wrong results for canvasTwo with its non-zero offset. While the diagnosis was easy it took me a while to find a way to convert between the two coordinate systems. The following seems to work: def reportXY(self, event): canvas = self.activeCanvas dx = self.winfo_rootx() - canvas.winfo_rootx() dy = self.winfo_rooty() - canvas.winfo_rooty() x = event.x + dx y = event.y + dy print "before", event.x, event.y print "after", x, y item = canvas.find_closest(x, y) print canvas.itemcget(item, "tags"), "item>>", item canvas.itemconfigure(item, fill="red") Let me know if you find a better way or run into a problem with my approach. From bob at passcal.nmt.edu Tue Oct 18 01:05:07 2011 From: bob at passcal.nmt.edu (Bob Greschke) Date: Mon, 17 Oct 2011 17:05:07 -0600 Subject: [Tkinter-discuss] Calculating a ripening tomato Message-ID: <5CF43974-AE6A-40FF-BDE4-53DAF87B875B@passcal.nmt.edu> Do you think there is a formula (probably three of them) for calculating the RGB colors for the background color of a widget of a tomato ripening from green to red with, let's say, an input of 0-100%? It's not just Red 0-255 and green 255-0, because the brown shows up in the middle and doesn't look good at all. There must be some blue in there somewhere, but I'd like to calculate the values, instead of just looking them up in a list of 100 RGB values. I'd think there would be something like this for various things somewhere. Autumn leaves turning colors, sunsets... I've done widget coloring for things like different elevations and water depths, but for those I just binned the values into 16 or thereabouts bins and looked up the color I wanted to use. Calculating the values would be more elegant, right? :) I searched around a little, but just kept getting schooled on how to grow tomatoes. Bob From bieffe62 at gmail.com Tue Oct 18 06:18:37 2011 From: bieffe62 at gmail.com (Francesco Bochicchio) Date: Tue, 18 Oct 2011 06:18:37 +0200 Subject: [Tkinter-discuss] Calculating a ripening tomato Message-ID: A quick googling tourned out with this: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0102-05362004000300006 Which seems to be related to what you are looking for... only a lot more complex than a simple formula. I suspect a look-up table does mot seem so bad, now :-) Ciao ------- FB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at greschke.com Tue Oct 18 07:36:07 2011 From: bob at greschke.com (Bob Greschke) Date: Mon, 17 Oct 2011 23:36:07 -0600 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: References: Message-ID: Hi! Nice! That's not a long way off from what I empirically came up with below. I tried all kinds of combinations of having the red come up at linear or Pct**2 or Pct**3 or Pct**4 rates, with the green going down linearly or at Pct**2 or Pct**3 or Pct**4 rates. I even had a little blue kicking in when the red and green values were close to each other to try and counteract the formation of brown. But it all seemed to get much simpler when I used the Pct**2.7 rate for the red. 2.7 being close to e. I should have known the "natural" log would be involved somehow, even though most tomatoes these days are far from natural. Why did I need a ripening tomato? For a Pomodoro Timer, of course. :) Thanks! Bob #! /usr/bin/env python # ripe.py # The ripening tomato routine. It's kinda close. # In my program the engine is a count down timer, so this routine counts down # from 400 to 0 to simulate it. from Tkinter import * Root = Tk() Stage = 400 R = 0 G = 0 B = 0 for i in xrange(0, 20): Sub = Frame(Root) for j in xrange(0, 20): Pct = Stage/400.0 Stage -= 1 # 2.7 => e-ish R = 255-int((Pct**2.7)*255.0) G = int(Pct*255.0) Label(Sub, text = " ", bg = "#%02x%02x%02x"% \ (R, G, B)).pack(side = LEFT) Sub.pack(side = TOP) Root.mainloop() On 2011-10-17, at 10:18 PM, Francesco Bochicchio wrote: > A quick googling tourned out with this: > > http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0102-05362004000300006 > > Which seems to be related to what you are looking for... only a lot more complex than a simple formula. > > I suspect a look-up table does mot seem so bad, now :-) > > Ciao > ------- > FB > From greg.ewing at canterbury.ac.nz Tue Oct 18 08:19:26 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 18 Oct 2011 19:19:26 +1300 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: References: Message-ID: <4E9D1A6E.3010904@canterbury.ac.nz> Bob Greschke wrote: > 2.7 being close to e. I should have known the "natural" log would be > involved somehow, even though most tomatoes these days are far from natural. Resemblance to e probably doesn't have much to do with it -- more likely your formula is just preventing the overall brightness of the colour from getting too low, thus avoiding brown. Another way to approach this might be to do the interpolation in HSB space, varying the hue angle from red to green while keeping the brightness constant, and then convert to RGB. -- Greg From bob at passcal.nmt.edu Tue Oct 18 18:15:25 2011 From: bob at passcal.nmt.edu (Bob Greschke) Date: Tue, 18 Oct 2011 10:15:25 -0600 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: <4E9D1A6E.3010904@canterbury.ac.nz> References: <4E9D1A6E.3010904@canterbury.ac.nz> Message-ID: On Oct 18, 2011, at 00:19, Greg Ewing wrote: > Bob Greschke wrote: >> 2.7 being close to e. I should have known the "natural" log would be >> involved somehow, even though most tomatoes these days are far from natural. > > Resemblance to e probably doesn't have much to do with it -- > more likely your formula is just preventing the overall > brightness of the colour from getting too low, thus > avoiding brown. > > Another way to approach this might be to do the interpolation > in HSB space, varying the hue angle from red to green while > keeping the brightness constant, and then convert to RGB. > > -- > Greg Oh, agreed. That sounds like a better way to do this, but for a quick and dirty approach I messed for quite a while with just red and green rates and tossed in several different if-statements to mess with things here an there, but then just threw all of that out and tried the **2.7 and it all of a sudden was pretty close to what I had in mind. I've since altered it to start with a bit of red R = 65+(190-int((Pct**2.718)*190.0)) G = int(Pct*255.0) It still spends a little too much time in a tanish-orangeish area for my taste, but it's good enough for this exercise. I wouldn't dismiss e too quickly. It pops up in some weird places. Now I'm wondering about being able to calculate things like going from dark green through to white for land elevations, and the colors of the rainbow in the right order, light blue to dark blue for water depths (that one is easy), etc. I'll have to look into this when I get some time. Thanks! Bob From dblank at cs.brynmawr.edu Tue Oct 18 18:37:38 2011 From: dblank at cs.brynmawr.edu (Douglas S. Blank) Date: Tue, 18 Oct 2011 12:37:38 -0400 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: References: <4E9D1A6E.3010904@canterbury.ac.nz> Message-ID: <4E9DAB52.5030706@cs.brynmawr.edu> On 10/18/2011 12:15 PM, Bob Greschke wrote: > > On Oct 18, 2011, at 00:19, Greg Ewing wrote: > >> Bob Greschke wrote: >>> 2.7 being close to e. I should have known the "natural" log would >>> be involved somehow, even though most tomatoes these days are far >>> from natural. >> >> Resemblance to e probably doesn't have much to do with it -- more >> likely your formula is just preventing the overall brightness of >> the colour from getting too low, thus avoiding brown. >> >> Another way to approach this might be to do the interpolation in >> HSB space, varying the hue angle from red to green while keeping >> the brightness constant, and then convert to RGB. >> >> -- Greg > > Oh, agreed. That sounds like a better way to do this, but for a > quick and dirty approach I messed for quite a while with just red and > green rates and tossed in several different if-statements to mess > with things here an there, but then just threw all of that out and > tried the **2.7 and it all of a sudden was pretty close to what I had > in mind. I've since altered it to start with a bit of red > > R = 65+(190-int((Pct**2.718)*190.0)) G = int(Pct*255.0) > > It still spends a little too much time in a tanish-orangeish area for > my taste, but it's good enough for this exercise. I wouldn't dismiss > e too quickly. It pops up in some weird places. > > Now I'm wondering about being able to calculate things like going > from dark green through to white for land elevations, and the colors > of the rainbow in the right order, light blue to dark blue for water > depths (that one is easy), etc. I'll have to look into this when I > get some time. > > Thanks! > > Bob Although this is pretty off-topic for the Tkinter mailing list, I look forward to seeing where this leads you, so do please make your results available. Also, if anyone has first-principle arguments or equations, that would be interesting. (Off-list I would also like some pointers on the strange places where e makes appearances.) Thanks, and sorry for the additional noise, -Doug > > _______________________________________________ Tkinter-discuss > mailing list Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > -- Douglas S. Blank, Associate Professor and Chair Department of Computer Science, Bryn Mawr College http://cs.brynmawr.edu/~dblank (610)526-6501 From greg.ewing at canterbury.ac.nz Tue Oct 18 22:55:36 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 19 Oct 2011 09:55:36 +1300 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: References: <4E9D1A6E.3010904@canterbury.ac.nz> Message-ID: <4E9DE7C8.1070306@canterbury.ac.nz> Bob Greschke wrote: > R = 65+(190-int((Pct**2.718)*190.0)) > G = int(Pct*255.0) > > I wouldn't dismiss e too quickly. It pops up in some weird places. Not as an exponent, though -- usually it's e**something rather than something**e. That's what makes me think it's *probably* a coincidence. -- Greg From strider1066 at gmail.com Wed Oct 19 05:00:20 2011 From: strider1066 at gmail.com (Steve Solomon) Date: Tue, 18 Oct 2011 20:00:20 -0700 Subject: [Tkinter-discuss] Tkinter-discuss Digest, Vol 92, Issue 7 In-Reply-To: References: Message-ID: Thank you all, Peter Otten's patch worked right off the bat. Now that Peter explained the core of the problem I'll be able to tinker with the code to dig deeper. Steve On Mon, Oct 17, 2011 at 3:00 AM, wrote: > Send Tkinter-discuss mailing list submissions to > tkinter-discuss at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/tkinter-discuss > or, via email, send a message with subject or body 'help' to > tkinter-discuss-request at python.org > > You can reach the person managing the list at > tkinter-discuss-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Tkinter-discuss digest..." > > > Today's Topics: > > 1. Re: Limit to the number of canvases in a top_level object? > (Peter Otten) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Oct 2011 15:43:26 +0200 > From: Peter Otten <__peter__ at web.de> > To: tkinter-discuss at python.org > Subject: Re: [Tkinter-discuss] Limit to the number of canvases in a > top_level object? > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Steve Solomon wrote: > > >>> Is there a limit to the number of canvases in a top_level object -- > one > >>> maybe ? I have been trying to solve this problem with an application > for > >>> several weeks. In the application I have two canvases, each with a grid > >>> of rectangle objects. They display perfectly but when I try to interact > >>> with the rectangles they behave anomalously. Using > >>> canvas.find_closest(event.x, event.y) the rectangles in the first drawn > >>> canvas behave normally, allowing configuring each, but within the > second > >>> canvas the rectangles report back the id of only one of the rectangles > >>> and an attempt to change the fill-color of any one is applied only to > >>> the last item in the grid. > >>> > >>> Your thoughts would be appreciated, thank you > > > I'm a bit in the tall weeds, please excuse the mess (in the attached > > code). > > The best time to clean up your code is always right now; the second best > time is when you run into an error ;) > > > from Tkinter import * > > import random > > import palettebuilder as pb > > from colorservices import getHSV > > > > def randomColors(count=1, sorted=False): > > "returns list of color strings in #nnnnnn hexidecimal format" > > rtn = [] > > for x in range(count): > > intgr = random.randrange(0, 16777215, 1) > > hex = "#{:0>6X}".format(intgr) > > rtn.append(hex) > > if sorted: > > "the folowing should be sorted by ..." > > # rtn.sort(key=lambda rtn: getHSV(rtn)[2]) #...value > > rtn.sort(key=lambda rtn: getHSV(rtn)) #...full HSV > > return rtn > > > > class test(Toplevel): > > def __init__(self): > > Toplevel.__init__(self) > > self.config(height = 500, width = 500) > > self.activeCanvas = None > > self.bind("", self.reportXY) > > size = 180 > > frameOne = Frame(self, height = 200, width =200, bg = "pink") > > self.canvasOne = Canvas(frameOne, height=size, width=size, > background="#bababa") > > self.canvasOne.grid(row = 0, column = 0, sticky = W ) > > frameTwo = Frame(self, height = 200, width =200, bg="light blue") > > self.canvasTwo = Canvas(frameTwo, height=size, width=size, > bg='#bababa') > > self.canvasTwo.grid(row = 1, column = 1) > > self.canvasOne.bind("", self.makeOneActive) > > self.canvasTwo.bind("", self.makeTwoActive) > > frameOne.grid(row = 0, column = 0, sticky = W ) > > frameTwo.grid(row = 1, column = 1, sticky = E ) > > colors = randomColors(64, sorted = True) > > pb.DrawPalette(self.canvasOne, colors, columns = 8) > > colors = randomColors(64, sorted = True) > > pb.DrawPalette(self.canvasTwo, colors, columns = 8) > > > > def makeOneActive(self, event): > > self.activeCanvas = self.canvasOne > > print "one = active self.activeCanvas>>>", > type(self.activeCanvas) > > > > def makeTwoActive(self, event): > > self.activeCanvas = self.canvasTwo > > print "two = active self.activeCanvas>>>", > type(self.activeCanvas) > > > > def reportXY(self, event): > > print event.x, event.y > > item=self.activeCanvas.find_closest(event.x, event.y) > > print self.activeCanvas.itemcget(item, "tags"), "item>>", item > > self.activeCanvas.itemconfigure(item, fill = "red") > > > > root = Tk() > > root.withdraw() > > test() > > #for x in range(10): > > # print randomColors(10) > > # print "\n" > > root.mainloop() > > > > You bind the reportXY() method to an event triggered by your Toplevel > subclass, so the event instance contains coordinates relative to the test > widget. On the other hand the Canvas.find_closest() method expects > coordinates in terms of the canvas widget. The difference doesn't matter > for > canvasOne which is located at the origin of the toplevel, but gives wrong > results for canvasTwo with its non-zero offset. > > While the diagnosis was easy it took me a while to find a way to convert > between the two coordinate systems. The following seems to work: > > def reportXY(self, event): > canvas = self.activeCanvas > > dx = self.winfo_rootx() - canvas.winfo_rootx() > dy = self.winfo_rooty() - canvas.winfo_rooty() > > x = event.x + dx > y = event.y + dy > > print "before", event.x, event.y > print "after", x, y > > item = canvas.find_closest(x, y) > print canvas.itemcget(item, "tags"), "item>>", item > canvas.itemconfigure(item, fill="red") > > Let me know if you find a better way or run into a problem with my > approach. > > > > ------------------------------ > > _______________________________________________ > Tkinter-discuss mailing list > Tkinter-discuss at python.org > http://mail.python.org/mailman/listinfo/tkinter-discuss > > > End of Tkinter-discuss Digest, Vol 92, Issue 7 > ********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.meanley at gmail.com Wed Oct 19 05:49:01 2011 From: brian.meanley at gmail.com (Brian Meanley) Date: Tue, 18 Oct 2011 20:49:01 -0700 Subject: [Tkinter-discuss] Calculating a ripening tomato Message-ID: Not that I have a solution for you, but figured that I would share some of my experiences with something similar... The suggestion of using HSL rather than RGB is a good one, as calculating this in RGB would be rather hit or miss most likely... However, I think perhaps you might want to try calculating the raw chromaticity as CIE xy coordinates, rather than HSL, and then doing your color conversions from there. From the papers that were linked to earlier regarding the topic, it seemed that the preferred color-space for calculations was LAB, which would coincide rather nicely to the xyY coordinates. Many things are calculated along these lines, perhaps the most common being light/color temperature using the Planckian Locus: http://en.wikipedia.org/wiki/Planckian_locus. Unfortunately as you can see, the algorithms used are rarely 'simple' (at least to calculate initially), and approximations are often used. Basically, if you can find a 'curve' on on the color-chart that matches the color-ranges that you are after, than it just becomes a matter of figuring out the function(s) that best approximates it. I have a python/tkinter app that I created that you could take a look at for an implementation of the above color-temperature scale if it would help you out. I won't post all the code here, but you can download it at the links below. You'll have to excuse the code however, I make my living as a vfx artist, and I'm rather a hack when it really comes to coding... Anyways, you can find it here: http://wiki.brianmeanley.com/wiki/LightTools.py . For the main code involving the color calculations, look in the 'bhm_color.py' module. A non-gui version can be found here: http://www.brianmeanley.com/blog/?page_id=349 Color-science is a pretty hefty subject in its' own right, but it can be an extremely interesting and 'fun' one too if you take an interest in it. I would think that doing a bit of digging into the color temperature examples/links above might give you some insight into what it is that you are hoping to accomplish, as well as the other examples that you mentioned. I would also highly suggest checking out http://brucelindbloom.com/ for some good info regarding the math behind most color conversions and more. Good luck! -Brian (PS, sorry if I messed this mailing list thing up, I have never actually posted to this list before...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Wed Oct 19 06:48:06 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 19 Oct 2011 17:48:06 +1300 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: References: Message-ID: <4E9E5686.70401@canterbury.ac.nz> Brian Meanley wrote: > > Many things are calculated along these lines, perhaps the > most common being light/color temperature using the Planckian > Locus: http://en.wikipedia.org/wiki/Planckian_locus. Not sure that colour temperature would be all that relevant, since it's concerned with black body radiation. You would have to heat your tomatoes to a rather uncomfortable degree for that to affect their colour... -- Greg From bob at passcal.nmt.edu Wed Oct 19 18:15:51 2011 From: bob at passcal.nmt.edu (Bob Greschke) Date: Wed, 19 Oct 2011 10:15:51 -0600 Subject: [Tkinter-discuss] Calculating a ripening tomato In-Reply-To: <4E9E5686.70401@canterbury.ac.nz> References: <4E9E5686.70401@canterbury.ac.nz> Message-ID: On Oct 18, 2011, at 22:48, Greg Ewing wrote: > Brian Meanley wrote: >> Many things are calculated along these lines, perhaps the most common being light/color temperature using the Planckian Locus: http://en.wikipedia.org/wiki/Planckian_locus. > > Not sure that colour temperature would be all that relevant, > since it's concerned with black body radiation. You would > have to heat your tomatoes to a rather uncomfortable degree > for that to affect their colour... > > -- > Greg Dare I say it?: Gives new meaning to fried green tomatoes. I better not. Just ignore that line above. Bob From brian.meanley at gmail.com Wed Oct 19 18:27:55 2011 From: brian.meanley at gmail.com (Brian Meanley) Date: Wed, 19 Oct 2011 09:27:55 -0700 Subject: [Tkinter-discuss] Calculating a ripening tomato Message-ID: >Not sure that colour temperature would be all that relevant, >since it's concerned with black body radiation. You would >have to heat your tomatoes to a rather uncomfortable degree >for that to affect their colour... True. I never meant to imply that it was a bolt-on solution to the problem. I was merely trying to give a jumping off point for some further research (as the OP also mentioned other situations that he was interested in such as sunsets, etc...). I think that with a bit of work, the underlying concepts of plotting points in xy, rather than manipulating individual RGB channels, could possibly be adopted to suit the OP's needs. Anyways, didn't mean to take the talk off topic. -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From waynejwerner at gmail.com Thu Oct 20 22:11:37 2011 From: waynejwerner at gmail.com (Wayne Werner) Date: Thu, 20 Oct 2011 15:11:37 -0500 Subject: [Tkinter-discuss] [Tutor] tkinter binding issues In-Reply-To: <1319119618.46591.YahooMailNeo@web130205.mail.mud.yahoo.com> References: <1319119618.46591.YahooMailNeo@web130205.mail.mud.yahoo.com> Message-ID: Forwarding to the list... On Thu, Oct 20, 2011 at 9:06 AM, Elwin Estle wrote: > Thank you very much. That was a great help. I briefly considered the > lambda idea, but since I really don't understand the whole lambda thing (I > used an explanation from effbot for my buttons...but didn't really know > what I was doing) ... didn't even attempt it. The one that was really > driving me crazy was the clear form thing. I tried your idea of changing > the focus before calling the tkmessagebox. Worked like a champ! Lambdas are quite nice - they let you create a single, one line function with minimal effort. def add(x, y): return x + y add2 = lambda x, y: x + y add(2, 3) # Returns 5 add2(2, 3) # Also returns 5 I highly recommend firing up your interpreter and playing around with lambda functions. There are only a few places that they're appropriate, but they make those few things a _lot_ easier. HTH, Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From magni at inrim.it Fri Oct 21 09:37:31 2011 From: magni at inrim.it (Alessandro Magni) Date: Fri, 21 Oct 2011 09:37:31 +0200 Subject: [Tkinter-discuss] tag insertion while writing Message-ID: <4EA1213B.3050103@inrim.it> An HTML attachment was scrubbed... URL: