ruby-****@sourc*****
ruby-****@sourc*****
2012年 10月 3日 (水) 09:11:13 JST
-------------------------
REMOTE_ADDR = 184.145.80.187
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-trees
-------------------------
@@ -296,7 +296,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 in a view, and particularly we know that there is not a one-to-one mapping between them, hence, it is now easier to grasp the meaning of the above code snippets. If you still have troubles understanding these issues, 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 first of the above two code snippets we can see how tree view 'column objects' are associated with '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 rows. Therefor, not only can there be more than a single attribute associated with a single cell renderer, a single attribute can have different values assigned to it in different rows within a particular column in the model. This organization calls for a mechanism like our 'set_cell_data_func' and its code block which are executed for each row in the tree view, so those different values each attribute can have stored in different rows may be read and loaded.
-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.
+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 cells contain TRUE, by turning the background of these cells 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!