[PEAK] Trellis on_commit and Performers

[Phillip J. Eby]

At 07:54 PM 10/5/2008 +0300, Sergey Schetinin wrote:
>Trellis managers + AddOns make it rather trivial.  In .do_write I call
>manage_freeze(wxobj) which is implemented like this:
>
>class WxFreezeManager(addons.AddOn):
>     def __init__(self, ob):
>         self.ob = ob
>
>     def __enter__(self):
>         self.ob.Freeze()
>
>     def __exit__(self, *args):
>         self.ob.Thaw()
>
>
>def manage_freeze(wxobj):
>     if isinstance(wxobj, wx.Window):
>         trellis.manage(WxFreezeManager(wxobj.TopLevelParent))

Nice.  A very elegant solution.  One minor issue: there will be a 
circular reference between the freeze manager and the top-level 
window.  Dunno if that's really a problem, though.


>Also, event callbacks firing inside user code make me
>suspicious about possibility that user-activity callbacks might fire
>there too.

I don't think that's possible.  ISTM that such events must come via 
the normal event queue, not asynchronously, unless you are explicitly 
yielding or polling to pull such events from the queue.  Of course, I 
suppose that wx might do it inside of certain calls, but hopefully 
this is documented if so.  :)


>I completely missed the [dis]connectors of @maintain rules, this
>really starts to look like a solution. Thanks a lot, your help is
>invaluable. I'll report on how this works out.

I didn't think of it earlier because I not only forgot they were 
there, but I also forgot I'd made them able to safely do 
trellis-level changes.  :)


>If you will have a moment, could you please point to what makes
>discrete rules work correctly with performers? It's more curiosity
>that anything else. It seems like those cells just do this in their
>_finish (which runs in on_commit):
>
>             change_attr(self, '_value', self._reset)
>             changed(self)
>
>And it doesn't seem terribly different from setting a regular Value in
>on_commit (given its _set_by was reset by that time).

It isn't; however, setting a value also does a lock() and schedules 
another _finish(), neither of which would be necessary or desirable here.