TkX is a megawidget package based on Ttk.

I'm working on redefining how one interacts with Tk, and I'm looking for some ideas from the hive mind.  As someone who has written a lot of Tk code, I've always found it cumbersome in a lot of ways while still being infinitely easier than other toolkits I've used.  TkX started as a megawidget framework that would eventually be TIP'd as the megawidget framework to be included with Tk as the default.  That part is actually done, but now I'm looking to go one further and make interacting with Tk better.

Here are the main issues I seek to solve:

'''Naming Widgets'''

Naming widgets is a pain in the ass when, most times, there are only a few you might actually care about in your GUI.  I'm specifically referring to things like frames, toolbars, scrollbars, etc...  Things that it doesn't matter what the widget is called because you'll never refer to it by its path again.


'''Widget Tagging'''

Conversely, there are widgets that you do sometimes want to remember for later.  Every Tk app basically has some similar form of this piece of code:

======
global widgets

set f [frame $top.f1]
pack $f

set widgets(OKButton) [button $f.b1 -text OK]
pack $widgets(OKButton) -side left
======

We use some array or some dict or something somewhere that stores a reference to a widget path by some name.  We basically invent some system of tagging widgets every time we write a GUI app.  If you don't know what I'm talking about, you haven't written enough Tk.


These two issues (which are just a start) actually support each other.  With widget tagging, we don't need to worry about naming.  We simply tag the widgets we care about and forget the ones we don't and let Tk handle naming them for us.  I also wanted to include geometry management as something I want to work on, but what I propose is not necessarily a fundamental change in what is already there.  Just a re-imagining.  With those things in mind, here is what TkX proposes:

'''Proposed Syntax'''
======
tkx::new toplevel . {-tags Top}

tkx::new ttk::frame Top {-tags Toolbar} \
    grid {-row 0 -column 0 -sticky ew}
    tkx::new ttk::button Toolbar {-text Help -command exit} \
        pack {-side left}
    tkx::new ttk::button Toolbar {-text Quit -command exit} \
        pack {-side left}

tkx::new {tkx::scrolled text} Top {-background white -foreground gray} \
    grid {-row 1 -column 0 -sticky nesw -weight 1}
======

TkX provides a tkx::new command through which all widget creation passes.  This is mostly because I don't want to step on what Tk already does and/or propose a complete rewrite of Tk.  This package is not meant to create an incompatibility, but simply to propose a new way going forward.  The syntax is basically:

'''tkx::new <widgetCommand> <parentWidget> ?widgetOptions? ?geometryManager? ?geometryOptions?'''

I'm not married to this syntax, which is why I'm creating this page.  I want to get some opinions from the people who knew Tk best about how this should all look.  Here are the ideas I've had so far.

'''Syntax Options'''
======
tkx::new text $parent -background white -foreground black \
    grid -row 0 -column 0

tkx::new text $parent -background white -foreground black -- \
    grid -row 0 -column 0

tkx::new text $parent {-background white -foreground black} \
    grid {-row 0 -column 0}

tkx::new text $parent {
    -background white -foreground black
} grid {
    -row 0 -column 0
}
======

They are all variations of the same theme but with small differences.  The first version takes a little more parsing and would suffer a small performance hit because of it.  The second would also require a bit of parsing but less than the first.  The third and fourth are identical except for white spacing.  Either one could be used, but the question comes down to how we would document things for newbies.

The reason for a lot of this is to remove some of the more confusing parts of Tk and make it easier for newbies to grasp.  That is a major goal in the new design, so keep that in mind while you're looking at the variations.  The last one is the most verbose, but it also makes it really easy for a newbie to not have to use \ at the line end or anything like that.  It simply looks like blocks.

I'm going to stop now and open the floor for discussion.  This code has already been written, and I'm almost ready to release.  I just need to decide on syntax here and then put it out for iteration and evolution.

Damon (July 22nd, 2010)
----