Gnocl -the Tcl/Gtk Bindings

I've now created the structure to add options to the iconview add command. This will be useful if some other info apart from a filepath is needed. Also, in progress is the use of percentage markup strings. This will enable the choice between file, stockitem and pixbuf sources. If the specified icon is unavailable then a default item will be displayed. Here's a sample of the test code... set iv [gnocl::iconView \     -columns 1 \     -orientation vertical \     -itemWidth 100 ] gnocl::window \     -title VERTICAL \     -child $iv \     -width 150 \     -height 300 \     -onDestroy {exit} for {set i 1}  { $i <= 3} { incr i } {    $iv add "%?im-0001.pnm" -label "item $i" } $iv add pointer.png -label pointer $iv add upArrow.png -label up $iv add downArrow.png -label down And the result...

Done more work on adding items to the display. The code originally had a stub which  populated the widget, but now items can be added directly, set iv [gnocl::iconView \     -columns 2 \     -orientation vertical ] gnocl::window \     -title VERTICAL \     -child $iv \ $iv add pointer.png $iv add upArrow.png $iv add downArrow.png $iv add logo.png At the moment any graphic will be displayed at its original size and not resized to fit. Reflecting upon this and the fact that the GtkIconView widget can display any prededefined GtkTreeList, I think that I will after all, need to implement a parameter struct for this module. This is no hassle. Something for tomorrow....

Didn't need to create a param struct for the widget after all. I'd forgotten that for convenience the GtkIconView was already packed into a GtkScrolledWindow and all that I needed to do was to get the child for this item.

Overlooked this one in my 'audit' earlier this month. Spent a couple of hours working on this module this evening. Why do that? Again, 'cause I want to use the widget in an app. I got the bare bones together and hacked together a stub that launched a demo widget. But, now it need polishing off. I've got all the propterty and signal options sorted out but now I need to revisit how the widget is registered. In fact I need to create a iconview struct to contrain pointers not just to the widget but to the scrollable window that its packed into. So, options will be set a creation but cannot yet be 'configured' to other settings or values. I'll handle this tomorrow night. The code 'as-is' has been uploaded to sourceforge. Here's the test-script that I'm working with: #--------------- # test_iconview.tcl #--------------- # William J Giddings # 27-Oct-2010 #--------------- # Notes: # #--------------- #!/bin/sh # the next line restarts using tcl...

A while ago, after upgrading my distro from OpenSuse 11.2 to 11.3 I noticed that the Gnocl icon on my apps had vanished. Of course it had been installed as a shareable graphic. Its about time to add it to gnocl core so that it will always appear by default in the top left corner of all newly opened Gnocl windows.

Just implemented -unit option functionality, this will allow long and short keywords, millimeter/mm, inch/ins. pixel/px and point/pnt. Just looking at obtaining and manipulating the print status options. This module is certainly going to be a big one!

Added the core structures to hand the configure and cget commands. And its running fine. Took a look at the online docs and urgh! The gnocl::assistant page is in urgent need of completion.

Did some more work on the print module today. First of all I reworked the registration of the print op. Originally it was registered along with the other widgets, but on reflection I felt that it should be named differently in the same way as pixBufs are. So, I had to add a pile of funcs to add a hashtable to handle print jobs. Another change that I made to the code was to use a pointer to a parameters structure rather than to the op itself. Ok, all of the relevant info regarding the print job will be held in a printersettings structure, but the use of the parameters structure means that all the relevant pointers and non-gtk option settings can be accessed through a single call rather than having too many messy globals floating about. Finally, added the basics for the developer docs. The module doesn't print anything yet even though there's well over 500 lines of code!

Returned to the print binding today and put the code in place to handle the Gtk properties and signals for the GtkPrintOperation widget. I'm pretty well playing this one as I go along as I have to admit that I don't fully understand the whole process. In terms of requiring print functionality all that is ever needed for document processing is now probably catered for using the gnocl::abiword widget. The gnocl::text object could have a simple print command added to it for the purpose of simple listings. Rich formatted text is a different matter. Does an application need to draw directly to a canvas and then output the rasterized image to print? What about applications that generate their own reports, how are these to be directed to print? MMMM.... more to think about. Still, carry on putting the pieces together.

Earlier today I did a rather informal audit of the state of the implementation of Gnocl widget set. As my attention to coding is largely demand driven certain implementations are begun, brought to a 'what is required' state and then....  Well, left to looked at some indefinite future period. As I've nothing to draw my attention at the moment, the obvious activity in need of attention is those incomplete items. So, here's a list of what I have to finish. 1) Printing support, only the bare bones are present. 2) Undo/Redo script for text, support for d'n'd needs implementing. 3) Extension of Undo/Redo include text entry items. 4) Recent file choose button. 5) Tooltips work, but rely heavily upon deprecated code. 6) Canvas, add polyline arc and some other simple line primitives (eg. stars). 7) Pixbuf -complete image processing commands. 8) Cairo support -complete support for primitives. 9) Review splashscreen code. 10) Calendar That should do for now...

In the end I decide against the creation of new stock items from pre-existing items. So, here's what a piece of test script and its screenshot looks like #--------------- # test-stockitems.tcl #--------------- # Created by William J Giddings # 06-Oct-2010 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" package require Gnocl   #----- create stock item from an existing buffer -----#   set pb1 [gnocl::pixBuf load -file [pwd]/georgie.jpg] gnocl::stockItem add \     -label Georgie \     -icon "%?$pb1" #----- create stock item from disk objects  -----# gnocl::stockItem add \     -label News \     -icon "%/[pwd]/news.png" gnocl::stockItem add \     -label White \     -icon "%/[pwd]/night1.png" gnocl::stockItem add \     -label Black \     -icon "%/[pwd]/night2.png"   #----- display the whole lot ...

Gtk has support for stock items as well as loading graphics into containers. What has been needed for sometime is the creation of application specific stock items. This is now possible with the new gnocl::stockItem command. Although there's a lot of fiddly work done 'under the bonnet', the Tcl binding is quite simple: gnocl::stockItem add -label News -icon [pwd]/news.png The stock item can then be repeatedly accessed, all resizing etc out large graphics is all taken care of! For example: set but4 [gnocl::button -icon "%#News" -text News] The next step is to allow the creation of stockitems from pixbufs. This might be useful to someone for creating widget buttons that need refreshing.

Hitherto support for the gnocl::toggleButton was minimal. It displayed as text label and that was it. Like other widgets in its class, the togglebutton is also capable of displaying an icon. This it can now do via the new -icon option. All the ususal string formatting options apply.

Just finished putting the final touches together on implementing this new addition to the toolbar options. The Gtk+ toolbar menu button offers an interesting way of tackling things. As expected it provides the option to select items from a pull-down menu but it also allows a widget to be embedded in the menu item too. The only issue I had was getting the signal handlers working for the icon widget. Somehow I've got separate click signal handlers for both the widget and menu down arrow. Ok, there's a "show-menu" signal for the menu which is what is really called for, but who knows? It might be useful to someone so I'll leave it in. It's late now (1am) and so I think its best to leave the documentation till the morning.