ruby-****@sourc*****
ruby-****@sourc*****
2012年 9月 23日 (日) 08:14:19 JST
-------------------------
REMOTE_ADDR = 184.145.80.187
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-trees
-------------------------
@@ -268,7 +268,7 @@
A cell data function provides means to modify cell-renderer's attributes for each individual tree view cell. It is a block of code that is called for any desired cell renderer in a selected column for each single row before that row is rendered. Since the setting for a cell-renderer's property remains in effect for the entire column from the point (i.e. row) where it was set to the point (row) where it is overridden by a new setting, you need to carefully plan when to set and when to reset them. For instance if you wanted to render a background of each row in a tree view in different colour, you'd have to set the cell renderer's background property for every cell renderer in that row to a desired colour. Which means that there has to be a place that each cell-renderer will consult each time just before it is about to render its data. This place is the code block defined for a Gtk::TreeViewColumn#set_cell_data_func. Every column in a tree view can potentially call this method
with an associated code block. In our instance, just mentioned in this paragraph above, where we would like to render the background of every row in a different colour, every cell in the tree view would need to invoke "set_cell_data_func" with an appropriate code block. Indeed, many times you would want to render only some particular cell, or perhaps a few cells, with certain cell-renderer's properties set to different values than are set for the rest of the cells in the tree view. Shortly, we will see examples for both of these situations. But let's look at how these features, that allow us to so flexibly modify cell renderer attributes, fit together.
-Before we delve too deep into the mechanics of dealing with and programming the tree view cell rendering, we need to mention that many times certain cells in a tree view need to be presented differently than the rest of them. Perhaps, most of the data needs simply to be rendered as active and displayed normally with no adornments, while some cells need to be exposed or highlighted and others again may need to be shaded or disabled in the tree view. In such situations this inevitably reveals a tighter than usual relationship between the model and the view. We have already seen evidence of this on previous page in the paragraph entitled "((<Dissecting the column creation|tut-gtk2-treev-parts#Dissecting the column creation>))" when discussing the hash parameter for cell-renderer's attributes where attributes were passed to Gtk::TreeViewColumn object's constructor and to the "set_attribute" and "set_attributes" instance methods, as a set of name/value pairs, for whose values we
were adamantly insisting were not the values of the attributes but rather the column numbers of their respective values in the model.
+Before we delve too deep into the mechanics of dealing with and programming the tree view cell rendering, we need to mention that many times certain cells in a tree view need to be presented differently than the rest of them. Perhaps, most of the data needs simply to be rendered as active and displayed normally with no adornments, while some cells need to be exposed or highlighted and others again may need to be shaded or disabled in the tree view. In such situations this inevitably reveals a tighter than usual relationship between the model and the view. We have already seen evidence of this on previous page in the paragraph entitled "((<Dissecting the column creation|tut-gtk2-treev-parts#Dissecting the column creation>))" when discussing the hash parameter for cell-renderer's attributes where attributes were passed to Gtk::TreeViewColumn object's constructor and to the "set_attribute" and "set_attributes" instance methods, as a set of name/value pairs, for whose values we
were adamantly insisting were not the values of these very attributes but rather the column numbers of their respective values in the model.