iwidgets , or incr Widgets, is a set of megawidgets based on incr tcl and incr tk.

See Also

Learning Iwidgets


chiselapp project
Slightly modified iwidgets implementation for itk4. For changes see the iwidgets.patch file.
sourceforge project
hosts the CVS repository for iwidgets


In the early life of itcl/itk/iwidgets, they were all three distributed in the same source tar file.

During 2001, a TIP was submitted proposing that the incr tcl be included as an extension distributed with Tcl.

Now that this proposal is being implemented in Tcl 8.6, users will need to download the tcl, tk, itk, and iwidgets tar files to get the pieces to use iwidgets.

See incr Widgets for a list of the widgets included in the set. [What do we do about the cases below which overlap with widgets that already existed in Tk, etc.?] In the case of overlap, just update the associated page with info about each of the items, and the extension with which it is associated.

This package is part of the ActiveTcl Batteries Included distribution.

Paned Window


official reference
the example provided may be outdated and fail to work with the latest Tcl/Tk


Some users with iwidget panedwindows in their apps find that, when moving to Tk 8.4 , their applications are now generating syntax errors. This is because the Tk panedwindow and iwidgets panedwindow widgets use the same class - however, they don't have the same bindings.

Tom Silva writes on the itcl mailing list: I use this code-fix in panedwindow.itk, in the Panedwindow constructor, down near the bottom (just before "eval itk_initialize $args").

set btags [bindtags $itk_component(hull)]
if {[set ndx [lsearch -exact $btags Panedwindow]] >= 0} {
  bindtags $itk_component(hull) [lreplace $btags $ndx $ndx IPanedwindow]

Prompted by an observation by Bryan Oakley that, whereas

[winfo manager $w] forget $w

does what one want for $w-s managed by pack, place, and grid, but not for panedwindow, Joe English offered this "interesting solution":

set scratch [winfo parent $w].__temp__
pack $w in $scratch
pack forget $w
destroy $scratch 

SeS 2011-10-23:

I have been using the iwidgets panedwindow for some time now and it is also provided inside tG² since the Layout Editor's early conception/implementation. I have encountered a behaviour which is only observed in the iwidgets implementation of Panedwindow. It is the constant flickering of the child widgets of a panedwindow if the panedwindow is packed and the toplevel geometry is changed.

See for yourself:

Using Windows Vista, using wish.exe with $tcl_version 8.4, Iwidgets 4.0.2

package require Iwidgets
iwidgets::panedwindow .pw -width 200 -height 200
pack .pw
.pw add [frame .pane0]
.pw add [frame .pane1]
.pw add [frame .pane2]
.pw add [frame .pane3]
pack [button .pw.pane0.b -text test] -expand 1 -fill x
pack [button .pw.pane1.b -text test] -expand 1 -fill x
pack [button .pw.pane2.b -text test] -expand 1 -fill x
pack [button .pw.pane3.b -text test] -expand 1 -fill x

Now, resize the toplevel and pay close attention to the buttons we just created...the flickering becomes more severe with more embedded widgets. Do the same with the ttk panedwindow implementation in a fresh 'wish' and see the diff's:

panedwindow .pw -width 200 -height 200 -orient vertical
pack .pw
frame .pw.pane0; .pw add .pw.pane0
frame .pw.pane1; .pw add .pw.pane1
frame .pw.pane2; .pw add .pw.pane2
frame .pw.pane3; .pw add .pw.pane3
pack [button .pw.pane0.b -text test] -expand 1 -fill x
pack [button .pw.pane1.b -text test] -expand 1 -fill x
pack [button .pw.pane2.b -text test] -expand 1 -fill x
pack [button .pw.pane3.b -text test] -expand 1 -fill x

For some people, this flickering might be a minor thing, imo it is important to reduce such strange displaying just to provide the user a cool and relaxed GUI and if there is a chance to get rid of it I will certainly persuit it. One of the main reasons I recently added the ttk panedwindow implementation also to tG²'s layout editor. Should have done that in the first place, anyway, better late than never they say.

SeS 2011-10-23T1027CET: BTW, this observation will change from OS to OS and from PC to PC. Using Win7 & a different PC & monitor gives me almost unnoticable differences between the iwidgets & ttk panedwindow...


LV: Has anyone any experience using iwidgets with Tcl/Tk 8.5? I have gotten a report that widgets that used to be grey are now white and that the buttonplacement configuration parameter appears to be ignored for the distjointlistbox widget.

Here's a code example:

# ----------------------------------------------------------------------
#  DEMO: disjointlistbox in [incr Widgets]
# ----------------------------------------------------------------------
package require Iwidgets 4.0

iwidgets::disjointlistbox .dlb -buttonplacement center -lhslabeltext {Left Side} -rhslabeltext {Right Side}
pack .dlb -padx 10 -pady 10 -fill both -expand yes 

.dlb insertlhs {black white red blue yellow green magenta}

Run this code with a Tcl/Tk 8.4 system and iwidgets. The "left side" and "right side" buttons appear about the middle of the two listboxes. However, when I run this code with a Tcl/Tk 8.5 system (this is on SPARC Solaris), the left and right side buttons are aligned with the top of the two listboxes.

DKF: Since you need a new build of iwidgets with 8.5 anyway (because of forced changes to itcl due to VarReform) this should really be regarded as being a regression/bug in iwdgets itself. (Yes, I've got no idea what's wrong...)

LV: That's certainly where I started. I suspect, regardless of the Tk change that caused the behavior, you are right - there should be something in the test suite to test such a thing. I suspect the test suite has various things missing.

In the comp.lang.tcl thread leading to Tk but ticket 2062394, I think the reporter indicates the Tk behavior that led to this has to do with a change in the default gravity behavior of grid that is being used in the widget. But I may be wrong. And I have no idea if the change was intentional or not...

In comp.lang.tcl, Uwe writes about what appears to be the cause of this [L1 ] - a change in the default behavior Tk 8.5's grid command. He has filed a trouble ticket on the Tk issue (ticket 2062394) as well as posted this work around for iwidget's disjointlistbox to be used in the meantime.

Here is a patch for disjointlistbox:

*** pkg/iwidgets4.0.2/scripts/disjointlistbox.itk       Tue Aug 12
--- new/iwidgets4.0.2/scripts/disjointlistbox.itk       Wed Aug 20
*** 462,467 ****
--- 462,470 ----
                  grid configure $itk_component(bbox) \
                          -in $itk_interior -row 0 -column 1 - columnspan 1 \
                                  -sticky nsew
+                 # Tk8.5: enforce compatibility to previous versions
+                 # see Tk-ticket 2062394
+                 catch {grid anchor $itk_component(bbox) center}

                  grid configure $itk_component(rhsbutton) \
                          -in $itk_component(bbox) -row 0 -column 0 - sticky ew 

LV: This patch now looks to me to be a part of the current iwidgets sf.net cvs repository. That's great!

Also, for those of you following along at home, the same developer who asked me about this also reported as a difference the fact that his application, which previously was blue with this widget having a gray background, now is blue with this widget having a white background. At least one other developer also mentioned this, wondering if he was doing something wrong.

In our environment, upgrading the software is looked upon most kindly when users see no difference other than a difference intentionally coded in the application code itself. On comp.lang.tcl, I've had two suggestions for our developers - read up on option, options, and listbox, to see how to make use of the option command to set colors, or, somewhat hesitantly mentioned, tk::classic::restore.

CF 2009-03-10: Has anyone tried running iWidgets examples on Linux with display on a Windows box via Cygwin/XWin, along with the Windows-based window manager (i.e. XWin -multiwindow)? The iwidgets::combobox, in particular, is rendered unusable when -dropdown is true, since the box appears to be visibly 'chopped off' when the drop-down button is clicked, making it difficult to make any selections. This doesn't occur when running separately in either Windows or Linux, or when the multiwindow option is turned off...

LV 2010-06-09: I can confirm seeing the same behavior. I've opened a ticket at the itcl sf.net project site, but since there doesn't appear to be much action there, I don't know if it will do any good. We have found that if the program displaying this problem runs under Putty, or as you mention, in the cygwin x full screen mode, the problem does not exhibit itself. I've asked in various places for help finding a work around, but so far have been unsuccessful. Note that in a June 2010 thread on comp.lang.tcl, another Tcl developer mentioned he sees the same thing, with a very recent version (March 2010) version of cygwin x, so whatever the issue is, it continues to exhibit itself.