Skip to main content

Posts

Showing posts from April, 2021

Why didn't I do this before?

Sometimes its so much more convenient (and efficient) to implement something in C rather than Tcl: positioning a popup menu on screen is one of those situations. To this end a new option, -widget, has been added to the menu popup subcommand.  This causes the callback handler to determine screen coordinates from the on-screen location and height of the widget specified by the -widget option. Compare: $abut configure -onClicked "$menu popup -widget %w" With: $abut configure -data $menu -onClicked {         lassign [gnocl::winfo geometry %w] x y w h           %d popup [expr $x-4] [expr $y+$h] } This latter approach not only requires memory allocation using -data but 'pollutes' the global namespace with the extra variables 'x y w h' which might result in some form of conflict.  For those who notice, there is '+4' which is an attempt to handle the buttons style border-width setting. This isn't handled in the callback script, but accommodated in the m

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

gnocl::unicode -a new command

Determining the language of the user's system and script of a text string     puts $env(LANG) puts $env(LANGUAGE) puts [gnocl::unicode script "我是英国人。"] puts [gnocl::unicode script "ཀརྨ"] puts [gnocl::unicode script "aṣṭa"] puts [gnocl::unicode script "ꛅꛇꛈ"]   puts [gnocl::unicode options] puts [gnocl::unicode commands]

March 2021 Updates and News

    Fashionably late? Maybe not. Here's a listing of the recent enhancements to the gnocl core modules. 2021-03:     gnocl::fileChooserButton         o -fileFilters option now works correctly     gnoclKeyboardCmd, retrieve keyboard state.         o Returns list of boolean for: NumLock CapsLock ScrollLock           For Overwrite Mode of text and entry widgets, obtain setting from wiget directly           using %w cget -overwrite.     gnocl::window, gnocl::frame, gnocl::expander, gnocl::handleBox, gnocl::scrolledWindow         o -onDelete %c string option added to handle GTK_BIN objects, return sole child widget.     gnocl::dialog         o new option -noButtons, creates a buttonless dialog, with           response handled through dialog closure   Most of March saw me working on the complete rewrite of my translator's workbench, code named 'JMLS'. I've worked on various 'manifestations' of this platform since 1998 but, such a complete and thorough rewrite, I&#