Other, non-standard geometry managers cannot be supported this way. The code generation must be extended to include unconventional geometry managers.
Example 11.5. Code generation for Pack
Inside vg26/library/vgcode.tcl
:
proc vgcode::dump-geometry-pack { target ta_name basename id_base ch_class {class ""} } { # calls the meta-code generation: set out [vgcode::dump-geometry-meta \ $target $ta_name $basename \ $id_base $ch_class pack]; # Deals with propagation: if ![pack propagate $target] { append out [dumper::propagate \ pack $ta_name 0] } return $out; }
Example 11.6. ...Code generation for Pack
... and inside vg26/library/tcldumper.tcl
:
proc dumper::metamanager {
manager window container properties
} {
return [subst \
{
# Geometry for '$container' child window.
[format {%20s %s} $manager $window ] $properties
}]
}
Example 11.5, “Code generation for Pack” shows the
procedures, most important for the »pack« geometry
manager. Code generation can be ensured, for an
unknown manager, by implementing a similar procedure
pair for it. The procedure must follow the given
naming convention.
vgcode::dump-geometry-zincwindow
for
example, generates code for windows embedded in a
TkZinc 3.3.4 window.
Built-in geometry managers are always unconventional. The default for built-in managers is the Tk canvas window. The built-in code from the palette entry is being used, as a last resort for code generation.
In both cases, the possible interactions with unknown managers is extremely limited.