ruby-****@sourc*****
ruby-****@sourc*****
2013年 4月 23日 (火) 23:49:35 JST
-------------------------
REMOTE_ADDR = 70.49.50.179
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-appdx-clrtheory
-------------------------
@@ -33,7 +33,7 @@
As you can see the above example program, called 'display-color-shades.rb', displays a colour greed for all basic colours with an arbitrary depth (a number of desired colour shades), the image of which is shown above in the introduction paragraph. Actually, this program is just a platform in which we use and test our colour management methods, designed to shield a developer from the intricacies and complexities of raw colour code manipulation, mainly relieving him or her from the need to even know how the colour codes look like, let alone memorizing them, their darker and brighter colour shades, and their associated colour code patterns.
- Most often a developer just needs to set or use a certain basic colour, or perhaps its lighter or darker shade. Les frequently, but still often enough colour transparency is desired. We could pack all this functionality into a simple easy to use utility method, that would allow us to use colours in programs just like we use them in human languages, where a small number of basic colours is used to form all needed shades by using adjectives like, 'bright', 'brighter', 'darker' ..., and adverbs like 'more' or 'less', etc. Similarly, the methods should make colour transparency, a.k.a alpha channel - transparent, namely, one should not constantly think about it. Transparency should always be there in the form of reducible opacity. The use of colour management methods should be self-explanatory, and the main colour management method should implement sufficient error reporting, to greatly reduce, if not eliminate, the need for a programmer to check API documentation for colour
management methods, whenever an incorrect argument was used in a method invocation during the early program development phases.
+ Most often a developer just needs to set or use a certain basic colour, or perhaps its lighter or darker shade. Les frequently, but still often enough colour transparency is desired. We could pack all this functionality into a simple easy to use utility method, that would allow us to use colours in programs not unlike in the human languages, where in order to build a large number of different colour shades, only a small number of basic colours is used and operated upon by the the operators, a.k.a. adjectives like, 'bright', 'brighter', 'darker' ..., and/or adverbs like 'more' or 'less', and alike. Similarly, the methods should make colour transparency, a.k.a alpha channel - transparent, namely, one should not constantly think about it. Transparency should always be there in the form of reducible opacity. The use of colour management methods should be self-explanatory, and the main colour management method should implement sufficient error reporting, to greatly reduce, i
f not eliminate, the need for a programmer to check API documentation for colour management methods, whenever an incorrect argument was used in a method invocation during the early program development phases.
If such a utility were available, I believe the majority of programmers would never be bothered with the details of "Digital Colour Theory". The good news is we have such a utility, and if you belong to the above mentioned majority, that could not be bothered with some digital colour theory, you can skip all the theoretic mumbo-jumbo, and jump ahead directly to the section A12.3.3 ((<Putting the theory to work|tut-gtk2-appdx-clrtheory#Putting the theory to work>)), where this program, and even more importantly, the colour management methods we developed, are explained.