KWWidgets/FAQ

From KitwarePublic
< KWWidgets
Revision as of 13:06, 29 April 2008 by Barre (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

General Information

What is KWWidgets

KWWidgets is a free, cross-platform and open-license GUI Toolkit. It provides low-level core widgets, advanced composite widgets, and high-level visualization-oriented widgets that can be interfaced to visualization libraries like VTK. KWWidgets is an object-oriented C++ toolkit that can interact and co-exist with Tcl/Tk directly from C++. It is wrapped automatically into a Tcl package or Python module, and can therefore be used directly from Tcl/Tk or Python, allowing for fast-prototyping and scripting.

For more information, see http://www.kwwidgets.org

Where can I download KWWidgets?

http://www.kwwidgets.org/Wiki/KWWidgets/Download

Is there a roadmap?

http://www.kwwidgets.org/Wiki/KWWidgets/Roadmap

I have a question! What should I do?

Refer to the page describing how to contact us for questions and feedback. Feel free to add specific inquiries or problems in the discussion section available from each page in this Wiki.

I found a bug! What should I do?

Report the bug in our bug tracker: http://www.kwwidgets.org/Bug.

Please make sure to look at the old bugs to avoid duplicates, pick the appropriate "Severity" field, and include detailed instructions of the bug and how to reproduce it. Also feel free to assign it to Sebastien Barre for the moment.

I want a new feature in KWWidgets. What should I do?

Report a feature request in our bug tracker: http://www.kwwidgets.org/Bug. Change the "Severity" field to "Feature Request".

Please make sure to look at the old feature requests to avoid duplicates, and include detailed instructions of the feature and proposed implementation, if any. Also feel free to assign it to Sebastien Barre for the moment.

Can I contribute code or bug fixes?

We encourage people to contribute bug fixes as well as new contributions to the code. We will try to incorporate these into future releases so that the entire user community will benefit from them.

What's the best way to learn KWWidgets?

Make sure you check the examples page: http://www.kwwidgets.org/Wiki/KWWidgets/Examples

Also, feel free to download the distribution, compile the examples and study the source code. The API is documented here: http://www.kwwidgets.org/doc/nightly/html

Why should I use KWWidgets instead of Qt, MFC or wxWidgets?

It comes down to a few basic issues including widget set features, the license, documentation, and supporting tools. Qt, MFC and wxWidgets are arguably well featured; they have been in development for years and they already have a large user-base. While Qt still requires a commercial license for proprietary software, KWWidgets adopts a much less restrictive BSD-style license with no such limitations. Most toolkits provide more or less the same core widget set. KWWidgets, on the other hand, is targeted at scientific and medical visualization. While it provides both core widgets as well as advanced composite widgets, KWWidgets provides sophisticated interface to the visualization library VTK, offering high-level 2D and 3D visualization-oriented widgets such as surface material editors, simple animation generators, transfer function editors, annotation editors, window/level and volume property preset editors, text property editors, 2D and 3D rendering widgets, etc. To create these high-level widgets with a 2D widget set such as Qt requires significant effort, not to mention inherent expertise with VTK. Thus if you are interested in 3D graphics and visualization applications using VTK, then KWWidgets are likely your best bet.

Compilation

Borland Linker complains about invalid OMF record! Why?

This problem occurs when you are trying to link to a third-party library that is not in a format the Borland Linker can understand. For example, the Python distribution for Windows is likely to trigger the following error:

Linking C executable ..\bin\vtkWrapPython.exe
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: 'C:\PYTHON2.4\LIBS\PYTHON24.LIB' contains invalid OMF record, type 0x21 (possibly COFF)

The solution to this issue is to generate a Borland compatible OMF import library from the original import library using Borland's coff2omf tool. For example, this will create a Borland compatible OMF import library python24omf.lib out of the original python24.lib:

coff2omf python24.lib python24omf.lib
COFF to OMF Converter Version 1.0.0.74 Copyright (c) 1999, 2000 Inprise Corporation

Once the Borland compatible library has been created, make sure you set the corresponding CMake variable accordingly (say, for example PYTHON_LIBRARY=c:\python2.4\libs\python24omf.lib), and re-configure/re-build the project if necessary.

If this approach still fails with "Unresolved external" references, try creating the OMF import library directly from the original DLL/shared/OCX library using Borland's implib tool. For example:

 implib c:\htmlhelpomf.lib c:\WINNT\system32\hhctrl.ocx

Note that this will only work on import libraries, not static libraries.

Borland Linker complains about htmlhelp.lib! Why?

KWWidgets does not require the Microsoft HTML Help Library (htmlhelp.lib) to build but will search for it in order to provide some minor additional functionalities (like online help). Even if you are not using a Microsoft compiler, it is likely that a default HTML Help Library is already installed on your system, and KWWidgets is likely to find it. The problem is that the default htmlhelp.lib file is not in a format that the Borland Linker can understand. The solution to this issue is to generate a Borland compatible OMF import library, by using Borland's implib instead (not coff2omf). For example, on Windows 2000 Pro:

  implib c:\htmlhelpomf.lib c:\WINNT\system32\hhctrl.ocx

Note that the path to hhctrl.ocx may be different for other Windows version (c:\WINDOWS for example). Once the Borland compatible OMF import library htmlhelpomf.lib has been created, make sure you set HTML_HELP_LIBRARY accordingly (say, for example HTML_HELP_LIBRARY=c:\htmlhelpomf.lib). Be aware that coff2omf will not work to convert this library.

Can I build KWWidgets from Cygwin?

As of February 2006, we managed to build both VTK and KWWidgets under Cygwin. Sadly, they both would either behave in very unexpected ways or die horribly. We suspect issues with Cygwin's Tcl/Tk libraries. No further support for Cygwin has been scheduled, but let us know if it is a concern.

Note that you can use KWWidgets from a Cygwin shell without any problem though. KWWidgets even creates both a KWWidgetsSetupPaths.sh and KWWidgetsSetupPaths.csh script in your KWWidgets binary directory so that you can setup the proper runtime environment variables very easily.

CMake Error: File vtkWrapperInit.data.in does not exist

This problem is likely to happen if you downloaded an "old" version of VTK 5.0. As of today, the VTK 5.0 distribution can be downloaded as an archive file, but we recommend you retrieve the VTK-5-2 CVS branch directly from the CVS repository instead, until VTK 5.2 is available as an archive file. This error, which prevented an installed VTK to be used properly, was fixed later on the 5.0 CVS branch and subsequent versions. Please download VTK 5.2 (or VTK 5.0) from CVS again or contact us if the problem persists.

LOAD_COMMAND Attempt to load command failed from file : libcmVTK_WRAP_TCL2.so

If you get

CMake Error: Error in cmake code at
/local/packages/vtk/install/lib/vtk-5.0/CMake/vtkLoadCMakeExtensions.cmake:7:
LOAD_COMMAND Attempt to load command failed from file : libcmVTK_WRAP_TCL2.so

This means you downloaded VTK 5.0 from an archive file (tarball). This bug has been fixed in the meanwhile, but the archive file has not been refreshed; please download VTK 5.0 from the CVS repository (VTK-5-0 tag) or use VTK 5.2:

cvs -d :pserver:anonymous@public.kitware.com:/cvsroot/VTK checkout -r VTK-5-2 VTK

Runtime

KWWidgets complains a DLL was not found! Where is it?

This message is triggered when an executable that uses the VTK or KWWidgets libraries fails to find the libraries it depends on. On Windows platforms, you need to update the PATH environment variable to specify where the operating system should search for libraries (DLLs). The PATH variable is a semi-colon separated set of paths on Windows platform, colon-separated on Unix, Linux or Cygwin platforms; you should add both the VTK and KWWidgets build directories to this list. It is probably a good thing to add the PATH to your Tcl/Tk binary directory too, if it was not done by your Tcl/Tk installer already. For example:

SET PATH=%PATH%;C:/Tcl-build/bin
SET PATH=%PATH%;C:/VTK-build/bin/Debug
SET PATH=%PATH%;C:/KWWidgets-build/bin/Debug

or for Unix/Linux/Cygwin:

export PATH=$PATH:/home/barre/Tcl-build/bin
export PATH=$PATH:/home/barre/VTK-build/bin
export PATH=$PATH:/home/barre/KWWidgets-build/bin

Since you may want to work with different version of VTK and KWWidgets installed on your system, it may not be practical to update your PATH in a permanent way. To solve this problem, we recommend you store the above lines in a separate batch file (say, setup.bat on Windows, setup.sh on Unix/Cygwin) and execute that batch file on the command-line each time you need to work with a specific VTK/KWWidgets combination. You actually do not even have to write it, since KWWidgets created one just for you: look for the KWWidgetsSetupPaths.bat or KWWidgetsSetupPaths.sh script in your KWWidgets binary directory, and run it!

Tcl complains it can not find the kwwidgets package! Where is it?

This message is triggered when a Tcl script that uses the KWWidgets (or VTK) packages fails to find the packages and/or libraries it depends on:

 "Can't find package kwwidgets while executing 'package require kwwidgets'"

On Windows platforms, first make sure the path to the VTK and KWWidgets libraries are known to the operating system (see the corresponding FAQ). The next step is to help the Tcl shell find the KWWidgets or VTK packages. The standard way to do so is to update the TCLLIBPATH environment variable to specify where Tcl should search for KWWidgets' or VTK's pkgIndex.tcl files. The TCLLIBPATH variable is a space separated (forward-slash) set of paths; you should add both the VTK and KWWidgets path to the Wrapping/Tcl subdir (located in your build directories) to this list. For example:

SET TCLLIBPATH=%TCLLIBPATH% "C:/VTK-build/Wrapping/Tcl/Debug"
SET TCLLIBPATH=%TCLLIBPATH% "C:/KWWidgets-build/Wrapping/Tcl/Debug"

or for Unix/Linux/Cygwin:

export TCLLIBPATH="$TCLLIBPATH \"/home/barre/VTK-build/Wrapping/Tcl\""
export TCLLIBPATH="$TCLLIBPATH \"/home/barre/KWWidgets-build/Wrapping/Tcl\""

Since you may want to work with different version of VTK and KWWidgets installed on your system, it may not be practical to update your TCLLIBPATH in a permanent way. To solve this problem, we recommend you store the above lines in a separate batch file (say, setup.path or setup.sh) and execute that batch file on the command-line each time you need to work with a specific VTK/KWWidgets combination. You actually do not even need to write it, since KWWidgets creates one just for you: look for the KWWidgetsSetupPaths.bat or KWWidgetsSetupPaths.sh script in your KWWidgets binary directory, and run it!

The procedure entry point _TkWinChildProc@16 could not be located! Why?

This kind of error usually happens when a project is built against a specific Tcl/Tk library (used internally by KWWidgets), but a different version/flavor of that library is picked at run time by the operating system. Make sure your environment variables are set properly (especially the PATH variable). Have a look at the other FAQ entries in this "Configuration" section, they deal with similar problems too. When you configure VTK, KWWidgets, or your own project with CMake, make sure all the Tcl/Tk variables are consistent and point to the same version/flavor of the Tcl/Tk library (TCL_TCLSH, TCL_LIBRARY,TK_LIBRARY, TK_WISH).

Python complains it can not find the kwwidgets module! Where is it?

This message is triggered when a Python script that uses the KWWidgets (or VTK) modules fails to find the modules and/or libraries it depends on:

   from kwwidgets import *
      ImportError: No module named kwwidgets

On Windows platforms, first make sure the path to the VTK and KWWidgets libraries are known to the operating system (see the corresponding FAQ). The next step is to help the Python shell find the KWWidgets or VTK modules. The standard way to do so is to update the PYTHONPATH environment variable to specify where Python should search for KWWidgets' or VTK's module files. The PYTHONPATH variable is a semi-colon separated set of paths on Windows platform, colon-separated on Unix, Linux or Cygwin platforms; you should add both the VTK and KWWidgets path to the build directories and Wrapping/Python sub-directories (located in your build directories) to this list. For example:

SET PYTHONPATH=%PYTHONPATH%;C:/VTK-build/Wrapping/Python/Debug;C:/VTK-build/bin/Debug
SET PYTHONPATH=%PYTHONPATH%;C:/KWWidgets-build/Wrapping/Python/Debug;C:/KWWidgets-build/bin/Debug

or for Unix/Linux/Cygwin:

export PYTHONPATH=$PYTHONPATH:/home/barre/VTK-build/Wrapping/Python:/home/barre/VTK-build/bin
export PYTHONPATH=$PYTHONPATH:/home/barre/KWWidgets-build/Wrapping/Python:/home/barre/KWWidgets-build/bin

Since you may want to work with different version of VTK and KWWidgets installed on your system, it may not be practical to update your PYTHONPATH in a permanent way. To solve this problem, we recommend you store the above lines in a separate batch file (say, setup.path or setup.sh) and execute that batch file on the command-line each time you need to work with a specific VTK/KWWidgets combination. You actually do not even need to write it, since KWWidgets creates one just for you: look for the KWWidgetsSetupPaths.bat or KWWidgetsSetupPaths.sh script in your KWWidgets binary directory, and run it!

A TkRenderWidget is being destroyed before it associated vtkRenderWindow

Generic Warning: In /VTK/Rendering/vtkTkRenderWidget.cxx, line 616
A TkRenderWidget is being destroyed before it associated vtkRenderWindow is destroyed.
This is very bad and usually due to the order in which objects are being destroyed.
Always destroy the vtkRenderWindow before destroying the user interface components.

This usually happens when reference counting prevents a vtkRenderWindow from being deleted properly (i.e. before the vtkTkRenderWindget that is using it). Try to check that all your objects were deleted properly (a call to Delete(), or use smartpointers), and build VTK with VTK_DEBUG_LEAKS turned ON to make sure leaks are reported upon exit.

Setting your vtkKWRenderWidget's parent to NULL before deleting it may also do the trick, depending on how you allocated and cross-refenced your objects. See Patrick D. Emond's useful post in the KWWidgets Mailing List archive for more details.

Testing

Is there a dedicated dashboard for KWWidgets that I can submit tests to?

The KWWidgets dashboard reports how successfully KWWidgets compiled and tested on many different platforms and compilers every day. If it is mainly "green", the project is in good shape. If there is a lot of "red", you may want to make sure your changes did not break anything, or check the dashboard in a day or two if you were going to download the source code. You can also browse the dashboard back in time and checkout the CVS repository at that specific point.

If you are familiar with CMake and CTest, the best way to submit a dashboard is to write a CTest script (say, kwwidgets_gcc.cmake) to drive every stage of the build and test process. Look in the dashboard for machines that display a small 'note' icon next to their 'Build Name': this should provide a link to the CTest script that was used for this specific submission.

Please note that for the tests to pass successfully you have to make sure the operating system can find all dependent libraries (i.e. VTK, Tcl/Tk, KWWidgets), as well as the corresponding Tcl packages and/or Python modules for the Tcl and Python tests. The best way to do so is to check the Configuration FAQ, and eventually run/source the KWWidgetsSetupPaths script located in your KWWidgets build directory before running the tests. Modifications made to the PATH, TCLLIBPATH or PYTHONPATH environment variables can be reflected in a CTest script by setting the CTEST_ENVIRONMENT CMake variable, or by sourcing/including the KWWidgetsSetupPaths.cmake script that is generated automatically at build time.

Documentation

The documention mentions a class that is not in the source code! Where is it?

First of all, check that the documentation or the examples you are looking at match the version of KWWidgets you downloaded. The KWWidgets API is automatically generated on a nightly basis: if the class does not show up in this document, then it is likely it was removed or renamed a short while ago. Be aware though that some classes listed in the API are not in the source code but are generated automatically from a set of templates; for more information, check the corresponding "Auto-Generated Classes" section in the online API.

Usability

I want the UI to remain responsive while I'm doing something else

Here is scenario: "I am trying to create a simple application where a user clicks a button and the application would have a series of output to the render window. I would like to make the UI remain responsive (for example, the user can click the stop button to stop the "animation"/series of output). How do I do that ?".

This situation is actually demonstrated in the Polygonal Object Viewer example located in either the Examples/Cxx or Examples/Tcl directory (pick your favorite language). If you build KWWidgets and its examples as well, you should be able to run this example and check how it is working: the left panel uses a vtkKWSimpleAnimationWidget objet that allows you to setup a very simple camera animation. You can hit "play", and stop the animation at any time. How this is done technically can be found in the vtkKWSimpleAnimationWidget's PerformCameraAnimation() or PerformSliceAnimation() methods. Remember that a KWWidgets application is usually started by calling vtkKWApplication's Start() method, say:

       app->Start();

this actually enters a loop that will process user interaction events, and stay there until all windows are closed. Now while the animation is performed, the application is given a chance to process pending events so that the user can still interact with the UI. This is done by calling the ProcessPendingEvents() method. For example, from vtkKWSimpleAnimationWidget:

     this->GetApplication()->ProcessPendingEvents();

Layout

I can't pack render widgets next to each other! What's the trick?

At the moment, you still need to use either Tk's pack or grid to setup the layout of your widgets. In the specific case of the vtkKWRenderWidget class, stay away from pack and use the grid manager. The following code creates 3 render widgets in the vtkKWFrame $frame1, place them on top of each other and allow them to expand freely.

set rw1 [vtkKWRenderWidget New]
$rw1 SetParent $frame1
$rw1 Create
$rw1 SetRendererBackgroundColor 1.0 0.0 0.0

set rw2 [vtkKWRenderWidget New]
$rw2 SetParent $frame1
$rw2 Create
$rw2 SetRendererBackgroundColor 0.0 1.0 0.0

set rw3 [vtkKWRenderWidget New]
$rw3 SetParent $frame1
$rw3 Create
$rw3 SetRendererBackgroundColor 0.0 0.0 1.0

grid [$rw1 GetWidgetName] -column 0 -row 0 -sticky news
grid [$rw2 GetWidgetName] -column 0 -row 1 -sticky news
grid [$rw3 GetWidgetName] -column 0 -row 2 -sticky news

grid columnconfigure [$frame1 GetWidgetName] 0 -weight 1

grid rowconfigure [$frame1 GetWidgetName] 0 -weight 1
grid rowconfigure [$frame1 GetWidgetName] 1 -weight 1
grid rowconfigure [$frame1 GetWidgetName] 2 -weight 1

Note that each one is placed on the same column 0 but on a different row, to form a grid-like layout. The -sticky option is a combination of any 'n', 'e', 'w', 's' letters, which specifies against which border(s) the widget should expand if its parent allows it to: 'n' (north), 'e' (east), 'w' (west), and/or 's' (south). Once each widget is placed in the grid, each column and row can be configure independently to expand or not, by specifiying a weight. The default weight is 0 and won't allow any cell in the grid to expand. Set all weights to 1 so that all the rows expand freely. Same for the columns. You can use 0.5 to specify that a specific row or column should expand but use half of the available space compared to the other rows/columns that are set to 1.

Transfer Function Editors

In a small editor, many different elements overlap! How can I avoid that?

The transfer function editors (subclasses of vtkKWParameterValueFunctionEditor) provide a wide range of functionalities but can be intimidating at first given the number of methods that can be used for customization. While the default settings should be good enough for most users, tighter situations may require to tweak the editors in order for all elements to show up without overlapping. The position and visibility of almost all elements can be changed; the best way to do so is to experiment with methods that follow the Set...Position() and Set...Visibility() patterns. For example, the title label on top of the editor can be moved using SetLabelPosition() and hidden using SetLabelVisibility(). The label displaying the parameter and value ranges can be moved using SetRangeLabelPosition() and hidden using SetParameterRangeLabelVisibility() and/or SetValueRangeLabelVisibility(). The entries displaying the value of the selected point (say, its color), can be moved using SetPointEntriesPosition() and hidden using SetPointEntriesVisibility() and/or SetParameterEntryVisibility(). Do not forget to check the superclass and subclasses documentation too. A good way to play with the editors is to to create a small Tcl script and create a transfer function editor inside a vtkKWWindow; head to the 'Window' menu and select 'Command Prompt': this will pop up a Tcl shell where you can interactively modify the transfer function editor object in real time, without re-compiling any code.

3D Visualization

Why can't I add the same actor to two render widgets?

set rw1 [vtkKWRenderWidget New]
[...]

set rw2 [vtkKWRenderWidget New]
[...]

set cone [vtkConeSource New]

set pdm [vtkPolyDataMapper New]
$pdm SetInput [$cone GetOutput]
set actor [vtkActor New]
$actor SetMapper $pdm

$rw1 AddViewProp $actor
$rw2 AddViewProp $actor

The above code won't work. You will likely end up with one render widget displaying the actor, while the other will remain empty. This is a "property" of VTK, the underlying visualization toolkit, not KWWidgets (the call to AddViewProp simply triggers the eponymous method on the render widget's internal vtkRenderer). A simple solution to this problem is to create two actors. An actor does not "cost" much in terms of memory. It is a good practice to create separate mappers too, one for each actor. It is perfectly legal for different mappers to share the same input data though.

[...]

set cone [vtkConeSource New]

set pdm1 [vtkPolyDataMapper New]
$pdm1 SetInput [$cone GetOutput]
set actor1 [vtkActor New]
$actor1 SetMapper $pdm1

set pdm2 [vtkPolyDataMapper New]
$pdm2 SetInput [$cone GetOutput]
set actor2 [vtkActor New]
$actor2 SetMapper $pdm2

$rw1 AddViewProp $actor1
$rw2 AddViewProp $actor2

Third-Party Libraries Support

SOViewer

How can I insert a SOViewer inside a KWWidgets interface?

SOViewer is a powerful package that can be used to visualize ITK's Spatial Object hierarchies. Since it is faily independent of any user interface toolkit, it is quite easy to use SOViewer capabilities inside a KWWidgets application. All you need to do is create a 3D scene using a vtkKWRenderWidget object, and instruct it to use SOViewer's rendering routines. This will work just fine since SOViewer creates geometrical representation of ITK Spatial Object using VTK objects, which vtkKWRenderWidget understands natively. Note that this approach only works from C++ for the moment, and is explained in much more details in the SOViewer example (C++ code).

Let's first create a 3D scene using KWWidget's vtkKWRenderWidget (provided that parent points to a valid widget):

  vtkKWRenderWidget *rw = vtkKWRenderWidget::New();
  rw->SetParent(parent);
  rw->Create();
  ...

Now let's create a SOViewer renderer, and instruct our render widget to remove all its internal renderers and use the one provided by SOViewer:

  sov::VTKRenderer3D::Pointer sov_renderer = sov::VTKRenderer3D::New();
  rw->RemoveAllRenderers();
  rw->AddRenderer(sov_renderer->GetVTKRenderer());

You are done! Feel free to create Spatial Objects, add them to a scene, and let SOViewer process that scene. Do not forget to call the Update() method on the SOViewer renderer to transform the Spatial Objects into their VTK geometrical representations:

  itk::CylinderSpatialObject::Pointer cylinder = 
    itk::CylinderSpatialObject::New();
  itk::SceneSpatialObject<3>::Pointer scene = 
    itk::SceneSpatialObject<3>::New();
  scene->AddSpatialObject(cylinder);
  sov_renderer->SetScene(scene);
  sov_renderer->Update();

  rw->Render();

Cross-Plaform Issues

Mac OS X with default Tcl/Tk Aqua

If you are a Mac OS X user, we strongly recommend you download your own Tcl/Tk distribution and compile it to run in X11 mode (check "Configuring and Running X11 Applications on Mac OS X" for more information about X11). The default Tcl/Tk was built to run in Aqua/Carbon mode, and is not behaving properly:

I can't change the color of the buttons! Why?

If you create a vtkKWPushButton widget and try to change its background color using SetBackgroundColor, you will notice that the color will not change. This is not a KWWidgets bug, but an issue with the Tcl/Tk library that is installed on MacOS (Tcl/Tk 8.4.7 as of MacOS 10.4, up to 8.4.12 as of today). This specific Tcl/Tk distribution maps Tk buttons to Aqua buttons, which color can't be changed from Tk. This is not a critical issue since changing the background color of a button is neither very common nor very recommended. For a workaround, check the KWWindowWithPanelsExample example (Tcl code / C++ code). This issue was tracked in this bug entry.

I can't put an image in a menu! Why?

If you create a vtkKWMenu widget and try to put an image entry in this menu using SetItemImage (or any other method in a different class that intends to add an image to a menu), you will notice that the image will not be displayed. This is not a KWWidgets bug, but an issue with the Tcl/Tk library that is installed on MacOS (Tcl/Tk 8.4.7 as of MacOS 10.4, up to 8.4.12 as of today). This specific Tcl/Tk distribution does not support image in menus, and will display an ugly "<Image>" label instead, discarding the current label entry, if any. KWWidgets work around this problem by not trying to set the image for this entry, so that the entry label will at least still show up. This issue was tracked in this bug entry.

The tooltips grab the focus and make my window flicker! Why?

If you associate a tooltip (or balloon help) to any widgets using the vtkKWWidget::SetBalloonHelpString method, you will notice that the tooltip will indeed popup when you hover on this widget, but the corresponding mini-window will grab the focus as the same time, triggering an annoying flickering effect on the main application window as it loses its focus. This is not a KWWidgets bug, but an issue with the Tcl/Tk library that is installed on MacOS (Tcl/Tk 8.4.7 as of MacOS 10.4, up to 8.4.12 as of today). Raising a toplevel seem to actually give the focus to it, which does not happen in any other Tcl/Tk port. The bug has been reported back in 2003, and has not been fixed. It can be reproduce from Tk using:

label .foo -text "Move the mouse over this label"
pack .foo
toplevel .bar
bind .foo <Enter> {raise .bar}

There is no workaround to this problem, except turning off the tooltips/balloon help feature from the "Application Settings" dialog that can be found under the "View" menu if your application is based on a vtkKWWindow. This issue was tracked in this bug entry.



KWWidgets: [Welcome | Site Map]