ruby-****@sourc*****
ruby-****@sourc*****
2012年 9月 23日 (日) 10:31:58 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, which by now should not be an obstacle anymore. We know how columns in model are related to view, and particularly 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 "((<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 single column (one-to-many relationship), should reside in their respective columns across different model records (rows), hence each row can store a different value for a particular cell-renderer attribute.
-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 and 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.
+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.
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 associated with a particular cell renderer which in turn is mapped to a tree view column via the column, associated with the renderer by 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!