Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #86100
| Subject | Re: Design thought for callbacks |
|---|---|
| From | Cem Karan <cfkaran2@gmail.com> |
| Date | 2015-02-22 07:07 -0500 |
| References | (3 earlier) <CAPTjJmrfMowbK7z+eN7xfMv2Ck5peJpBPyBRHvhXM4-ocxRR6w@mail.gmail.com> <BB15CAE6-4C31-4544-A9DE-DC9D6F827B45@gmail.com> <CAPTjJmrA2suEdKDZkn44Xxsq4m_mZ=Jf6C19GvBjoBfCaTEyzg@mail.gmail.com> <C82546F4-1CBB-4D83-834F-CF1BAE52E8E9@gmail.com> <CAPTjJmoZsB8=xpadFp_S5TFqHcSjW9kO-SfmJzM2dLvq+yCPRA@mail.gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.19001.1424606842.18130.python-list@python.org> (permalink) |
On Feb 21, 2015, at 10:55 AM, Chris Angelico <rosuav@gmail.com> wrote: > On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan <cfkaran2@gmail.com> wrote: >> OK, so if I'm reading your code correctly, you're breaking the cycle in your object graph by making the GUI the owner of the callback, correct? No other chunk of code has a reference to the callback, correct? > > Correct. The GUI engine ultimately owns everything. Of course, this is > a very simple case (imagine a little notification popup; you don't > care about it, you don't need to know when it's been closed, the only > event on it is "hit Close to destroy the window"), and most usage > would have other complications, but it's not uncommon for me to build > a GUI program that leaves everything owned by the GUI engine. > Everything is done through callbacks. Destroy a window, clean up its > callbacks. The main window will have an "on-deletion" callback that > terminates the program, perhaps. It's pretty straight-forward. How do you handle returning information? E.g., the user types in a number and expects that to update the internal state of your code somewhere. Thanks, Cem Karan
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 07:07 -0500
csiph-web