Re: Trellis on_commit and Performers
"Phillip J. Eby" <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]>
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <[email protected]> |
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.