Copyright © 2009, 2010 Arndt Roger Schneider
Figure 4, “Frontside Water Mark” features two hugelists, each with a water mark. Both hugelists are part of a rtl_mlistbox, which in turn is part of a Gistbox. A Goolbar compliant vector is used as the water mark in both hugelists.
The water mark in Figure 4, “Frontside Water Mark” is semi-transparent and placed front most. The hugelist items do not need to be transparent when the water mark is placed in front. The water mark itself has to be transparent.
The code for Figure 4, “Frontside Water Mark” is presented in Example 8, “Water Marking Code”. Inside the Tcl-Code two issues are important: The hugelist internal canvas ($cv1 and $cv2) are accessed with a leading underscore, and window position changes –column resize– won’t generate <Configure> events.
makeRectangle, this procedure creates the background of each item.
makeBox, this procedure is called whenever an activeStyle other than »none« was defined for the hugelist window.
makeNormal, this procedure is called when a not selected item is drawn.
makeSelection, this procedure is called when a selected item is drawn.
makeCoords, this procedure is called when an item gets created.
This TkPath extended hugelist brings transparency to the hugelist. Transparency is used in an uniform fashion and applied on all background items. Text and images remain opaque. Background opacity is controlled by the »opacity« Option Database entry. The opacity value follows the TkPath convention for »-strokeopacity« and »fillopacity« ; a value of »0.0« is altogether transparent and a value of 1.0 opaque.
»makeNormal« is called for normal items. »makeNormal« reads the »opacity« value from the Option Database and applies it via »-fillopactiy« on the prect elements.
Transparent items allow water marking inside of an hugelist. Water marks have to be moved whenever the hugelist size changes. Window size changes are reported through the <Configure> event.
Using TkPath elements in hugelist makes gradients possible.
Figure 5, “Etiquettes” extends Figure 4, “Frontside Water Mark” with Aqua OSX® etiquettes. These etiquettes are raised gradients.
Example 12. Etiquettes makeNormal
proc hugelist::makeNormal { w row color index mixed } { # Use gradients as etiquettes, only: if { ![isAlternate $w $color] && ![isBackground $w $color] && ![isDisabled $w $color] && } { set color \ [tkpgradient _$w.f.c create linear \ -stops [list \ [list 0.0 $color 0.2] \ [list 0.4 $color 1.0] \ [list 1.0 [rtl::mixColors $color \ 70 black] 0.85]] \ -lineartransition { 0.49 -0.01 0.5 1.01 }] } _$w.f.c itemconfigure rect$row \ -fill $color \ -fillopacity [opget $w opacity 1.0] }
»tkpgradient« in Example 12, “Etiquettes makeNormal”, from the Runtime Library 3.0 package »gtkp«, creates a new gradient every time it’s called. A real application must caché the created gradients, in order to prevent it from successive and excessive memory consumption!
Vector procedures have to follow a certain signature to be used as such from within a Hugelist.
Signature details
The first parameter »canvas« is the drawing window inside the Hugelist.
The required tags for the new–to be created– vector item.
The provided »tags« are used to manipulate and identify the item, to which the vector belongs.
When using groups under TkPath 0.3, only assign these »tags« to the main group of the created vector and not to its elements.
The coordinates where the new vector icon is to be created. The used anchor is »s« (south).
The dimensions of the new vector icon.
The size value is the linespace of the used hugelist font.
Use the following formulas to convert real canvas coordinates into vector size:
Example 14. Lisp Code to calculate Vector Icons
;; Y-Position (* (/ (- bottom y) (- bottom top)) 1.25) ;; X-Position (/ (- x (* 0.5 (+ right left))) (- right left))
Bottom, top, left and right in Example 14, “Lisp Code to calculate Vector Icons” are either the outer coordinates or the
bounding box around all elements inside this vector.
The vector formula is Lisp-Code.
Using TkPath 0.2 transformation inside a vector is a rather bad idea. Specifically avoid rotations. Best practice: first design the vector, then convert rotated items to path.
With TkPath 0.3 use a basic group without transformations, transformations are then usable for the items inside of it.