Skip to main content

Posts

Showing posts from July, 2011

New Sourcecode Module textTag.c

Added a new module to the core source, textTag.c. The creation of this module is simply to separate out tag related functions from the the text.c module. It looks like this will be a hefty file. The tag object has a great number of properties that need to be wrapped. The timing of this corresponds to expanding the gnocl::text widget functionality to enable the 'dump' of buffer contents in a manner similar to Tk. Got most of it working now.

Loading a simple tag table

 Here's a quick way of creating multiple tags in one go. set tagTable {     {{Header 1} -font {Sans 12 Bold} }     {{Header 2} -font {Sans 10 Bold} }     {{Body} -font {Serif 10} -wrapMode word } } foreach {a} $tagTable {     eval "$txt tag create $a" } $txt insert end \n $txt insert end MANTRA\n -tags { {Header 1} } $txt insert end "Om Ah Hum\n" -tags Body

gnocl::text tags

Still working on extending the text tag functionality. Its quite interesting really as it requires more understanding of the really powerful Tcl command libraries to build lists etc. Today I've added some extra functionality which pretty well follows the same guidelines of the Tk text widget, i.e.  tag names, raise and lower. I'm still working on the robust parsing of tag options. One little tip for those out there, who like me, want spaces in names. Use the following to create tags: $txt tag create [list {Heading 1}] or, $txt tag create {{Heading 1}} If tags need to created proceedurally, then try: $txt tag create [list [list $tagName]]

gnocl::text -markupTags

Extending pango markup string support is something of a challenge. One option that I've just added to the gnocl::text widget is -markupTags. This will specify whether to implement a set of tags corresponding to the 'Convenience Tags' listed in the Gnocl docs. Apart from saving time when scripting, this will allow the parsing of the text buffer for names tags for output of text blocks in pango markup. For example: $txt insert end "APPLE" -tags {b} can be parsed and output as: <b>APPLE<\b> The same should be possible for span attributes too: $txt insert end "APPLE" -tags {b fg=r bg=y} could be parsed and output as: <span fgcolor="red" bgcolor="yellow"<b>APPLE<\b><\span>

gnocl::text - tag dumping

Now that its possible create tags by either direct specification or through the use of Pango markup strings, its feasible to require the conversion of text buffer contents back into some form of markup format. Saving off large amounts of text as markup is ill-advised, use serialization to save/reload large buffers. What is in mind here is the ability to edit some rich text in a text buffer and then submit it for display in a list cell or label. Might sound an odd thing to do, but my translation editor does just this. A large body of writing is converted from a text file to a list, one entry per paragraph. These paragraphs are displayed in a gnocl::list in one column and their English translations in a second column alongside. Pango markup would allow those areas in the translation to be highlighted for future review. Previously I had the bare bones of a widget 'dump' command in place and am now making further headway. Last night I added a 'ranges' sub-command to return

gnocl::text now supports pango markup

Spent some time today looking at how to implement the rendering Pango markup strings in the gnocl::text widget. Found a module in the StarDict app that was exactly what was needed! It took a couple of minutes to added it to the gnocl sources, modify the makefile text.c module. Screenshot: Test script. # test-text-pango.tcl #!/bin/sh #\ exec tclsh "$0" "$@" package require Gnocl set pango_string(0)  {%<<span foreground="blue">Hello</span> <span foreground="red">World</span>} set pango_string(1)  {<span foreground="blue">Hello</span> <span foreground="red">World</span>} set pango_string(2)  {%<<span foreground="blue">Hello</span> <span foreground="red">World</span>} set txt [gnocl::text] gnocl::window -child $txt -width 600 -height 150 # the string is parse, and the leading %< stripped $tx

gnocl::listPicker -done

Completed this megawidget. Here's the script: # test-listPicker.tcl #!/ bin/sh #\ exec tclsh "%0" "$@" package require Gnocl #--------------- # megawidget to contain Ok/Cancel buttons #--------------- proc gnocl::listPicker { args } {     set titles {"Item" data}     set types {string string}     set ls(from) [gnocl::list \         -titles $titles \         -types $types ]     set ls(to) [gnocl::list \         -titles $titles \         -types $types ]        # are any names data?     set i [lsearch $titles data ]     $ls(from) columnConfigure $i -visible 0     $ls(to) columnConfigure $i -visible 0         #~~~~~~~~~~~~~~~     # move items between two lists     #~~~~~~~~~~~~~~~            proc ::moveItem { from to i} {         set active [$from getSelection]         if {$active == ""} {return}         set rows [$from getNumChildren]         set a [$from get $active 0]         se

gnocl::listPicker

Things on the Gnocl front have been quiet these past few days. My work load has been heavy and my second hard-drive on my workstations (ie HOME) started giving me sector errors which, is always bad news. Coupled with this, my workstation has parts in it dating back to the mid-1990s and so spares are scarce! Well, as luck would have it I still have spare drives floating around from a pile of old Acer laptops one of which will soon me in my OpenSUSE workstation. At the moment, running on a totally reliable (yet very noisy) 8.5GB IBM PATA hard drive circa 1998 so space is tight. However, spent a couple of hours this evening putting the basics together for a scripted listchooser widget. Here's a screenshot: My prototype in running ok at the moment and, once finished, I'll post the code to the Gnocl website.

cget -data

One of the great features of Tk/Gnocl widgets is data association. For some time now its been possible to set the -data options but not to extract it. The reason for this is that such associations are not gtk widget properties although support for the feature is via the Gdk libraries. I'm currently working on a Gnocl scripted megawidget which needs extra items of data passes to its events handlers, the -data option is ideal for this. Implementing the feature is a simple process, as the following code extract from the entry.c module cget function shows. static const int variableIdx = 0; static const int onChangedIdx = 1; static const int valueIdx = 2; static const int cursorIdx = 3; static const int primaryIconIdx = 4; static const int secondaryIconIdx = 5; static const int dataIdx = 6; static GnoclOption entryOptions[] = {     /* gnocl unique and complex options handled through configure */     { "-variable", GNOCL_STRING, NULL },        /* 0 *

gnocl::text - obtaining names of tags applied to specific locations

The following script shows how to obtain details of which tag applies to a particular position in a block of text. #--------------- # test-tag-get.tcl #--------------- #!/bin/sh #\ exec tclsh "$0" "$@" package require Gnocl set txt [gnocl::text -baseFont {Serif 14}] $txt tag create red -foreground red $txt tag create black -foreground black $txt tag create bold -fontWeight bold gnocl::window -child $txt -setSize 0.25 $txt insert end "the quick brown fox " -tags red $txt insert end "jumps " -tags {red bold black} $txt insert end "over the lazy dog" -tags red $txt configure -onKeyRelease {     puts [%w tag get [%w getCursor]]     } $txt configure -onButtonRelease {     puts [%w tag get [%w getCursor]]     }