[Tile-dev] Re: tile vs. tk

[<dg...@ni...>]

Quoting tkt...@li...:
> Of course you don't need the namespace force in their,
> but I think what we really need is an interim step that
> does the opposite for all Tk widgets, like:
> 
> namespace move $tkWidgetCommands 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.  We are talking about 1
> char, and I don't really think that I'm ready to screw over
> every existing Tk app in Tk 9 by making our life hard over
> a single extra t or not.

I think I can be flexible regarding any interim steps
that turn out to be necessary for a smooth migration,
even if that means gobbling up another toplevel namespace.

I hope, though, that we can keep our "eyes on the prize,"
so the finished result holds together coherently, without
too much historical inconsistency visible to the user.

I think the end product should be a package "Tk" that
provides many public commands, all exported from the
namespace "::tk".

I don't want users to forever have to know that it's
[namespace import ::tk::button], but it's 
[namespace import ::ttk::notebook], all because of
the development history of Tk.  Let all commands
that come to be part of Tk also come to 
be [namespace import]-able from ::tk .

Note that there's no issue with "breaking every existing
Tk app in Tk 9" either, because currently *no* Tk
commands are exported from ::tk ; they're all created
in :: (for the sake of not breaking those Tk apps
written for Tk 4 (!) ).  

DGP