'''[http://incrtcl.sourceforge.net/iwidgets/iwidgets.html%|%iwidgets]''', or
[incr Widgets], is a set of megawidgets based on [incr tcl] and [incr tk].
** See Also **
* [Learning Iwidgets]
** Development **
[http://chiselapp.com/user/rene/repository/iwidgets/index%|%chiselapp project]: Slightly modified iwidgets implementation for itk4. For changes see the iwidgets.patch file.
[http://sf.net/projects/incrtcl/%|%sourceforge project]: hosts the [CVS] repository for iwidgets
** Description **
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 **
Docs can be found at
http://incrtcl.sourceforge.net/iwidgets/iwidgets/panedwindow.html (''the
example provided may be outdated and fail to work with the latest Tcl/Tk'') and
http://purl.org/tcl/home/man/iwidgets3.0/panedwindow.n.html
[http://incrtcl.sourceforge.net/iwidgets/iwidgets/panedwindow.gif]
----
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
'''pack'''ed 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...
** Discussion **
[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
[http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/86590035a1030c71#]
- 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
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 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.
<> Package | Object Orientation | Widget | Itcl