Re: GNOME spreadsheet work in progress



[Miguel already replied to most of your mail, so I'll only comment on
the missing parts]

>  By raw mode I mean drawing directly on the canvas rather than via an item.
>  I guess creating a new item is the way to do this, which is fine as long
>  as it can be done quickly in C++. However if requires writing a GtkObject
>  that is pretty painful if it has to be done for every type of plot.

You could either write a new item type that know how to draw a single
plot type.  You could also derive an item from GnomeCanvasGroup and
have it manage the necessary primitive items to build a plot.

>  One trivial thing I'm doing now I notice the canvas doesn't permit is
>  grabbing the pointer with the "confine" option on while rubberbanding;
>  this confines the pointer to a single plot if there are multiple plots. It
>  would be nice to allow passing in that argument, and trivial to
>  do. 

I could add a "confine" parameter to the gnome_canvas_item_grab()
option.  It would be a single boolean, not a window, since you want to
confine to the canvas window anyway.  Does this sound right?

>  The bad thing is that it would cost some time right now because
>  we'd have to learn how to use it and how to write our own items,
>  and then re-do some code. We have also been using Gtk 1.0 up to
>  now. So I don't know what we'll do.

Please tell me if you need any help when writing your own items.  It
is not hard; it's basically cut&paste from any of the existing item
types.  I intend to write documentation for the canvas, soon.

>  On another note, if you can stand a tangent on the end of an already-long
>  mail, I think it would be really neat if the Canvas could make itself into
>  a text file and then reconstitute. Each object could have stringify and
>  unstringify (serialize?) methods. Then you could load and save in
>  GnomeCanvas format and have a GnomeCanvas viewer. 

That's a very good idea.  I will look into the Computer Graphics
Metafile (CGM) format, as it may provide just what we need.

  Federico



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]