Version 25 of Iwidgets

Updated 2015-06-13 19:31:49 by juef

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 [Radical reform of the execution
engine%|%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: <patch> *** pkg/iwidgets4.0.2/scripts/disjointlistbox.itk Tue Aug 12 11:56:03 2003 --- new/iwidgets4.0.2/scripts/disjointlistbox.itk Wed Aug 20 16:47:34 2008


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
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,


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 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