Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #86116 > unrolled thread

Re: Design thought for callbacks

Started byCem Karan <cfkaran2@gmail.com>
First post2015-02-22 08:54 -0500
Last post2015-02-22 08:54 -0500
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Design thought for callbacks Cem Karan <cfkaran2@gmail.com> - 2015-02-22 08:54 -0500

#86116 — Re: Design thought for callbacks

FromCem Karan <cfkaran2@gmail.com>
Date2015-02-22 08:54 -0500
SubjectRe: Design thought for callbacks
Message-ID<mailman.19011.1424613279.18130.python-list@python.org>
On Feb 22, 2015, at 7:24 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Feb 22, 2015 at 11:07 PM, Cem Karan <cfkaran2@gmail.com> wrote:
>>> 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.
> 
> Not sure what you mean by "returning". If the user types in a number
> in a GUI widget, that would trigger some kind of on-change event, and
> either the new text would be a parameter to the callback function, or
> the callback could query the widget. In the latter case, I'd probably
> have the callback as a closure, and thus able to reference the object.

We're thinking of the same thing.  I try to structure what little GUI code I write using the MVP pattern (http://en.wikipedia.org/wiki/Model-view-presenter), so I have these hub and spoke patterns.  But you're right, if you have a partially evaluated callback that has the presenter as one of the parameters, that would do it for a GUI.  I was thinking more of a DAG of objects, but now that I think about it, callbacks wouldn't make sense in that case.

Thanks,
Cem Karan

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web