[Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't

[Fredrik Lundh]

> > PIL 1.0 can hook itself into Tk in two different
> > ways:
> > 
> > 1) link _tkinter with the tkImaging module (old style)
> > 2) link _imaging with the same module (new style)
> > 
> > in both cases, tkImaging needs access to the under-
> > lying Tcl/Tk libraries, so (2) only works well if you're
> > using shared libraries.
> 
> I think that's fine. But why is (2) better than (1)? For me,
> looks like (1) is the reasonable solution.

both methods are supported, so you can use whatever
method you prefer.  (or none, if you don't use ImageTk).

> Then again, you mention not wanting to modify Tkinter. But if
> such a modification would be an improvement, it would be better
> for everyone, wouldn't it? If it is at least minimally useful to
> other users of Tkinter besides PIL, it should be done.

today, the modification is highly PIL specific (it installs
a special Tcl command whenever tkinter creates a new
root instance).

_tkinter could be modified to allow you to install new
Tcl commands from Python code, rather than by relink-
ing the module, but I'm not aware of any other module
that would benefit from this.  besides, commands are
not the only thing that you might wish to install in this
way.  there are also bitmaps, canvas types, etc.

and when you end up requiring access to many parts
of the Tcl/Tk library, linking with (shared versions of)
Tcl/Tk surely seems like the best solution... :-)

</F>