[George Peter Staplin]: It has occured to me that much of Tk is about hiding the structure of a widget or gadget.  This greatly reduces the stress of using the toolkit, but it can become limiting.

The [canvas] is a great example of hiding structure.  If say you want to create a polygon with a red color it's as simple as:

 pack [canvas .c] -fill both -expand 1
 .c create polygon 10 10 150 150 200 200 130 100 -fill red

Tk is hiding many aspects of the structure of that object you just created.  For instance there is a '''graphics context/GC''', an '''XColor''' allocated, information about how to redraw it, etc.  The canvas takes care of redrawing it when an Expose or Configure event occurs without us telling it to.

Now obviously if we just created objects this way it would be limiting and we would run out of memory.  So, the canvas returns a unique id for each object and that can be considered a name for our structure.   We can delete the object and the hidden structure behind it.

The concept of a tag (which may have originated in Ezd) was introduce to allow having an easier method of referring to an object than the tag returned by the creation.  The tag also allows classifying objects.

This all sounds great, but then you decide "I want to manipulate Object to do X."  Usually this means writing a procedure that manipulates the object via the '''coords''' or '''scale''' subcommands.   As the amount of changes you want to make to the object increases your number of global or namespace procedures grows.  Then you may decide in the future "I want to create another instance of this."  So, then you create two or more widgets and probably redesign some of your work to '''restructure''' the code to work in this manner.  The canvas and your procedures are not a unit.  Changes made in one part may adversely affect another.

On [Drawing Gradients on a Canvas] I wrote a simple procedure.  It ends up consuming a lot of memory if used for random colors in a loop.  I also found that it was much slower than in C, because of each item being an object.  I didn't really want or need each line to be an object.  An obvious yet-limited solution is to use a photo image, but alas they are even slower due to the structure being hidden and the design of the photo subsystem.

WORK IN PROGRESS