Skip to main content

Namespace export-import, aliases and rename

 
    Namespaces are really useful in Tcl as they permit commands and variables to be conveniently grouped together. This means that common command names can be reused within specific contexts, and that variables can be 'hidden' away from errant command calls. All this extra security does come at a cost, a lost of unecessary and respetative typing. Using the gnocl:: namespace prefix is useful if, lets say, there is a need for mixed Tcl and Gnocl programming. But, if there isn't this need what can be done to alleviate the typing burden, albeit with some risks when coming to readability and portability between applications? Variables and commands embedded within a namespace can undergo export-import process or they can be renamed.

The following code example shows how this can be done. When exporting and importing between namespaces its possible to have a naming conflict in the importing namespace. Tcl will pick this up and result in an error. Fortunately this only applies to a handful of instances and in most cases (e.g. list and listStore) command synonyms are built into the gnocl core.

 
# !/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

# what namespaces are present?
puts [namespace children ]

# export all gnocl command and widge names
namespace eval ::gnocl {
    namespace export application listStore button menu window
    foreach class [widgets] { namespace export $class }
    foreach class [commands] { namespace export $class}
}

foreach class [gnocl::widgets] {
    if { [catch { namespace import gnocl::$class } err] }  { puts WIDET-$err }
}

foreach class [gnocl::commands] {
    if { [catch { namespace import gnocl::$class } err] }  { puts COMMAND-$err}   
}

set x 200 ; set dx 400
set opts "-y 400 -width 300 -height 200"

# EXAMPLE 1) create app from and array
array set app [application]

$app(topLevel) show


set lst [listStore -columns 2 -types {string string}]
$lst add [list [list a b] [list b c] ]
$app(container) add $lst -fill 1 -expand 1
$app(topLevel) configure -x [incr x $dx] {*}$opts

# EXAMPLE 2) using aliass
interp alias {} g_window {} gnocl::window
g_window -child [gnocl::text] -x [incr x $dx] {*}$opts

# EXAMPLE 3) renaming commands
foreach class [gnocl::widgets] {
    rename gnocl::$class gcl::$class
}

gcl::window -child [gcl::button -text hello]  -x [incr x $dx] {*}$opts




Comments

Popular posts from this blog

gnocl::calendar

Given this module some attention today. Added some of the more package wide options to the module and created customised handler for setting the month. (For some odd reason months are are counted 0-11 whereas days are 1-31.) There's still a little more to do to this one including the addition of code to store diary details. Here's the working test script to show the range of options at work. The percentage substitution string item %e explores something that I've been toying with, the name of the signal/event that initiated the call. Ok, a script can keep its own internal trace but who knows, it might prove useful. #--------------- # calendarTest.tcl #--------------- # Author:   William J Giddings # Date:     07/05/09 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set cal [gnocl::calendar] $cal configure -day 8 -month 7 -year 1956 $cal configure -rowHeight 1 -colWidth 1 $ca...

Gnocl Dashboard

Over the past few programming sessions I've been working on producing a central point, a dashboard, around which it's possible to see the various Gnocl widgets and commands in operation. In many ways like the demo script which shipped with the earlier releases of Gnocl but offers much more. The introspection functionality provides details of the various options and sub-commands of each Gnocl procedure which are displayed under the associated tab. Sample scripts are included for each item which offers newcomers a clearer insight into how make the most of what's on offer.

Getting Widget Style Properties

Until the move over to Gtk4, Gnocl is still built against the Gtk 2.21 libraries. One of the inconveniences of Gtk is getting and setting widget style settings which are considered to be set globally by the desktop style settings and not for the programmer to tinker around with. Needless to say, there are times when different defaults are preferred, largely to draw the users attention to 'something a bit different'. The function gtk_widget_modify_font  is a convenience function to set the widget basefont as shown in this snippet from the button.c module,  if ( options[baseFontIdx].status == GNOCL_STATUS_CHANGED ) { GtkWidget *label; label = gnoclFindChild ( GTK_WIDGET ( para->button ), GTK_TYPE_LABEL ); PangoFontDescription *font_desc = pango_font_description_from_string ( Tcl_GetString ( options[baseFontIdx].val.obj ) ); gtk_widget_modify_font ( GTK_WIDGET ( label ), font_desc ); pango_font_description_free ( font_desc ); } Unfortunately, there's no d...