What new widgets need to be included? This can be a generic need (i.e. some
kind of tab notebook), or a specific instance of a widget that is out there. In
terms of the latter, keep in mind both underlying implementation (i.e. does the
widget work well), and also its API. Examples of widgets with good API's are
just as valuable as those with good implementation, and the former might well
be used to improve the latter.
Some good places to look for details on these things include the Windows Common Controls
[link] (any we're
missing that aren't in the list below?), the palette of controls available in the Visual Basic GUI builder etc..
Action Items
- can we agree on this last as it stands, including priorities?
- identify existing solutions for high priority items (c.f. Assets page)
Proposed Widgets
High Priority to Include: (yes, please bitch about the categorization) (assessments of general implementation route by DKF)
- a table widget (in C, may share across platforms)
- a tree widget (in C, may share across platforms)
- a tabbed notebook widget (in C or Tcl, share initially but look will vary between platforms eventually once we move from targetting Win2k to WinXP)
- a non-dockable toolbar widget (in Tcl?, may share across platforms?)
- a tooltip widget (in Tcl, may share across platforms)
- a drop-down list/combobox widget (in Tcl?, may share across platforms?)
- a properties dialog (in Tcl, platform-specific versions)
- a statusbar widget (in Tcl, platform-specific versions)
Medium Priority to Include:
Lower Priority to Include: (and probably therefore beyond the initial scope of this project)
Addressed by the Tile project
Posted at Aug 08/2003 01:48 PM:
Michael Lenaghan: I'd say that a list view (ie, multi-column listbox) is high priority. If TkTree gets added to the core, you'll get list views as well...
Posted at Aug 08/2003 04:20 PM:
Paul Kienzle: Table widgets such as tktable can act as multicolumn lists. Conversely, multicolumn list widgets such as tablelist can act as a table. Tree widgets such as TkTreeCtl and blt::heirtable can act as multi-column lists.
In my particular case, I want to be able to restructure the tree. Think of a table containing {red,white,green} X {circle,square,triangle}. I want to see the tree ordered by colour or by shape (user selectable, changing on the fly). If collapsing/expanding repeated values were a capability of a table widget, that table widget could act like a tree.
Posted at Aug 13/2003 07:06 AM:
Jeff Godfrey: I don't know if this is a widget, or more of a window decoration, but how about the little hashed triangle that appears in the lower right hand corner of a Window's app that's used to drag for resizing? That appears to be a standard Win UI element that has no Tk counterpart. There is a tcl script floating around (maybe I got it from the Wiki?) that does an admirable job of emulating this, but should it be available in the core? See
[link]
Posted at Aug 13/2003 02:20 PM:
Damon Courtney: I really like the way BWidgets handles insertion into listboxes and trees in that it allows you to name the node that you're inserting. I would like it to be a little more like the image command though. IE:
.listbox insert end foo -text FOO
Inserts an item called foo.
.listbox insert end -text FOO
Creates a new item from a unique identifier and creates the item, returning the new ID.
This is exactly how I'd like the tree widget to work as well. In BWidgets, I added a #auto substitution (which I never really liked, but hey, people know it) to do this sort of action.
Posted at Aug 13/2003 09:43 PM:
Marty Backe: For the last 1+ years I've been impressed with the widgets offered by Iocomp -
http://www.iocomp.com You can download an executable demo. I particularly like their LED's, dials, knobs, LCD's, scales, progress, etc. Lots of good ideas to leverage off. I've made some LED's (with the reflections) using the canvas which look identical. Food for thought.
Posted at Aug 18/2003 12:58 PM:
Jeff Hobbs: The iocomp stuff has some overlap with the vu widget set and BLT. It has more different styles for the gauges, but nothing not reproducible in Tk should one put a little effort into it.
Posted at Aug 15/2003 08:16 AM:
Kevin Kenny: One minor thing that's important to the Windows look-n-feel is a resize control at the southeast corner of a toplevel, overlaying the corresponding bit of the status bar.
http://wiki.tcl.tk/2988 might be a starting point. (D'oh! Just noticed that Jeff Godfrey beat me to it. Well, the point stands.)
Posted at Aug 17/2003 05:42 PM:
TFW: Although not a "widget", what about adding TkDND (or its functionality) to the core? What is required to get this working on OS-X (or is it)?
Posted at Aug 18/2003 08:45 AM:
Vince: TkDND doesn't work on OS X. What is required is someone to implement the appropriate C code to map tkdnd's functionality to the 'Drag manager' api on the Mac. I think this would be a very good idea.
Posted at Aug 18/2003 03:09 PM:
Tom Krehbiel: Althought not a "widget", the concept of "busy" needs to be added to Tk. A "busy" toplevel should cause the toplevel and its childern to display a busy cursor and discard all events.
Posted at Aug 18/2003 05:03 PM:
DKF: If you make a toplevel busy, you should be able to mark a widget (or widget hierarchy) as being unbusy, so you can have a Cancel button to click on...
Posted at Aug 27/2003 02:59 PM:
Ala: How about a Multiple Document Interface (MDI) where windows can be embedded within one another? A pure Perl Tk::MDI module does exist (although still a work in progress), but something native to Tk would be nice.
Posted at Aug 27/2003 06:57 PM:
Bryan Oakley: Almost all usability experts say that MDI is a bad way to write software. Microsoft, who pretty much pioneered this techique, rarely if ever uses this technique any more.
That being said, I suppose it's possible there's still a small set of programs where MDI makes sense, but I'd personally put this feature right at the very bottom of the priority list.
Posted at Aug 28/2003 01:11 AM:
DKF: I agree with Bryan. Let's just say that MDI is a feature I'd put low enough down that it's not likely to make the core cut-off point, though an extension (and probably a platform-specific one, given how hard it is to do right on some platforms) to do it is no problem with me.
Posted at Nov 13/2003 06:09 AM:
bryan schofield: I'm not sure that "New Widgets" is the best place to add this, but here it is. I'd like to see the concept of "actions" introduced in TK. It is often desirable to allow the user to do the same thing from multiple places, say a toolbar, a menu, and/or a button. Instead of crafting each widget manually it would be nice to create one action and
apply that action to menus, toolbars, and buttons. This could written in TCL and could be it's own package. The api might be something like this:
action create action ?options?
Creates a new action with the specified properties.
Options:
-text string
-tooltip string
-longtip string
-image image
-command script
-toolbarstyle image|imageandtext|text (default: image)
-menubarstyle image|imageandtext|text (default: text)
-buttonstyle image|imageandtext|text (default: imageandtext)
action configure action ?options?
Return or set properties of an action. Changes in properties are propogated to all widgets that the action has been applied.
action apply action widget ?widget ...?
Applies an action to a set of widgets. This will set the appropriate widget specific or menu item options such as "-text" for
buttons and "-label" for menu items.
action remove action widget ?widget?
Removes association between the action and the set of widgets.
action enable action
Enables all widgets and menu items associated with the action
action disable action
Disables all widgets and menu items associated with the action.
action delete action
Deletes the action (and any widgets or menu items that the action as been applied to)
Example
# create a new action with an image, text, help, and a command
action create myAction -image myImage -text "Some Text" -tooltip "Action!" -longtip "This is some action!" -command {myActionProc}
# create a menu, toolbar, and button to which we can apply
# our action
menu .m
button .b
toolbar .t
# apply our action and disable it
action apply myAction .m .b .t
action disable myAction
...
# ok, we are ready to allow the user to perform the action
action enable myAction
Bryan Oakley 14-Nov-2003 Weird. I've been coding "actions" for years in my apps for various companies, with virtually an identical API to the above (though my current implementation doesn't include the -*style options). Parallel development, or is
bryan schofield referring to my code (which I think I've occasionally mentioned in comp.lang.tcl)?
At any rate, they are a powerful way to write GUIs.
Posted at Nov 14/2003 06:46 PM:
bryan schofield: Not so weird after all :-P Actions are great and about the only thing I like about swing. I think they'd be great in tcl core, too. I've never noticed your mentioning of it, but, hey, that's no suprise, I don't read every message. The api I mentioned comes from a package I wrote a while back, but my evil employer, EG (name scrambled to protect the innocent), claims the code to be confidential and proprietary since it was written on their dime. My code is also missing the "-*style" options, but I thought if tcl were to get a
toolbar widget, it might be handy to be able to have some actions with image and text in the
toolbar.
Additionaly, a -type option my be handy accepting values of command, checkbutton, radiobutton, where command is the default and checkbutton and radiobutton type get -value and -variable options.
At the very least, perhaps Mr. Oakley's action package could make it into tcllib. That or I could write another, but that seems kinda silly being his appears to open already.
Bryan, do you think you could point to your code so that I might have gander?
Bryan Oakley - no, not at present. I have clearance from my boss to do so but haven't found the time. My current incarnation is a whopping 177 lines of code (with about 20% of that comments and whitespace). Over the years I've scaled back and streamlined what I think are the most useful features and taken out features I don't like. But that's an "internal-use-only" implementation; a public version would require more packaging and more error checking. But we're starting to drift off topic.
Posted at Jan 06/2004 05:16 PM:
Brian Griffin: I've just posted a rewrite of a toolbar and dockbar widget written in snit. The dockbar can make use of TIP #125 if present. This new widget can be had at
ftp://ftp.model.com/pub/tcl/toolbar01.tgz
Enjoy! Let me know what you think.
Posted at Jan 09/2004 07:47 AM:
David S. Cargo: Use toolbar02.tgz instead of 01. It fixes a problem found on Windows versions of Tcl.