gnome-canvas-using.html

linux下gnome编程

          pass in an integer when the item is expecting a double, the
          parsing code will read too far, thus corrupting the stack
          and probably causing your application to crash. These
          parameter lists are often the first place to look when
          you're experiencing mysterious Canvas crashes.
        </P
><P
>          Here's an example of creating a rectangle Canvas item. The
          rectangle will be black and will stretch from world
          coordinates (10.0, 10.0) to (25.0, 50.0).  The line will be
          two units wide:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>GnomeCanvasItem *item;
item = gnome_canvas_item_new(group, GNOME_TYPE_CANVAS_RECT,
  "outline_color", "black",
  "x1", 10.0, "y1", 10.0,
  "x2", 25.0, "y2", 50.0,
  "width_units", 2.0,
  NULL);
        </PRE
></TD
></TR
></TABLE
><P
>          You could just as easily use the gnome_canvas_rect_get_type(
          ) function instead of the GNOME_TYPE_CANVAS_RECT macro. They
          are equivalent, so it's mostly a matter of style. We'll
          explore the long list of Canvas items in Section 11.4.
        </P
><P
>          Once your item exists, you can find out its current size and
          position with gnome_canvas_item_get_bounds( ). This function
          returns the bounding box of the item inside the coordinate
          system of its immediate parent item. You can go in the
          reverse direction and find out which item resides at a given
          point on the Canvas by calling gnome_canvas_get_item_at( ):
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_get_bounds(GnomeCanvasItem *item,
    double *x1, double *y1, double *x2, double *y2);
GnomeCanvasItem *gnome_canvas_get_item_at(GnomeCanvas *canvas,
    double x, double y);
        </PRE
></TD
></TR
></TABLE
><P
>          You can grab the input focus for an individual Canvas item
          with gnome_canvas_item_grab_focus( ):
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_grab_focus (GnomeCanvasItem *item);
        </PRE
></TD
></TR
></TABLE
><P
>          When you do this, all keyboard input will go to that
          particular Canvas item until another Canvas item, widget,
          or application grabs it back. This feature is particularly
          handy if you need an item to display text as the user types
          it. We'll learn more about how the Canvas interacts with GDK
          events in Section 11.5.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1129"
>Moving Canvas Items Around</A
></H2
><P
>          Unlike a simple double-buffered rendering engine in which
          you draw directly to the buffer, the GNOME Canvas supports
          an infrastructure of movable objects that the Canvas draws
          to the double buffer for you. If all you wanted was a static
          graphics buffer, you could fill the Canvas with items and
          leave them where they lay. However, that would be wasting a
          good portion of the Canvas's functionality. Moving an item
          to a new location is as simple as calling a single function
          with the new world coordinates:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_move(GnomeCanvasItem *item,
    double dx, double dy);
        </PRE
></TD
></TR
></TABLE
><P
>          Since two Canvas items can't occupy the same rendering space
          (not counting alpha transparency, but we'll ignore that
          for now), the Canvas has to choose which one to display on
          top. It makes this decision by following the hierarchy of
          items from the topmost leaf nodes all the way down to the
          root group. Items closer to the root group always appear
          behind items farther away from the root group. Each branch
          of the hierarchy is another Canvas group because only
          groups can contain other items. Thus all items in a higher
          group appear on top of all items in a lower group.
        </P
><P
>          However, all items contained by the same group are more or
          less all at the same level. The Canvas remembers the order
          in which you add items to a group and displays the most
          recently added items on top. You can change that order with
          the raise and lower functions:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_raise(GnomeCanvasItem *item,
    int positions);
void gnome_canvas_item_lower(GnomeCanvasItem *item,
    int positions);
        </PRE
></TD
></TR
></TABLE
><P
>          These first two functions will raise or lower an item within
          a group by a numerical offset, positions. If you called
          gnome_canvas_item_raise( ) on the fifth item in a group of
          10 items with a positions parameter of 4, that item would
          move from the middle of the group to the second-to-top
          item. The Canvas will not move an item past the absolute top
          or bottom of a group, so if you pass a huge number to those
          functions, the item will end up at the top or bottom of the
          same group rather than continuing to the next group. If you
          specifically want to raise an item to the top or lower it to
          the bottom of its current group, you can call the
          following functions:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_raise_to_top(GnomeCanvasItem *item);
void gnome_canvas_item_lower_to_bottom(GnomeCanvasItem *item);
        </PRE
></TD
></TR
></TABLE
><P
>          The raise and lower functions, as well as the move function,
          work equally well on a Canvas group, which is still, by
          nature, a Canvas item. When you move a group around, you
          move all the items contained in that group as if they were a
          single aggregate object, including any groups inside that
          group. Moving, raising, or lowering a group performs the
          same action on the entire collection of items.
        </P
><P
>          Although the raise and lower functions cannot implicitly
          move an item to a different group, you can do that
          explicitly with the following function:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_reparent(GnomeCanvasItem *item,
    GnomeCanvasGroup *new_group);
        </PRE
></TD
></TR
></TABLE
><P
>          By default, reparenting an item to a new group will put that
          item at the top of that group. But don't be surprised if
          reparenting an item also causes it to jump to new
          coordinates. The item keeps its old item-based coordinates,
          so an item at (10.0, 25.0) in the old group's coordinates
          will move to (10.0, 25.0) in the new group's
          coordinates. Unless the two groups share exactly the same
          coordinates in the Canvas, the item will end up at a
          different Canvas offset in the new group. One limitation you
          may have noticed from the function prototype is that you
          can't use the reparent function to move an item to a
          different Canvas widget. You can only move it to another
          group in the same Canvas. The function does not ask for a
          pointer to the GnomeCanvas widget because the pointer is
          implied by the Canvas item.
        </P
><P
>          Because groups are Canvas items too, you can reparent them
          as well, but you should be aware of a couple of
          peculiarities that apply only to group reparenting. First,
          you cannot reparent a group to itself. This limitation
          should be obvious. Somewhat less obviously, you may not
          reparent a group to another group within itself. You must
          first move the target group outside of the group you want to
          reparent. If you were allowed to reparent a group to a group
          within, the Canvas would quickly become corrupted by
          circular tree branches: Group A contains group B, which
          contains group A, which contains group B, and so on, ad
          infinitum.
        </P
><P
>          Another useful feature of the GNOME Canvas is the ability to
          completely hide an item-or an entire group-without removing
          it from the Canvas. You can turn it on and off like a light
          switch, just as you can with normal widgets, using the
          following functions:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_show(GnomeCanvasItem *item);
void gnome_canvas_item_hide(GnomeCanvasItem *item);
        </PRE
></TD
></TR
></TABLE
><P
>          A hidden item or group is still a valid object. The main
          difference between a hidden item and a visible one is that
          the Canvas skips over hidden items when it goes to render
          the Canvas contents to the drawing buffer. You can still
          move hidden items around and apply transforms to them. When
          you show them again, they will take on their new, modified
          state.
        </P
><P
>          Normally you shouldn't need to hide objects to avoid flicker
          before making major changes to them. The Canvas defers
          painting updates to an idle function rather than demanding a
          fresh redraw each time the Canvas changes, so very likely if
          you apply several changes in a row, they will be rendered to
          the double buffer right away, and only transferred to the
          display the next time the idle handler fires. If you're
          desperate, though, and can't get rid of some annoying
          flicker, you can use the freeze function from the Canvas's
          GtkLayout ancestry:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>gtk_layout_freeze (GTK_LAYOUT (canvas));
        </PRE
></TD
></TR
></TABLE
><P
>          In reality you should never need to go this far, unless you
          are doing something very unusual with the Canvas, in which
          case you might be better off rethinking your design.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN1149"
>Transformations</A
></H2
><P
>          The Canvas uses libart's affine transformations to move
          items around, by applying simple spatial offsets. The
          infrastructure is already there for performing much more
          complex transforms, separately, on any item on the
          Canvas. As we learned in Chapter 10, affine transforms are
          very powerful and very flexible.  By adjusting the affine
          transforms a bit, you can invert, rotate, scale, and shear
          your Canvas items. Simple operations like scaling and
          rotating come with dedicated functions, so you won't need to
          touch the affine matrices directly:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_scale(GnomeCanvasItem *item,
    double x, double y, double scale_x, double scale_y);
void gnome_canvas_item_rotate(GnomeCanvasItem *item,
    double x, double y, double angle);
        </PRE
></TD
></TR
></TABLE
><P
>          More complex operations can perform custom transforms
          directly on a Canvas item. Setting an absolute transform
          will completely override any current transforms:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_affine_absolute(GnomeCanvasItem *item,
    const double affine[6]);
        </PRE
></TD
></TR
></TABLE
><P
>          You might need to do this if you want to start a series of
          transforms from scratch. Another use, in conjunction with
          art_affine_identity( ), is to remove transforms entirely
          so that the item appears in its most basic state. Be careful
          with this approach, however, because it will also reverse
          any gnome_canvas_item_move( ) operations as well.
        </P
><P
>          In most cases you'll probably want to add transforms rather
          than replacing existing transforms. Affine transforms are
          inherently cumulative, so it's very easy to accurately apply
          successive transforms on top of each other.  In fact, each
          time you move an item, you are really applying yet another
          translational transform to the current offset. This
          operation is conceptually similar to art_affine_multiply( ),
          although the Canvas does not actually use that function to
          move items around. Instead it uses the following function:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>void gnome_canvas_item_affine_relative(GnomeCanvasItem *item,
    const double affine[6]);
        </PRE
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="gnome-canvas-coordinates.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="gnome-canvas-items.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Coordinate Systems</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="gnome-canvas.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Canvas Items</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>