ruby-****@sourc*****
ruby-****@sourc*****
2013年 3月 20日 (水) 04:42:24 JST
-------------------------
REMOTE_ADDR = 184.145.81.215
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-dancr-intro
-------------------------
@@ -18,6 +18,6 @@
We have indeed, just slightly, touched on these issues already in previous chapter in paragraph 11.1 "((<Drawing Widgets|tut-gtk2-agtkw-draww>))" discussing program called 'drawingareas.rb', suggesting you get familiar with the way user interactions may cause a drawing area to be redrawn (actually cleared, and how the programmer must make sure the drawn items do not get lost) when window is moved, resized, or even when focus is changed on widgets and windows. The program also implements the most basic "redo" functionality, by allowing user to clear the screen by pressing the Delete key.
-Though, what is shown in chapter 11 in 'drawingareas.rb' program is far from what the full-blown "undo/redo" functionality would look like, understanding the two, namely, the manual clearing of the drawing area on the one hand, and on the other the automatic clearing/redrawing of the window when 'expose-event' is emitted, is absolutely required before you can attempt to implement stacked, partial "undo/redo" behaviours, usually triggered when user repeatedly presses the((*<Ctrl+Z>*))keys, which also reveal how copies of drawing area surfaces have to be stored by the programmer each time electronic pen, brush, or 'eraser' is applied to the drawing area. In fact the illusion of the phantom (non-existent) 'electronic eraser' is achieved, by repainting the drawing surfaces with the saved image of the drawing area before user made any changes to the surface.
+Though, what is shown in chapter 11 in 'drawingareas.rb' program is far from what the full-blown "undo/redo" functionality would look like, understanding the two, namely, the manual clearing of the drawing area on the one hand, and on the other the automatic clearing/redrawing of the window when 'expose-event' is emitted, is absolutely required before you can attempt to implement stacked, partial "undo/redo" behaviours, usually triggered when user repeatedly presses the((*<Ctrl+Z>*))keys, which also reveal how copies of drawing area surfaces have to be stored by the programmer each time electronic pen, brush, or 'eraser' is applied to the drawing area. In fact the illusion of the phantom (non-existent) 'electronic eraser' is achieved, by repainting the drawing surfaces with the saved image of the drawing area before user made the latest changes to the surface. Subsequently pressing the "<Ctrl+Z>" key combination, repaints the drawing area with the image stored before the ear
lier stored image, ...
We will delve into our investigation of drawing surfaces, by rewriting the 'drawingareas.rb' program from chapter 11, turning the plain single colour background surface into a background adorned with an arbitrary image you load from an image file on your disk.