Recent Modifications

Over the past few weeks a number of enhancements have be made to the gnocl package. Here's a brief overview of the changes:

2015-05:
    gnocl::menu, gnocl::menuRecentChooser, gnocl::statusBar
        o added -name, -data; implemented cget
        o added -name, -data; implemented cget
    gnocl::window
        o added -name
    added gnocl::application, a convience application megawidget
2015-04:
    added parent command to gnocl::volumeButton, gnocl::scale and gnocl::spinner
    gnocl::spinner
        o resolved problems with start and stop commands (same as using the -active options).
    gnocl::text
        o using the get widget command alone will return all text contents, i.e. same as "$wid get start end"
    gnocl::entry
        o wordList sub-commands "add", "clear", "delete" and "get" are now implemented.
        o enhanced the wordList subcommand with new option -split
            specifying this option will result in a string being treated as a space separated list
            of single words: e.g. "a red dog" becomes {{a} {red} {dog}}
        o enhanced the progress functionality, new options -range and -progressStep
            the command progress will increment the display by the fractions given by progressStep.
            Changing either -range or -progressStep will reset the progress display to 0.
            The use of the -progressFraction remains unaltered and is useful for resetting the progress to 0.
    gnocl::text
        o insert markup now works acceptably well, at present '            markup can only accept single, predefined options. Future
            versions may offer more, but this is probably adequate for
            most purposes requiring text pango markup.
        o renamed -markupTags to -useMarkup
    gnocl::toolBar
        checkItem/toggleButton
        o configure -data option and others now works
        o cget -iconSize now works properly
    gnocl::label
        bugfix:
            -textVariable setting now responds to the widget -useMarkup option

For me, the most exciting prospect is the ability to use pango-like markup strings in conjunction with the the text widget. Additionally, the gnocl::application convenience function offers an extremely quick way of initializing a working application complete with menus, toolbars, main container and status bar. The following tests script shows how this new script can be used:

#---------------
# test-gnocl-appl.tcl
#---------------
#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

#~~~~~~~~~~~~~~~~~~~~~~~~~
# create the basic application
#~~~~~~~~~~~~~~~~~~~~~~~~~
array set app [gnocl::application -application "MyAPP" -version 1.0 -date 07/05/15 -filetypes *.tcb]

#~~~~~~~~~~~~~~~~~~~~~~~~~
# Configure the main toplevel settings
#~~~~~~~~~~~~~~~~~~~~~~~~~
$app(topLevel) configure -title "APPLICATION" -setSize 0.5 

#~~~~~~~~~~~~~~~~~~~~~~~~~
# Configure toolbars
#~~~~~~~~~~~~~~~~~~~~~~~~~
$app(toolBar,1) add item -icon "%#New" -text New -name AAAA
$app(toolBar,2) add item -icon "%#Open" -text Open -name BBB
$app(toolBar,2) configure -visible 0

#~~~~~~~~~~~~~~~~~~~~~~~~~
# Create and pack application specific resources
#~~~~~~~~~~~~~~~~~~~~~~~~~
set app(txt) [gnocl::text -wrapMode word -name "textEdit" -useMarkup 1]
$app(container) add $app(txt) -fill {1 1} -expand 1
$app(txt) lorem ;# a bit of dummy data

#~~~~~~~~~~~~~~~~~~~~~~~~~
# Show and go!
#~~~~~~~~~~~~~~~~~~~~~~~~~
$app(statusBar) push "Ready..."
$app(topLevel) show

#~~~~~~~~~~~~~~~~~~~~~~~~~
# GUI elements can now be modified
#~~~~~~~~~~~~~~~~~~~~~~~~~
$app(toolBar,2) add item -icon "%#Yes" -name CCC
$app(help,about) configure -onClicked {puts HIDIHI}
$app(file,quit) configure -onClicked {exit}
$app(file,recent_menu) configure -onClicked {puts "HODIHO %f"}

#~~~~~~~~~~~~~~~~~~~~~~~~~
# alternatively, use aliases based upon Gtk+ builder names
#~~~~~~~~~~~~~~~~~~~~~~~~~
if 1 {
    namespace eval myApp {}
    foreach item [gnocl::inventory widget $app(topLevel)] {
        set n [$item cget -name]
        if { $n != "" } { interp alias {} ::myApp::$n {} $item }
    }
    ::myApp::textEdit insert end "\nOm Mani Padme Hum Hrih"
}

Recent Enhacements

Here's a brief overiew of enhancements to the development distribution over the past month or so.The mix is consists of the inclusion of a number of convenience options and enhanced feedback.

    gnocl::notebook
        o added command nthPage, retrieve name of child widget on specified page. 
    gnocl::stringUtil
        o new command, provides additional convenience string functionality; particularly useful for
           string comparisons.
    gnocl::text
        o added -lineSpace convenience option. Valid options are "single", "1.5", double" or exact
           spacing in pixels.
    gnocl::label
        o added command getSelection (text only, markup not included)
    gnocl::window
        reduced -typeHint options to normal, popup and splashscreen.
    gnocl::toolbar menu button
        o added new option -data:
    gnocl::notebook
        o added command pageNum, retrive page number for specified child widget
            added extra percentage substitution strings to -onSwitchPage
                %c child
                %t label text
                %d data
    gnocl::eventBox
        o added specifc %c to -onButtonPress/Release list of substitution strings
        o add %d subsitution to -onButtonPress/Release list of substitution strings
    gnocl::fileName
        o new command, offers partial binding to the glib filename functions.

Cancellation of a 'Recent Items' Pull-Down Menu

Its been some time since support for 'recent file' operations was first added to the Gnocl sources. At the time I was quite pleased with its inclusion but there was always a annoying snag to it, something which is an inhereted feature from the API: if no selection if made, then the last file URI added to the list is always returned. This is not really a sign of anything lacking in the GTK sources, but the documentation does not suggest how to handle any need to CANCEL the menu by pressing the 'ESC' key.
 A quick gloss over the docs shows that there is a 'cancel' signal for the MENU-SHELL containing the recent items, but this automatically generates a 'selection-done' signal, the very signal that we want to avoid. The obvious solution for this is to set a boolean cancel flag and test for its TRUE or FALSE state during the execution of any 'selection-done' event handler.

For a TCL side solution it was first was necessary to implement a gnocl -onCancel option. So, this could added to any test script:

set cancel 0
set rc_menu [gnocl::menuRecentChooser \
...
-onCancel {  set cancel 1 } \
-onClicked {
     if { !$cancel } {
        set fname [string range %f 5 end]
        openFile $fname
        }
    set cancel 0
}

Works nicely, but it's better if this becomes invisible to the scripter.This of course, is not a problem to implement in C and so the relevant handlers have been modified to offer the benefit of this functionality.

Broken gnocl::splashScreen now fixed

Whilst a splash screen widget has been in the core for some time now, the code has became unreliable and so some fixing was in order. The revised module, rather than using cairo to draw screen elements, uses items placed directly in GtkFixed container to create a gnocl megawidget. This has not only proved more easy to code, but also operates more smoothly. Updates available in the nightly build.

Paned motion events now handled

I'm not quite certain why, but the GtkPaned API has no direct support for tracking the events associated with the mouse pointer. Signals are implemented, but only for keyboard operations. The docs give useful function to isolate the handle gdkwindow but why didn't they go the whole hog and implement a proper binding? Well we have it now in Gnocl!  

To test this feature get the latest nighly build.

set p [gnocl::paned \

-children [list $b1 $ebox] \

-resize 1 -shrink 1 \

-onHandleMotion {

## puts "MOVING w= %w x= %x X= %X p= %p s=%s"

if {"%s"== "256" } {

foreach {x y w h} [gnocl::winfo geometry %w] {}

_set_width $paned [expr $w - "%p"]

gnocl::update

}

}]

Multipaned container implemented in Tcl/Gnocl

The Gtk+ widget set contains two widgets, GtkHPaned and GtkVPaned which only allow the insertion of two child widgets. One might suppose that if more items are needed then folding boxed in a scrolling window would be adequate. One alternative, as I have used up to date, is the use of nested double panes.

Implementing a new container widget in C using the Gtk+ libraries is possible, but implementing such an beast in Tcl/Gnocl is somewhat less complex.

Over the past couple of evenings I've put together a proof of concept script to get the bare bones of this this megawidget in place. All seems well, although a little bit of easing on the gnocl source code side of things has helped. To this end I've added the geometry subcommand to the gnocl::fixed widget. The effect of this to allowing a single command to return the position and size of child objects placed in a gnocl:fixed container rather than making two separate calls in the script, one for the (x y) position and the other for (width height) size of the child.

As can be seen from this screenshot my test script my paned is somewhat overpopulated.

To test this out locally, download and install the lastet nightly build from SourceForge.

A click and drag of the mouse pointer on the separator bars sees the height of all of the panes resize correctly in real-time.

The next step is to introduce some minium settings, overlap prevention and collapse-expand double click behavious on the separator.

# mypaned-2.tcl
#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

set bar 15
set height 50
set width 200
set i 1
set handle_height 5


#---------------
#
#---------------
#
proc my_paned {} {

    set ::container [gnocl::fixed -onAdd {puts HI}]

    set wid [gnocl::eventBox]  ;#-background red]

    # add the first container
    $::container add $wid -x 0 -y 0 -width $::width -height $::height

    lappend ::panes $wid

    return $::container

}

#---------------
#
#---------------
#
proc _resize_above { handle } {

    set box [gnocl::winfo parent $handle]
    set i [lsearch $::handles $handle]
    set above [lindex $::panes $i]
   
    set w [lindex [gnocl::winfo geometry $box] 2]

    # get and process geometry
    foreach {ax ay aw ah} [$box geometry $above] {}
    foreach {hx hy} [$box position $handle] {}

if 0 {
        +---------------+ ay
        |               |
        |     ABOVE     | new height = hy - ay
        |               |
        +---------------+ hy
        |     HANDLE    |
        +---------------+  
}

    $box move $above -x $ax -y $ay -width $aw -height [expr $hy -$ay]
       
}

#---------------
#
#---------------
#
proc _resize_below { handle } {

    set box [gnocl::winfo parent $handle]
    set i [lsearch $::handles $handle]
    set below [lindex $::panes [incr i] ]

    # get and process geometry
    foreach {bx by bw bh} [$box geometry $below] {}
    foreach {hx hy hw hh} [$box geometry $handle] {}

if 0 {
        +---------------+ hy
        |     HANDLE    |
        +---------------+ hy+hh = by
        |               |
        |     BELOW     | new height = (by+bh) - (hy+hh)
        |               |
        +---------------+ by+bh 

}
    $box move $below -x $bx -y [expr $hy + $hh] -width $hw -height [expr ($by+$bh) - ($hy+$hh)]
       
}

#---------------
#
#---------------
#
proc move_handle { handle } {

    # get container
    set box [gnocl::winfo parent $handle]

    # move handle
    set hy1 [_pointer_ypos $handle]
    foreach {hw hh} [$box size $handle] {}
    $box move $handle -x 0 -y [_pointer_ypos $handle] -width $hw -height $hh

    _resize_above $handle
    _resize_below $handle   
       
}

#---------------
#
#---------------
#
proc _pointer_ypos { w } {
    return [expr [lindex [gnocl::winfo pointer [gnocl::winfo toplevel "$w"]] 1] -5]
}


#---------------
#
#---------------
#
proc adjust {w} {
    set i [lsearch $::handles $w]
    set l [expr [llength $::handles] -1]


    set ret "[expr $i] [expr $i+1]" 
       
    return $ret
}

#---------------
#
#---------------
#
proc add_handle { y } {
   
    set wid [ gnocl::eventBox ]
    $wid configure -child [ gnocl::separator ]
   
    set parent [gnocl::winfo parent $::container]
    foreach {a b width c} [gnocl::winfo geometry $parent] {}
   
    set y [expr $y -$::handle_height]
   
    $::container add $wid -x 0 -y $y -width $width -height $::handle_height   

    lappend ::handles $wid
   
    $wid configure -onMotion { move_handle %w }
       
}

#---------------
#
#---------------
#
proc add_pane { } {
   
    set lpane [lindex $::panes end]
   
    foreach {a y w h} [$::container geometry $lpane] {}
   
    set y [expr $y + $h +$::handle_height]
    set wid [gnocl::eventBox ]
   
    $::container add $wid -x 0 -y $y -width $w -height $h

    add_handle $y
   
    incr ::i
   
    lappend ::panes $wid
   
}

#---------------
# test-block
#---------------
#

set paned [my_paned]

gnocl::window -child $paned -height 600 -width 300

add_pane
add_pane
add_pane
add_pane
add_pane
add_pane
add_pane
add_pane

set txt(1) [gnocl::text -wrapMode word] ; $txt(1) lorem
set txt(2) [gnocl::text -wrapMode word] ; $txt(2) lorem
set txt(3) [gnocl::text -wrapMode word] ; $txt(3) lorem
set txt(4) [gnocl::text -wrapMode word] ; $txt(4) lorem

[lindex $panes 0] configure -child $txt(1)
[lindex $panes 1] configure -child [gnocl::label -text ONE]
[lindex $panes 2] configure -child [gnocl::label -text TWO]
[lindex $panes 3] configure -child $txt(2)
[lindex $panes 4] configure -child [gnocl::label -text FOUR]
[lindex $panes 5] configure -child [gnocl::label -text FIVE]
[lindex $panes 6] configure -child $txt(3)
[lindex $panes 7] configure -child [gnocl::label -text SIX]
[lindex $panes 8] configure -child $txt(4)

gnocl::entry validation

Making headway now in implementing entry validation. As is always the case, the challenges don't arise from getting the code to work, but overcoming those instances when, theoretically, a block of code should work but doesn't. The most annoying aspect of all this is that such hindrances tyically occur in the simplest, most straight forward of tasks and those features which at first glance look daunting are implemented in a blink! Think I'm having a deja vu moment here.

Ah, such is life. Zen and the the art of C programming -- frustration arises when one's vision of an ideal and perfect world are shot to pieces by an abrupt clash with the imperfect reality of things.

The entry and parseoptions C modules now have all the necessary functionality coded into it, what now remains is to tidy it up, test and document it.