This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients gpolo, gregorlingl, loewis
Date 2008-11-19.21:04:39
SpamBayes Score 3.7325698e-13
Marked as misclassified No
Message-id <49247F65.30408@v.loewis.de>
In-reply-to <1227101508.39.0.96881720411.issue4117@psf.upfronthosting.co.za>
Content
> I cannot call the Canvas method _update_idletasks() from within
> _Screen.setup() becaus this would contradict to the architecture of the
> module which isolates all direct references to Tkinter to
> TurtleScreenBase. (The idea behind this is to make the module easily
> portable, by porting only this class).

I find that desire misguided; this is (IMO) a case of false abstraction.
Is there any kind of proof that this design actually
works, i.e. can be ported to a different GUI library (like, say,
PythonWin? or AWT, when run in Jython?)

Unless such proof can be provided (and then integrated into the code),
I recommend to give up that objective, and start merging the base class
code into the subclasses where reasonable.

> Did you experience any problems or undesired behaviour
> because of using unly cv.update?

I agree with with gpolo: it's a general Tk programming principle to
defer updates whenever possible. This allows the event handler to return
more quickly, making the system more responsive. Each individual update
call will only contribute a small amount of time to the response time.
It's many of these which eventually make the entire system sluggish.
History
Date User Action Args
2008-11-19 21:04:43loewissetrecipients: + loewis, gregorlingl, gpolo
2008-11-19 21:04:41loewislinkissue4117 messages
2008-11-19 21:04:39loewiscreate