[Tutor] Tkinter canvas on frame

[Dennis Lee Bieber]

On Tue, 1 Mar 2022 10:47:05 +0000, Alan Gauld via Tutor <tutor at python.org>
declaimed the following:

>On 28/02/2022 23:52, Phil wrote:
>
>> I understand that the pack manager should be left to automatically 
>> adjust the size of the window.  However, in the case of a drawn line or 
>> a shape that extends off the edge of the canvas, isn't it still 
>> necessary to specifically set the window geometry or is it simply left 
>> to the user to enlarge the window?
>
>So what if the user draws it even bigger? What happens in other graphics
>programs you've used? Usually you have the option to zoom in/out without
>changing the size of the window. But when zoomed in part of the image
>will be off-screen.
>
>But scaling the content of a canvas could be tricky. I don't know
>if the widget offers any assistance there?

	Haven't looked at Tkinter, but as I recall, most of these windowing
packages issue a "redraw" event if a general drawing widget is resized (or
even just covered/uncovered), requiring the application to redo any
calculations needed for scaling. Note that this most applies to "paint" or
"line draw" type windows -- regular widgets being just rectangular shapes
with/without text, and easy to rescale or just position.

	"paint" and "line draw" type windows tend to be sequences of actions,
and the windowing system doesn't save the sequence used to produce the
display. It becomes part of the application "redraw" handler to regenerate
the display data -- and determine if the viewport has expanded but not the
scale (ie: the world coordinates now span 0..2 when they used to be 0..1)
or if the scale has changed but the real world coordinates are the same
(world is still 0..1, but there may be twice as many pixels spanning that
range).

	The last time I did anything with graphical data was in the days of
DECWindows, UIL (to define the DECWindows interface) and used a particular
DECWindows widget as a canvas for GKS (Graphical Kernel System). GKS
supported Display-Lists and scaling from "world" to "display". Resizing the
application window required replaying the display list using new scaling
factors.

	Considering the full system required running something like five
separate executables to one "display" window (legacy system was a RAMTEK
9300 Graphics Engine -- which operated as an I/O device shared by each
executable; the update required writing a "display app" to which those
executables would send commands), and some of those executables (separate
executable to, say, draw the axes labels, another to render the
"temperature scale" bar, a third to render a world map, and a fourth to
read a massive data file of "temperature points" and send them to the
display) might take half an hour or more to process input for display --
well, having to rerun all those executables every time the "display" was
resized (or worse, had another window dragged across it -- no equivalent to
the Amiga Smart Refresh window (where the OS would maintain an off-screen
bitmap from which to refill exposed areas) was a non-starter.

	I've not seen any mention of modern window packages (Tk, wX, Qt...)
incorporating the equivalent of a display list, and some may not even
handle world<>viewport<>display coordinate translation.


	Apologies for the history harangue...


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed at ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/