Gnocl -the Tcl/Gtk Bindings

The gnocl::application command is a really use option to create a project ready front end. It creates all the necessary basics, containers, menubars, toolbars and status zones -- it even packs the whole lot into a toplevel window and returns the widget-ids of the contents. But what, as I recently needed, must be done when the application is the centre of a plug-in to be packed into some pre-existing container held in some other toplevel window?   Remove and repack!   The whole layout is contained in a frame, a widget ordinarily accessed. This needs to be removed from the default toplevel and repacked elsewhere.  Here's how to do it. array set app [gnocl::application]    $app(topLevel) remove $app(frame)    $app(topLevel) delete unset app(topLevel)

I've just been working on the module to create the gnocl notebook widget, paying particular attention to the tab configuration options.   Earlier, and for convenience's sake, I added two commands tabConfigure and tagCget . All well and good, but the established practice of is to have the commands addressing the main container, and sub commands container objects, in the manner of the text and its tags and various other elements.   The reasoning for this is that the notebook tab contains a child widget, a label by default, which the Gtk api allows to be directly accessed or even replaced. This is how some applications are able to embed widgets into notebook tabs (take Geany for example).   Unlike text tags, which are the same class of object, the notebook tab ans a container can  become the parent of any other widget or even a boxed set of widgets. Aware of this, any specific cget or configure command needs to be customized in order to allow for this extra flexibility.   To acc

  Overlooked posting April's updates. Here goes...  2021-04:     gnocl::window         o new commands: maximize, fullscreen. Take boolean arguments.         o problems with using -setSize after window first shown fixed.     gnocl::menu         o new option -widget for popup subcommand, position popup at bottom left corner of the specified widget.         o menu tearoff item no longer added by default. This due to "window show" revealing any hidden items.           The -tearoff option was added to emulate Tk, but in practice this rarely used.     gnocl::comboEntry         o new option -editable for gnocl::comboEntry         o new command clear, a synonym for set "".           Simply a convenience to comply with other editable widget commands.     gnocl::clock         o startup diameter (width/heightRequest) set to 150px.     gnocl::unicode         o new command to manipulate and query unicode strings.           located in module src/unicode/unicode.c           su

Just a quick way of centering a substring within a space passed string.  Nothings perfect, especially when odd numbers are concerned.  proc pad { str max} {     set len [string length $str]          set tmp [string repeat " " $max]     set dif [expr $max-$len]     set fr [expr $dif/2]     set to [expr $fr+$len]      set str [string replace $tmp $fr $to $str]          return $str }

    The list widget is a great tool for displaying related information in sets. That is a sample, distributed across rows and columns. To do this the list widget creates cells for each sample and allocated memory to handle its formatting and data. In practice, this means two 'blocks' for each piece of data. The information to display, and how to display it. This arrangement works fine for large humanly workable amounts of data, perhaps up to 1,500 or more rows. But, what about more, much, much more? I have a translation data set with source and target language pairs well in excess of 57,000 pairs. The list widget will handle these, but the delay receiving and rendering is far too long. The solution then, is to tweak the text widget to handle similar rows with a row picker. Sounds complicated, but its not. Just a couple of tweaks needed. Put the text widget inside an eventBox and then trap any direct events being passed to it, whilst allowing the scrolledWindow containe

When we learn to code we work on simple problems, maybe the sort of tasks that were originally used to test and develop our favourite languages, libraries and apis. In a nutshell, simple solutions to simple problems.  But, when complexity takes over, rules often go out of the window - there may be causes, but these cannot be easily identified and defined. The may be at a 'lower level', perhaps in dependencies or even compilation errors.  I've just had to resolve one such problem arising from the failure to display of child widgets in an eventBox . After modifying the gnoclOptChild code in the parseoptions.c module to offer the ability to replace child objects in a GtkBin , the new code worked for other GtkBin objects but not for an eventBox .  The solution was to copy the contents of the gnoclOptChild function and divide the code between the configure and cget module functions. This also needed a modification to the EBoxOptions array. Happy again now! So why the Zen a

Ok, its of limited use but it is possible to embed user defined widgets in a notebook page tab. In all likelihood it will still be a label and a button embedded in hbox and not a list or tree view !  Including custom labels does have its drawbacks, its not really practicable to use accelerators in the same way and, if any commands or substitution strings are passed then these will return label widget-ids and not the label text string. # !/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set nb [gnocl::notebook] $nb addPage [gnocl::button -text HI] AAAAA $nb tabConfigure 0 -data 1 # label and box set hbox [gnocl::hBox -padding 0 -borderWidth 0] $hbox add [gnocl::label -text %_H_IHIHI] $hbox add [gnocl::image -image %#SaveAs -stockSize smallToolBar ] $nb label 0 $hbox puts [$nb getLabel 0] gnocl::window -child $nb

The format for defining a Tcl proc is simply: proc name {var 1 var 2. . var n } { } There is a special keyword when defining the variable list, args . When placed at the end of proceedures argument list, it results all other values being passed as a single list. In effect then, it allows a Tcl proc to recieve a variable number of arguments. So, the above definition could be re-written as: proc name { args } { } The implication here is that keeping to a single string as an even numbered list tags and values, it becomes possible to define variables within the calling procedure. Once passed, these can be set using the standard Tcl foreach command. proc name { args } {      foreach {*}$args {break} } Now, this process can be taken one step further. Many system commands have values, commands and switches and it can be helpful to emulate these patterns within a Tcl script as it saves the mind power of having to switch between programming styles. The next step then is: proc name { val1 val

Sometimes you want make a popup window with some editing or parameter setting functionality which is a bit like a dialog , although floating palette is what immediately comes to mind.  The problem is though, that whilst it's easy to adjust the window decorations, to remove the delete icons, the window's pull-down menu will still have a close option which will, by default, destroy the window when clicked.  To disable this, and simply hide the window so that it can be show n again, set the -hideOnDelete option to 1.  Following this callback scripts can be used to respond to the visibility state of the window, acting as some form of Ok button if necessary.   # !/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl set txt [gnocl::text] set win1 [gnocl::window -child $txt] \     -title Win1 -x 500 -y 400 -setSize 0.125 # EXTRA OPTIONS $win configure \      - hideOnDelete 1 \      -onHide { puts BYE! } \      - onShow

  I've spent the better part of half a day solving what really ought to a have been a trivial problem. Well, the solution was trivial but tracking down the cause of it all was very frustrating indeed! Consider this: set menu [gnoc::menu] Hitherto, in order to be compliant with now ancient formatting practices, a menu automatically has a tearoff item place at position 0 in the children list. So, to hide it, because we don't want one use: set menu [gnoc::menu -tearoff 0] or set menu [gnoc::menu] $menu configure -tearoff 0] So far, so good. But, if the gnocl::application command is used to produce a working UI framework, and extra widgets including addition menu bar items, and the show subcommand used for the application toplevel then BOOM!  The recently made menus without tearoffs suddenly got tearoffs again. 😠 The issue was that the existing menu.c configure function simply hid or showed the default tearoff item. This needs to be created or destroyed when needed. Well, job done