|
Gustavo J. A. M. Carneiro wrote: However, I would argue that to display a very large document in a canvas creating a canvas item for each document item is not the best solution; I'd rather have a pool, or cache, of visible canvas items, and just reconfigure them on the fly to show the portion of the document currently visible. I definitely agree that a model based on per-item objects is inefficient when dealing with a large number of items. In this case, one is usually employing the canvas from a data-oriented perspective rather than one that is serving in a GUI role. Approaching the problem of a canvas from a data-oriented perspective suggests that a different type of model is required. One example would be a tabular model, like GtkTreeModel. In this case the rows would be the items and each column would contain variables describing the items. These items would then be mapped to their appearance using something analogous to the GtkCellRenderer. There would be one or more renderers per column that would serve to take the values for each row (item) and use them to decorate the item view. The renderers could also map user interaction with a item view back to the row in the table. Given that GTK+ is centered around the GUI, the goocanvas model makes sense to me. Granted, it would be much more useful if the canvas model could be mapped to other view types. For example, the GtkTreeView could show the hierarchy of items.
I think Havoc's idea of integrating HTML and the canvas is very interesting. HTML would serve nicely for serialization of the canvas and the canvas would provide a interface for integrating widgets within an HTML document. They (HTML rendering and a canvas) are also two things that GTK+ sorely needs, in my opinion. Michael Lawrence |