On Wed, Oct 5, 2011 at 11:26 AM, GKalman <kalma...@msn.com> 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
_______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss