ruby-****@sourc*****
ruby-****@sourc*****
2009年 3月 9日 (月) 02:39:10 JST
-------------------------
REMOTE_ADDR = 74.15.84.244
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-agtkw-draww
-------------------------
@@ -167,6 +167,29 @@
You should notice a few things in the above listing. First, a ((*parray*)) is used to track the points that are added to the drawing area. This is fine when we draw lines with the mouse, however when a Gdk::Drawable's drawing instance methods are used their output is not saved in the array. This is important, because every time ((*expose_event*)) is emitted (and this is every time focus is changed, or mouse is dragged outside our application window) the drawing area is cleared, and has to be repainted. We can repaint what we have saved but not what was generated by Gdk::Drawable's drawing instance methods!
+{{image_right("agtkw-02-drawingareas.png")}}
+
+My first image above suffered due to just described problem with the ((*expose_event*)), and here on the right hand side image we can see that there is a solution to this problem. To fix it we need to place the our shape drawing instance methods or algorithms into the callback triggered by the offending ((*expose_event*)) event:
+
+{{br}}
+
+ def expose_event(area, event, arr)
+ # Loop through the coordinates, redrawing them onto
+ # the drawing area.
+ arr.each do |e|
+ points = []
+ x = e[0]
+ y = e[1]
+ points = [ [x,y], [x+1,y], [x-1,y], [x,y+1], [x,y-1] ]
+ area.window.draw_points(area.style.fg_gc(area.state), points)
+ alloc = area.allocation
+ area.window.draw_rectangle(area.style.fg_gc(area.state), false, 10, 10, 75, 50)
+ area.window.draw_arc(area.style.fg_gc(area.state), true,
+ alloc.width/2, alloc.height/2, alloc.width/3, alloc.height/3, 0, 64 * 360)
+ end
+ end
+
+
When we draw our lines we add four additional points around the original (x,y) position, which has a line thickening effect. {{image_right("dialog-warning.png")}} All in all, this program shows some serious drawbacks in the way vector graphic is implemented in GTK+. I do believe that GTK+ flaws in this area and even more so in GTK+ Ruby implementation, are one of major disadvantages of GTK+ system in general and perhaps the main reason that GTK+ has never become what it deserves to be!
It is true, that Cairo graphic is supposed to address and solve most of these vector graphic issues and major flaws that plague GTK+, but I also believe, that native GTK+ handling of vector graphics should be fixed regardless of how well Cairo graphics will be adopted and implemented.