ruby-****@sourc*****
ruby-****@sourc*****
2012年 8月 17日 (金) 04:06:53 JST
-------------------------
REMOTE_ADDR = 70.49.49.99
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-parts
-------------------------
@@ -268,7 +268,7 @@
# stored together in the model (store).
column = Gtk::TreeViewColumn.new("Buy", renderer, {:text => 3, :foreground => 4})
-Particularly misleading in the above code and in the API documentation is the part (if read inattentively) suggesting that the hash of attributes may be used to set the attributes to their respective values. That may have been an original Gtk GUI developer's goal that never materialized, or perhaps not, since the way it works now is rather useful though undoubtedly very convoluted. Namely, one may incorrectly conclude that in the above code we could set the foreground colour directly when creating the view column. This, however, is not the case, namely all attributes in the hash can only be assigned their respective column numbers in the list or tree store, which, if model and view columns are incorrectly assumed to be mapped to one another will cause inconsistent programming errors - (note, model columns are not the same as view columns, moreover, view columns are never directly coded or specified! (You will understand this better when defining sort column in tree view, whe
re the column number is not the view but rather model column number.)) Unless you need to design tree views that look like file browser, where each row is rendered in alternate colours, you can simply ignore the sophistication of storing miscellaneous system attribute values in a list or tree models along with the user data. (We will, however, look at this again in the following pages.)
+Particularly misleading in the above code and in the API documentation is the part (if read inattentively) suggesting that the hash of attributes may be used to set the attributes to their respective values. That may have been an original Gtk GUI developer's goal that never materialized, or perhaps not, since the way it works now is rather useful though undoubtedly very convoluted. Namely, one may incorrectly conclude that in the above code we could set the foreground colour directly when creating the view column. This, however, is not the case, namely all attributes in the hash can only be assigned their respective column numbers in the list or tree store, which, if model and view columns are incorrectly assumed to be mapped to one another will cause inconsistent programming errors - (note, model columns are not the same as view columns, moreover, view columns are never directly coded or specified! (You will understand this better when defining sort column in tree view, whe
re the column number is not the view but rather model column number.)) Unless you need to design tree views that look like file browser, where each row is rendered in alternate colours, you can simply ignore the sophistication of storing miscellaneous system attribute values in a list or tree models along with the user data. (We will, however, look at this again later.)