Posts

Showing posts from December, 2010

gnocl::notify -new gnome widget

I was asked today to sort out an issue with the gnome package. In the process of doing so I noticed that the implementation of a gnome notify object was restricted to use as an option of a statusicon object. In all fairness, I've never seen it used in any other way, but.... I thought that I really ought take a look at completing the binding. So, I've just hacked together the first attempt. There's still quite a bit left to do, but it will appear like a widget allowing changes to be made until is the notification object is 'closed'.

Here's my test script.

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

package require Gnocl
package require GnoclGnome

set gui [gnocl::window]

set not [gnocl::notify \
    -appName GNOCL \
    -summary SUMMARY \
    -body BODY \
    -icon ICON \
    -sound bell.wav \
    -timeout 500 \
    -urgency critical \
    -attach $gui \
    -onClosed "%w Puts CLOSED"]

puts $not

gnocl::keyFile - Documentation Uploaded

Just uploaded some user documentation to the website. As always, there are still a few things to tidy up. I resolved the problems I was encountering delete or 'freeing' key-value lists. I'm getting some GLIB-CRITICAL warnings written to the console but there seems to be no imparement to the functionality.

Read / Save and Creating config files using gnocl::keyFile

I'm pretty well satisfied that this module is in a usable form. This morning I put together some Tcl proc to manage the creation of application config files. This is what I came up with;

#---------------
# test-keyfile.tcl
#---------------
# William J Giddings
# 21/12/2010
#---------------

#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

#---------------
# read named ini file and create global config array
#---------------
# args:
#    fname    name of file to load
# notes:
#    resets any existing config array
# returns:
#    id of the created keyframe object
#---------------
proc config:read { {fname app.ini} } {
    global config
    array unset config

    set i 0
    set kf [gnocl::keyFile load $fname]

    foreach group [$kf get groups] {
        foreach key  [$kf get keys -group $group ] {
            set config($key) [$kf get value -group $group -key $key]
            incr i
        }
    }
    return $kf
}

#---------------
# Write current configuration setting to .ini file
#-------…

gnocl::keyFile module completed!

Had some more time this evening and so finished off this module. There's only one item left to resolve but this is not unique to this module -the 'clear' sub-command. The existing Gnocl support funcs are geared towards GObjects which are basically widgets. A GKeyFile or even a Pixbuf for that matter are not widget although they are commands in the same way as a text or button widget. So, a little more thought needs to go into completing this last piece of functionality. But, that doesn't stop the use of the command. Here's a test .ini file from my ScanDocs app.

[Program]
name=ScanDocs
version=0.0.1

[Files]
batchDir=/home/wjgiddings/Desktop/ScanDocs/batches
batchName=default
lastfile={}
outFileName={DUNDES (1984) Sacred Narrative - Readings in the Theory of Myth}
pageSize=125x197
path=/home/wjgiddings/Desktop/ScanDocs

[Scanner]
mode=Binary
resolution=300
format=bw
threshold=80
type=pnm

[Job]
autoscan=0
i=100
scanRate=2

[Process]
deskew=0
composite=0
split=1
clear=1
clearBottom=100
clearCentre…

gnocl::keyFile -remove functionality

Today's task is now completed. Its now possible to inquire what groups are present in the .ini file and what they keynames are. The final step is to remove entries and to close any open files. The next steps are to review the syntax and to add the documentation.

Here's the test-script:

#---------------
# test-keyfile.tcl
#---------------
# William J Giddings, 28/12/2010
#---------------

#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

set kf1 [gnocl::keyFile load sample_config.ini]

puts "1 [$kf1 get value -group Person -key name]"
puts "2 [$kf1 get value -key name -group Person ]"
puts "3 [$kf1 get value -group Person -key name]"
puts "4 [$kf1 get value -key name -group Person ]"
puts "5 [$kf1 get integer -key age -group Person ]"
puts "6 [$kf1 get value -key sex -group Person ]"
puts "6 [$kf1 get value -key sex -group Person -locale UK ]"
puts "7 [$kf1 get comment -group Person -key name ]&quo…

gnocl::keyFile -getting lists of groups and keys

Today's task is now completed. Its now possible to inquire what groups are present in the .ini file and what they keynames are. The final step is to remove entries and to close any open files. Here's the test-script:

#---------------
# test-keyfile.tcl
#---------------
# William J Giddings, 28/12/2010
#---------------

#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

set kf1 [gnocl::keyFile load sample_config.ini]

puts "1 [$kf1 get value -group Person -key name]"
puts "2 [$kf1 get value -key name -group Person ]"
puts "3 [$kf1 get value -group Person -key name]"
puts "4 [$kf1 get value -key name -group Person ]"
puts "5 [$kf1 get integer -key age -group Person ]"
puts "6 [$kf1 get value -key sex -group Person ]"
puts "6 [$kf1 get value -key sex -group Person -locale UK ]"
puts "7 [$kf1 get comment -group Person -key name ]"

$kf1 set comment -group Person -key name -value "HIDI HI, HO DI…

gnocl::keyFile almost done

After this morning's coding session the package now has functionality to change values and write these changes to disk.  The next step is implementing some of the introspection functionality and its pretty-well complete.

Here's the test script updated to reflect changes:

#---------------
# test-keyfile.tcl
#---------------
# William J Giddings, 28/12/2010
#---------------

#!/bin/sh
#\
exec tclsh "$0" "$@"

package require Gnocl

# 18/12/10 Additions
set kf1 [gnocl::keyFile load sample_config.ini]

puts "1 [$kf1 get value -group Person -key name]"
puts "2 [$kf1 get value -key name -group Person ]"
puts "3 [$kf1 get value -group Person -key name]"
puts "4 [$kf1 get value -key name -group Person ]"
puts "5 [$kf1 get integer -key age -group Person ]"
puts "6 [$kf1 get value -key sex -group Person ]"
puts "6 [$kf1 get value -key sex -group Person -locale UK ]"
puts "7 [$kf1 get comment -group Person -key name…

gnocl::keyFile -progress

Got the basics running now. Seeing as in TCL 'everything is a string' the process of retrieving and setting values in the Tcl side is simple. I've got the information retrieval side working well and some skeletal bits for adding values which I'll bash into shape tomorrow. Here's my sample_config.ini file:

# this is just an example # there can be comments before the first group
[First Group] Name=Key File Example\tthis value shows\nescaping # localized strings are stored in multiple key-value pairs Welcome=Hello
[Another Group] Numbers=2;20;-200;0 Booleans=true;false;true;true
[Person] #This is me! name=William sex=male age=54
And the test script to access it.

#--------------- # test-keyfile.tcl #--------------- # William J Giddings, 28/12/2010 #---------------
#!/bin/sh #\ exec tclsh "$0" "$@"
package require Gnocl
set kf1 [gnocl::keyFile load sample_config.ini]
puts "1 [$kf1 get string -group Person -key name]" puts "2 [$kf1 get string -key name -group P…

new command gnocl::keyFile

The GLIBs provides functionality for the creation and manipulation of application configuration files. This task is already pretty easy to implement using Tcl list and dictionary functionality and hitherto I've used it all the time. But, having seen how useful this functionality is, I thought that it was time to implement the bindings. The way in which this is achieved is to treat such lists as objects so that multiple files can be opened for an application. This will allow the use of such lists to be more than simply an application config file. One of my pet apps is the scanning and creation of djvu ebooks. Sometimes the settings for a particular page need to be modified in order to get a good scan. Creating a config page for to control the page creation operation would be the better than an a 'one setting fits all' approach.