Skip to main content

New widget and pixbuf filters

No new posting to the Blogsite have been made over that past few days, not because of inactivity but due to quite the opposite -too much! My daily coding sessions between Thursday and Saturday this week have have resulted in the addition of one new widget type and a bagful of image processing filters. This is what has been added:

gnocl::colorWheel

Gnocl already has bindings to the GtkColorSelectionDialog which includes the familiar HSV colour selection wheel. This is what it looks like:



The colour ring itself is a widget in its own right simply called: GtkHSV. The inclusion of this binding was really straightforward as the widget itself has only minimal signals and not specific properties (but of all, the object is easily configured in Gnocl). Whilst it may be a specialist item such as the various deprecated GIMP specific widgets, the decision to include it in the forthcoming release was rather impulsive and largely as the result of the range of pixbuf processing tools coming into Gnocl. Which of course leads to the next thing to report, the inclusion of the pixBufFilters.c module.

Pixbuf filters

At the time of writing the pixbuf.c module itself had grown into some 2500 lines of code which, for me, is too much. I’m a minimalist. I prefer smaller, well-ordered discrete bites of code rather than sprawling heaps of code leviathans. The pixBufFilter.c module then is not intented to be a Imagemagick or Gimp replacement, but set of simple useful image manipulation and processing tools. At the moment the functionality is compiled into the gnocl core itself, but it would be more in keeping with the idea of the main Gnocl module to purely handler Gtk+ objects to later move the filter extensions into a separate package.
The list of filters in by no means complete. Those currently included in the code are:
brightness
color
gamma
grayscale
invert
contrast

Comments

Popular posts from this blog

gnocl::calendar

Given this module some attention today. Added some of the more package wide options to the module and created customised handler for setting the month. (For some odd reason months are are counted 0-11 whereas days are 1-31.) There's still a little more to do to this one including the addition of code to store diary details. Here's the working test script to show the range of options at work. The percentage substitution string item %e explores something that I've been toying with, the name of the signal/event that initiated the call. Ok, a script can keep its own internal trace but who knows, it might prove useful. #--------------- # calendarTest.tcl #--------------- # Author:   William J Giddings # Date:     07/05/09 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set cal [gnocl::calendar] $cal configure -day 8 -month 7 -year 1956 $cal configure -rowHeight 1 -colWidth 1 $ca

Simple Runtime Debugging Message Dialog

At times it's useful to see what values variables hold, or offer some pause point before the code goes elsewhere before causing havoc. Its possible to write output to the terminal but this can get lost in copious forms of other outputs, besides, there's no pausing the script execution either. The following proc creates a custom dialog which displays ad message along with the point in the calling script from which it was invoked. ## simple runtime debugging feedback dialog, alternative to console based gnocl::msg # @param msg message to display # @returns none # proc xxx::msg {txt} { set frame [info frame -1] append msg "Message:\n\n" append msg " $txt \n\n\n" append msg "Called from:\n\n" append msg "Proc:\t[lindex [info level -1] 0]\n" append msg "File:\t[file tail [dict get $frame file]]\n" append msg "Line:\t[dict get $frame line]\n" gnocl::dialog \ -type info \ -text $msg

Creating a button box with right aligned widgets

The dialog widget has its own internal functionaluty to create and position buttons at the bottom right corner of the window container. When creating these for ourselves it must be born in mind that default settings for fill and expand are both 0.5. Failing to set these will always place the child objects in the centre, regardless of alignment. For most cases these defaults are acceptable but, to create that dialog-button arrangement, use the following snippet as a model!   # to right align completely, set expand and fill to 0 set hbox [gnocl::hBox] set b1 [gnocl::button -text Select \                -data $lst                 -onClicked { puts DO-SOMETHING-WITH-%d} ] set b2 [gnocl::button -text Cancel -onClicked { puts DONE! } ] $vbox add $hbox -expand 0 -fill 0 -align right $hbox add $b1 $hbox add $b2