After having done some considerable work with tile, searching for
platform native look and feel across various platforms, I have
come to the conclusion that simple codistribution of a platform
native widget set with Tk is seriously flawed.

First off, we all recognize that Tk needs the revamp.  We have
been aware of this for years, and tile does currently provide
the majority of the necessary changes in this regard.  At the
same time, after doing much work converting various applications
to make use of themed widgets, I realize that maintaining the
classic Tk set is equally as important for specialized widget
elements and other situations having highly customized UIs.  In
fact, I would argue that reverting some of native work done on
the "classic" Tk set would be best when Ttk is added, especially
on OS X, but that's a different discussion ...

So, we all know we want everyone to be able to use the themed
widgets, which requires consistent access.  The idea of
"strongly recommended" inclusion for binaries is just plain
silly - there should be no choice in this matter.  I don't want
to allow someone to make Tk binaries without Ttk any more then
I want them to make Tk binaries without the text widget.

There seem to be 2 main concerns regarding full core inclusion:

a) Core bloat
b) Maintenance

Core bloat is the easiest to address, as we agreed long ago
that Tk can grow (at least somewhat) without negative impact on
anyone.  Tile adds not much in binary terms, especially
compared to the benefit.  Tk is not bound by the same size
constraints as Tcl - as a UI toolkit, people already expect it
to be larger than it is.

As to maintenance, this one actually begs for core inclusion
more than not.  While tile and the Ttk widgets are not as
mature as the classic Tk widgets, separating them is not going
to enhance their stability.  Keeping them close will ensure
that we as maintainers are more focused on having everything
work "as expected".  Furthermore, leveraging off of common code
will actually make parts of tile more mature.  Also, making it
tied to the core will actually reduce the set of build issues
that arise from trying to make it some special extension.

The next point, not really addressed in TIP #248, or TIP #48
that it silently deprecates (we should probably make more of a
note of that ...), is that Tk should grow its C API base to
make it easier for Tk widget extension authors to craft native
themed widgets.  This may be more work than can fit into 8.5,
but it is still important and should not be forgotten.

I believe that addresses all relevant points.  I also think we
shouldn't ruminate on this one too long.  Time to bite the
bullet, integrate the code, and get cracking on making the
next release of Tk sizzle.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core