Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!bcyclone01.am1.xlned.com!bcyclone01.am1.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Design thought for callbacks
From: Cem Karan <cfkaran2@gmail.com>
In-Reply-To: <CAPTjJmoOnA8VWxtTSn5SVunsfbb8Qh10n-RA7WppuCcpw=7ZgQ@mail.gmail.com>
Date: Sun, 22 Feb 2015 08:54:28 -0500
Content-Transfer-Encoding: quoted-printable
References: <33677AE8-B2FA-49F9-9304-C8D93784255D@gmail.com> <CAPTjJmpEHQV2PpaZvszuTGn0_GNg0sWV6aLenbQsZrSXCy2YKQ@mail.gmail.com> <39813568-6DB8-4341-A130-C256CFF352EE@gmail.com> <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> <1444051E-DBD0-4162-94DF-50BC6CF62A92@gmail.com> <CAPTjJmoOnA8VWxtTSn5SVunsfbb8Qh10n-RA7WppuCcpw=7ZgQ@mail.gmail.com>
To: Chris Angelico <rosuav@gmail.com>
Cc: "comp.lang.python" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19011.1424613279.18130.python-list@python.org>
Lines: 38
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86116


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.
>>=20
>> 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.
>=20
> 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=