Monday, February 28, 2011

Docs

For some reason the formating of the doxygen generated pages was a little wierd. In the past it generated a nicely numbers list, but something went wrong. So, I've just reworked the pages with lists on them. Should be ok now.


gnocl::fileFilter

I noticed that the filechooser dialog still had no means of providing file filtering. Put a module together to handle that. Seems like a lot of code for a simple output! The basics are there but still a little more needs doing. For instance, its possible to assign more than one fileFilter to a widget. And, of course, there a special option just display known image formats.

 

Sunday, February 27, 2011

gnocl::tree and gnocl::windo enhancements

This weekend has been really busy. I've ben working on the gnocl::tree module which is pretty daunting but got there in the end. I wanted to implement text wrapping on text cells. Following this I wanted to implement a means of dynamically re-wrapping text as the text columns are resized -done. This needed a response to an event which emits not signals so I had then to explore the g_object_notify code. Once learned, I decided to add the functionality as a utility to the gnocl::winfo (widget-info) command. Here's the summary from the NEWS file. The updated dated code is now available from SF.

2011-02-27
    gnocl::winfo
        o new subcommand
            notify

2011-02-27
    gnocl::tree
    gnocl::list
        o new column option
            -wrapMode
            -wrapWidth
            -onWidthChange


Wednesday, February 23, 2011

gnocl::textview - full undo/redo

Just added the GtkSourceView undo/redo modules to the gnocl source core. Newly created gnocl::text objects will have unlimited undo/redo enabled by default. 

Saturday, February 19, 2011

gnocl::text contextualized popups

The GtkText and GtkEntry widgets have their own popup menus which are activated by the press of B3 (right mouse button). It is possible to create and display popup menus for other widgets but existing methods didn't allow for the direct augmentation of these widget specific menus. Today I completed the support for this functionality which I know is something that I'll use a lot. The code works but still might undergo some revision. At the moment menu items are only appended to the bottom of the list, but these could be prepended too. I'll look at this some other time. Here's the code snippets from my test application.

$trans(sl) [gnocl:text]
$trans(sl) configure -onPopulatePopup { popups %w }


#---------------
# -onPopulatePopup callback proceedure
#---------------
proc popups {w} {
   # add some items to the text widget popup menu
   # 1) create some menu items
  set m1 [gnocl::menuItem -icon "%#Open" -text "%_Use _Bird" -onClicked {puts "use bird" ; gnocl::fileChooserDialog}]
   set m2 [gnocl::menuItem -text "%_Use _Dog" -onClicked {puts "use dog"}]

   # 2) add them to the widget popup
   $w popup separator
   $w popup item $m1
   $w popup item $m2

   # 3) create a new menu
   set menu [gnocl::menu -title "Gnocl"]
   $menu add [gnocl::menuItem -text "%#Save" -onClicked {puts "save"}]
   $menu add [gnocl::menuSeparator]
   $menu add [gnocl::menuItem -text "%#Quit" -onClicked exit]

  # 4) attach this to a pre-existing menu item
  $w popup subMenu $m2 $menu
}

Wednesday, February 09, 2011

gnocl::draw composite

Added the rudiments of this subcommand that will composite a target image over the specified surface. I still have to sort out the matrix transformation ordering, but the basic bones are there.

gnocl::draw composite $pb2 \
    -image [pwd]/gnocl.png \
    -translate {100 1} \
    -scale {2 2} \
    -rotate 45

Tuesday, February 08, 2011

gnocl::draw roundedRectangle

Added another command to proiduce boxes with rounded corners. Its all working now, but I think that I might look at making this an option for the rectangle sub-command. Its not that much of a hassle, I can wrap the current gnocl::CairoDrawRoundedRectangle library functions into branch from gnocl::CairoDrawRectangle.


polyline -extra comands

After working around some compile data mangling problems I've finally got the polyline function to work with two new options -fill and -close. A bit of a fiddly process, but I got there in the end. So far, so good!

Monday, February 07, 2011

gnocl::draw polyline ...

Added a polyline function this evening.

gnocl::draw polyline $pb2 -points [list 0 0 100 50 100 100 50 150 200 100]

The syntax is simple enough.

I'll add a polygon next time.


Sunday, February 06, 2011

gnocl::draw

Resurrected the cairo module today. I almost deleted it a while ago but decided to return to it after I needed some its functionality in my ScanDocs application. Ok, some of these drawing functions can be achieved using a canvas, but I wanted optimal speed. When I returned to the code I found that I broke away after coming to a standstill on implementing the line and fill attributes. I'd got 90% of the way there.... Today got through that one in about 15mins. I've got the most of the Cairo primitives sorted now but have come to a similar 'sticky wicket' with regard to setting patterns. Its a little late now and so this is something for later on this week.

Here's the test script:

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

package require Gnocl

# how to pass these values to a cairo context?
# keep them in a global context, when drawing occurs, these are read!



#gnocl::mainLoop

set pb1 [gnocl::pixBuf load -file ./im-0007.pnm]
set pb2 [$pb1 resize -width 210 -height 297]

gnocl::draw set \
    -lineColor {1.0 0.0 0.0 0.5} \
    -fillColor {0.0 0.0 1.0 0.5} \
    -lineWidth 10 \
    -dash DUNNO

# top
gnocl::draw line $pb2 -from {0 0} -to  {0 296}
# bottom
gnocl::draw set \
    -lineColor {0.0 0.0 1.0 0.5} \
    -fillColor {1.0 0.0 0.0 0.5} \
    -lineWidth 10 \
    -dash DUNNO

gnocl::draw line $pb2 -from {200 0} -to  {200 296}

gnocl::draw circle $pb2 -center {200 200} -radius 50

set xc 100
set yc 100
set r 100
set a 90

gnocl::draw arc $pb2 \
    -center {100 100} \
    -radius 50 \
    -startAngle 0 \
    -endAngle 90 \
    -fill 1 \
    -negative 1

gnocl::draw curve $pb2 \
    -points {
        0 150
        50 50
        150 150
        200 50} \
    -fill 1

gnocl::draw pattern $pb2 \
    -type radial \
    -center1 {115.2, 102.4,} \
    -radius1 {25.6} \
    -center2 {102.4, 102.4,} \
    -radius2 {128.0} \
    -startColor {1 1 1 1} \
    -endColor {0 0 0 1}

# sides
#gnocl::draw line $pb2 -from {200 0} -to  {200 296}
#gnocl::draw line $pb2 -from {200 0} -to  {200 296}

#centre
#gnocl::draw line $pb2 -from {105 0} -to  {105 296}

set img1 [gnocl::image -image %?$pb2 ]
gnocl::window -child $img1



And a screenshot...



Saturday, February 05, 2011

gnocl::pixbuf -two new object commands

Offering new extra functionality "scale" and "resize" allow copies copies made of existing pixbufs at new sizes. Typically a pixbuf will be an image loaded from disk that would be suitable manipulated prior to display in a gnocl::image item which has its own buffer resizing functionality. However, the pixbuf code is pretty fast for scaling operations in general and so would be useful for simple image manipulation. Here's how these commands work:

# Create a pixbuf by loading and image from disk.
set pb1 [gnocl::pixBuf load -file ./georgie.png]

# Create copy by simple scale factor, conserves aspect ratio
set pb2 [$pb1 scale 0.25 ]



# Create copy by specifying width scale factors, no conservation of aspect ratio
set pb2 [$pb1 scale -width 0.25 -height 0.25 ]







# Create copy by specific size, does not conserves aspect ratio
set pb3 [$pb1 resize -width 100 -height 150 ]

# Copy with specific width, the height will be calculated based upon image aspect ratio
set pb4 [$pb1 resize -width 100  ]

# Copy with specific height, the width will be calculated based upon image aspect ratio
set pb5 [$pb1 resize -height 150  ]


These commands are pretty straight forward. There may be some function duplication between modules such as wand, but there are probably some speed differences. After all, the Gdk/Gtk libraries are designed for screen rendering and so need to be fast whilst the imageMagick equivalent supports an internal command pipeline for multiple commands and is aimed squarely as disk-based image processing.