Fredrik Lundh <fredrik@pythonware.com>:
>
> Magnus wrote:
>
> > Greg Ewing <greg@cosc.canterbury.ac.nz>:
> > [snip]
> > > This could be very useful for GUIs, too, for implementing
> > > model-view relationships. The anygui people would be very
> > > interested, I'm sure.
> >
> > Indeed!
>
> have you actually built large-scale UI applications using a
> one-size-fits-all observer model, or are you just guessing?
Guessing about what? Greg sayd that the anygui people would be very
interested, and since I'm the project leader and I'm very interested,
I think my reply was quite authoritative <wink>.
I'm not saying that we'd need it -- but I find it interesting, and
would like to try it out as an alternative to the current
synchronisation mechanism (where, unless you either rebind an
attribute or use a model class you have to manually notify an object
that one of its attributes have been modified).
The current model seems to work well (although it's still under
construction), but built-in language support could make it simpler.
Maybe. (And I'm only guessing about that -- you're right. But I would
be interested in trying it out.)
> in real life, "something happened" is almost entirely useless,
> and the other extreme "this and this and this and this and
> this happened" isn't much better. to get performance, you
> need to think in data model terms...
Performance wasn't really my first concern. Here is a (admittedly
somewhat contrived) Anygui example:
>>> rect = [0, 0, 10, 10]
>>> win.geometry = rect # Window automatically resized
>>> rect[1] += 10 # Window not resized
>>> win.sync('geometry') # Window resized
Being able to "listen in" on lists would make the last line
unnecessary...
But this is all mainly motivated by curiosity on my part.
> </F>
--
Magnus Lie Hetland The Anygui Project
http://hetland.org http://anygui.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4