ruby-****@sourc*****
ruby-****@sourc*****
2012年 9月 24日 (月) 01:24:57 JST
-------------------------
REMOTE_ADDR = 184.145.80.187
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-trees
-------------------------
@@ -280,7 +280,7 @@
When we first started to discuss the renderers and their attributes we were not yet able to venture into any meaningful code examples precisely because all these examples utilized "set_cell_data_func". It was also hard to deal with the model/view relationships because we lacked basic understanding of the two. We now know how columns in a model are related to the columns a view, and particularly we know that there is not a one-to-one mapping between them, hence, it is easier to grasp the meaning of the above code snippet. If you still have troubles understanding it perhaps you should reread the introductory chapter with the "((<Dissecting the column creation|tut-gtk2-treev-parts#Dissecting the column creation>))" paragraph in it. In the above code snippet we can see how a tree view column objects are associated with a cell renderer objects, and that the attributes are actually referred to their pertinent cells in model columns, where their values, potentially many for a singl
e column (one-to-many relationship), should reside in their respective columns across different model records (rows), hence each row can store a different values for any number of different cell-renderers' attributes.
-All that was just said is encapsulated it the second of the two program examples below called "modelNview_demo.rb". But let's not get ahead of ourselves here and concentrate on the simpler version of the two examples that follow, where we do not store the values for renders' attributes in the model, but change a cell-renderers property according to the different data values it renders. Indeed, the data resides in persistent model. The first of the following two program examples is our "Grocery List" program example we have already seen, with one new feature, namely, we want to highlight only those rows for which the "Buy" column contains TRUE, by turning the background of cell with TRUE value to red.
+Most of what was just said is encapsulated it the second of the two program examples below called "modelNview_demo.rb". But let's not get ahead of ourselves here and concentrate on the simpler version of the two examples that follow, where we do not store the values for renders' attributes in the model, but change a cell-renderers property according to the different data values it renders. Indeed, the data resides in persistent model. The first of the following two program examples is our "Grocery List" program example we have already seen, with one new feature, namely, we want to highlight only those rows for which the "Buy" column contains TRUE, by turning the background of cell with TRUE value to red.
Not surprisingly all the work to set the renderer's background property is done in the code block associated with the ((*set_cell_data_func*)) method. Note that this method is passed a cell renderer, which associates it with this particular renderer which in turn is mapped to a tree view column via the column constructor (Gtk::TreeViewColumn.new), and subsequently by the Gtk::TreeView#append_column(column) statement to the tree view; so all ((*render, column,*)) and the((*tree view*))are all connected (i.e. related.) The block associated with the "cell data function" is executed for every row for that particular view column. However, what may surprise a novice GTK+ programmer is that there is no((*:background*))attribute present in the hash of attribute name/value pairs in the constructor for the column!