From KitwarePublic
< KWWidgets
Revision as of 16:24, 10 January 2008 by Barre (talk | contribs) (TODO)

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


This page documents the short- and long- term items scheduled for the KWWidgets project. A lot of work has already been done cleaning-up and restructuring KWWidgets to turn it into an independent project (more details can be found in the first cleanup page). This page lists the remaining items and current priorities with respect to the NA-MIC/3D Slicer projects as well as Kitware's own internal projects.


GUI Testing, Tracing

  • Quoting Steve Pieper (see Engineering:Project:Slicer3.0): "ParaView has KWWidgets-based 'trace' mode to store GUI interactions to facilitate batch testing and demos -- similar functionality in slicer would be great, but some architecture work will be needed.".
  • Quoting Ron Kikinis: "The automatic testing capability that kww will enable, appears to me to be more and more important, the more I think about it. As a matter of fact, automatic testing of entire sequences of mouse clicks and keyboard strokes will enable us to move to a different level robustness with slicer 3.0.".

The demand for a GUI Testing framework is definitely acknowledged. Suggestions, discussions and specifications related to that topic are now in the GUI Testing page.

New Widgets

  • Quoting Steve Pieper: "In terms of priority items one thing I could think of is a registration inspection widget, or maybe better stated a multi-volume compositing viewer. Right now in slicer we can do a cross-fade between two volumes and scroll through them, but we haven't enabled the checkerboard display. I can imagine a widget with three linked image viewers (fixed, moving, merged) where you can select the merge type as a blend with adjustable fade or various parameters for a checkerboard (simple vertical or horizontal wipe, or 4x4 etc).". We could definitely create a new vtkKWImageWidget render widget that would allow for image/volume browsing through a VTK vtkImageViewer2, in a simpler way than what was done in our KWWidgetsPro/vtkKWImageWidget. This widget could accept a secondary input and several blending modes. Later on, we could add Will's new VTK widgets: one is a checkerboard interactor that lets you resize the checkerboard using handles on its sides, and the other performs a rectilinear wipe or a checkerboard wipe (i.e. a 2x2 checkerboard where you can interactively move the center point to reveal more or less of one of the image, etc).
  • Quoting Steve Pieper: "Another thing I've always wanted to see are camera control widgets that tie into the interactors. You could have spinners for each of the view parameters, but also presets (slicer has a rendered head with text buttons for preset views). It could also have toggles for trackball vs other interaction styles.". The camera preset concept is actually almost there in ParaView's vtkPVCameraIcon class or ParaView's Lookmarks, see what can be done with it.
  • Quoting Steve Pieper: "Another one that Atilla Tanacs hacked together in slicer is a dicom browser that shows you thumbnails of the images. It's kind of clumsy but it's useful. A better version of that would be cool.". Work has been started in that direction by Sylvain Jaume. I (Sebastien) wrote some internal specs that I will move to this Wiki at some point.

Interface to ITK

  • A tree-like inspector for itkSpatialObject, that will display the scene-graph as well as some parameters.

Better Look & Feel

  • Simple theming was achieved by introducing the vtkKWTheme and vtkKWOptionDataBase classes that allow for simple branding/theming, as much as the current Tk can support without Tile. Check the Examples/Cxx/Theme example. More documentation to follow. Tcl/Tk 8.5 with full Tile support was recently released (January 2008), and could be re-evaluated for full theming support and better MacOSX look&feel.

Layout Manager

We should create a Packing/Layout manager. Most of the remaining explicit calls to Tk in the KWWidgets C++ library are used to pack/grid the widgets inside each other (app->Script("pack %s", cb->GetWidgetName());). We should create an abstract vtkkWWidgetLayoutHelper class, and add a (lazy-evaluated) instance of this helper to vtkKWWidget. Widgets could be added/removed/configured in the layout object, and this helper would be responsible for calling Tk to realize the corresponding layout automatically. Concrete subclasses of this helper would implement the pack/grid/place Tk layouts (say, vtkkWWidgetLayoutPackHelper, etc.). Developers could create new helper subclasses and assign them to the vtkKWWidget instance. Suggestions, discussions and specifications related to that topic are now in the layout manager page.

Resource manager

Images and icons are incorporated into the code by converting them into a compilable form (basically an array of pixels declared in a header file) and reading the pixels at run-time. The whole process: storing the resources in a directory, listing them in a batch file that will convert them into a header, using the proper API to read the pixels back, working around header file size limit, etc., is a pain. A vtkKWResourceManager class should be created to abstract the whole framework. Suggestions, discussions and specifications related to that topic are now in the resource manager page.

API cleanups

  • The vtkKWEvent class enumerates event that are used in PV, VV, and many other projects. We should probably move them out to their own vtkVVEvent/vtkPVEvent class, eventually by numbering them starting from 1000, 2000, etc. At the moment, only 200 events are listed in vtkKWEvent, therefore 1000 events per project seems pretty reasonable. It seems that VV is the only project using the vtkKWEvent::GetEventIdFromString method, which explores VTK's vtkCommand event-space too. A vtkVVEvent::GetEventIdFromString would have to call vtkKWEvent::GetEventIdFromString too.
  • vtkKWScale and vtkKWThumbWheel are doing more or less the same kind of interaction, both API should be in sync, i.e. no DisplayLabel vs DisplayLabelOn, DisplayEntry vs DisplayEntryOn, SetLength/SetWidth, etc.
  • vtkKWListBox, vtkKWComboBox (and eventually vtkKWMenu) should probably have a unified API to add/remove/query the items (one use Value(s), another Item(s), another Entry(ies))

Widgets Improvments

Hiding dependencies to Tk

  • Get rid or isolate most low-level calls to Tk. KWWidgets is a library on top of Tk; dependencies to Tk can not be totally removed, but we can try to hide most low-level calls. Part of this cleanup has already been done by creating a vtkKWCoreWidget class, parent of all C++ classes that abstract core Tk widgets. Other low-levels calls should be tracked (search for this->Script(...)) and replaced by the proper C++ API. Many calls are used to get the geometry of widgets or the screen, i.e. calls to 'wm' (geometry, deiconify, overrideredirect, withdraw, iconname, protocol, transient, title) or 'winfo' (pointerx, rootx, width, reqwidth), or other various commands ('after', 'raise', 'bind', 'focus', 'update'). We could abstract those calls in vtkKWTkUtilities (something like GetScreenWidth, GetScreenHeight, etc.)
  • Expand the vtkKWCanvas class. The Tk canvas widget is an important source of explicit low-level calls to Tk. The vtkKWCanvas class could abstract those calls, even though there would be a significant amount work involved here since the Tk canvas is a faily complex and full-featured beast (not that we need all functionalities though).
  • Include the Tk support lib in the binary. Each binary built on KWWidgets has to be bundled with the Tcl/Tk dll, unless it is linked against the static Tcl/Tk libs. In both cases, the Tcl/Tk support libraries have to be packaged too, in the form of a hundred of small scripts that are copied, installed and initialized from the Tcl/Tk distribution (see lib/). We used to concatenate them inside a big header file, #include that file and rely on some other hacks to solve that problem, but it was a pain to maintain. Yet, now that Tcl/Tk is more stable, and that CMake is more powerful, we could investigate a way to automate the transformation into a big header file again. Check with some Tcl/Tk gurus online ? What about the encoding files (*.enc) ? We can bypass the tclIndex/auto_index feature that usually lazy-load the scripts when a specific feature is needed, and evaluate *all* the scripts at startup instead (not too high a cost). Also look at the Tcl Virtual File System facility and Startkits.

KWWidgets from Python

  • Add Python wrappers to the KWWidgets. The way they will be used from Python will be very similar to the way they are used from C++. [DONE]
  • Allow use of KWWidgets from Python either with Tkinter or without. Ideally the KWWidgets will be used on their own, but there are a quite a few large Tkinter applications out there that could benefit from them.
  • The C++ "Script" method will have to be wrapped in Python. For now, it is the only way to pack or grid.
  • Status Jan 30, 2006: Preliminary wrapping is CVS. Mixing with Tkinter is not yet supported.
  • Python callbacks should be supported


New Widgets

  • Quoting Steve Pieper: "Another widget type that was recently requested and sounded like a good idea was a better set of file/directory browsers. The ones in the newer versions of gimp are quite nice, I think, as a reference. They let you bookmark directories which are saved in the registry (like manually defined most recently used dirs). Right now slicer uses the tk ones, which are the windows native ones or the sucky motif style tk ones for X.". True enough, the native Windows one is nice, the Unix one definitely sucks. Such a universal file browser is actually almost there in ParaView's vtkPVServerFileDialog class, see what can be done with it. UPDATE: this item is completed, the framework is done. Check the Examples/Cxx/FileBrowserDialog example.
  • The vtkOutputWindow can be annoying at times, as it tends to pop-up at the wrong time or disappear too quickly. All error/warnings could be redirected to a dialog where they could be browsed, sorted,saved, etc. Such a concept is used in ParaView's vtkPVErrorLogDisplay class, but this implementation is seriously evil. UPDATE: this item is completed, the log dialog is done (screenshot). Check the vtkKWLogDialog and vtkKWLogWidget.
  • The tktreectrl widget looks very powerful and could probably used to implement both vtkKWTree and vtkKWMultiColumnList, and get rid of both Tk packages (BWidgets and tablelist). UPDATE: most probably not; tktreectrl is a C library, which makes it much more difficult to package than a pure Tk widget only. We would either have to build it from source, and/or package the DLL for Windows, etc. Furthermore, a significant amount of work has been done on vtkKWMultiColumnList already and a good communication channel has been established with its author. UPDATE: TkTreeCtrl is now built by KWWidgets and can be enabled. Creating a C++ API on top of it still remains a very large task.

Interface to ITK


Suggestions, discussions and specifications related to that topic are now in the internationalization page. Work on internationalization will start late November and should be completed in about 3+ weeks. UPDATE: this item is completed, the framework is done. Check the Examples/Cxx/Internationalization example, documentation to follow soon.

Better Look & Feel

  • Let's face it, plain Tk on Unix looks old. Very old. It does not integrate with GTK or Qt. In that respect, the new Tcl/Tk "Theme/Tile" framework is worth a look: the demo is pretty sharp and the "default" or "revitalized" themes are way better than the "classic" Motif-style theme used by Tk at the moment. The difference on Windows is actually not that much noticeable since Tk has been using native Windows widgets for a while. The Windows XP candy-style theme is supported by the Tile framework though. The main drawback is the different API, the removal of many Tk options, and the subset of Tk widgets actually supported by the Tile framework (but both non-themed and themed widgets can be used at the same time though). Since core Tk widgets have been clearly isolated as subclasses of vtkKWCoreWidget during the first cleanup pass, it should be easier to use themed or non-themed Tk widgets at runtime. Suggestions, discussions and specifications related to that topic are now in the Tile page. Update: this item has been completed by introducing the vtkKWTheme and vtkKWOptionDataBase classes that allow for simple branding/theming, as much as the current Tk can support without Tile. Check the Examples/Cxx/Theme example. More documentation to follow.
  • The support for transparency images has improved in Tcl/Tk. As of Tcl/Tk 8.4.5, there is still a bug that prevents the alpha layer from anything but fully opaque of fully transparent pixels, but KWWidgets works around it by pre-blending images. This was fixed in 8.4.9. As of 8.4.11 though, icons are not displayed properly in menus. A bug was submitted to the Tcl/Tk group.

KWWidgets: [Welcome | Site Map]