Re: [gtk-list] Re: Proposal: how about a gtk_canvas widget?
- From: Marius Vollmer <mvo zagadka ping de>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Proposal: how about a gtk_canvas widget?
- Date: 11 May 1998 10:03:18 +0200
Des Herriott <firstname.lastname@example.org> writes:
> Having thought a bit more about how such a canvas would work, each item
> type would need its own list of properties; e.g. location, colour, line
> width. All items would have a common set of properties (location, for
> example), and some item would have their own (an arc item needs a
> number of degrees to rotate through, for example). Hmm, maybe a
> gtk_canvas_item class & subclasses would be useful...
The Gtk object system already has support with, via the functions
gtk_object_set, gtk_object_get, etc. It also has support for
inheritance (of course) and signal handlers for event notification. I
think it would be advisable to use this substrate for implementing the
> As for tags, what's needed is to map an arbitrary tag number (or
> string) to a list of canvas items, within the canvas object. Then any
> function can refer to a list of items by just naming a tag...
The tag stuff of the Tk canvas is a very flexible thing, but I never
quite liked it. You actually have to come up with unique names and
that can be a drag. I once wrapped Tk in a nice Scheme layer and I
replaced the concept of tags with "sets" and "groups", which are not
as flexible as tags but where good enough for all my uses and much
friendlier to use.
The basic premise was that you work with the canvas object directly
and not thru some name. Like you work with a widget directly and not
by using its name. (Yes, in Tcl you have to use the names but I found
that this breaks down pretty fast for medium sized programs).
A "group" was a special canvas object that collects some other convas
objects. When you move the group, all objects in it move, when you
destroy the group, all elements are destroyed. Each canvas object can
be in at most one group and you can navigate this hierachy.
A "set" is a more loose collection of objects. It is mostly useful
for binding event handlers to a certain type of objects, like all
wires in a schematic editor. The only real differences from a groups
are that an object canbe in more than one set and when a set is
destroyed, its elements are not destroyed.
This is a quite convenient abstraction and saves you from having to
invent tag names that are unique across your whole application. It is
not all that different from tags, I think.
> The Tk canvas also allows a group of items to be tagged based on a
> reasonably powerful search spec., e.g. tag all items, all items within
> a bounding box, all items which stack above a given item, and so on.
> This would also be desirable to implement somehow...
This could be handled with several predefined sets, that change
] [Thread Prev