Re: [Tile-dev] tile vs. tk

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> As I work with tile, I realize that the need for both Tk
> and tile widgets existing in an interface is a necessity,
> at least for 8.5 (until the individual management of tile
> based widgets becomes better and more established).
>
> So that leads me to the problem of the standard way in
> which tile is added as an augmentation:
>
> package require tile
> namespace import -force tile::*
>
> Of course you don't need the namespace force in their,

[ It's not necessary inside a namespace, which is the
  recommended approach to use Tile on a per-module basis,
  but -force is needed if you do this in the global scope ]

> but I think what we really need is an interim step that
> does the opposite for all Tk widgets, like:
>
> namespace move $tkWidgetCommands tk::*
>
> There is no such command now, but I think that tile should
> be providing it.

That's a good idea -- how would we implement it?

One approach is to [rename] all the Tk widget commands
into the tk namespace, [namespace export] them, then
[namespace import] them back into ::.  (I don't _think_
this will break anything, but parts of Tk have been known
to do some jiggery-pokery with command internals...)

Another approach is to change this in the core; have Tk
define all the widget commands in the tk::* namespace to
begin with (sort of a followup to TIP #44).  Naturally
it should also [namespace import] them into :: to avoid
breaking every script ever written...  This might be
a better approach.

> Also, I think we should be reconsidering
> the 'tile' name *right now*, and I think that ttk is still
> useful.  The tile code is already full of TTK_* APIs, for
> themed Tk.  I think this separation from old Tk_ tk::* is
> actually a good thing, rather than thinking these should
> become the tk::* in the future.

Sounds reasonable.  Although I think we should still use
the name "tile" for stuff like the package name and maybe
a few other places.  'ttk::*' could be used for the public
script-level API.


--Joe English

  jen...@fl...