On Thu, 02 Apr 2009 16:53:11 -0500
Thomas Stover <tho...@wsinnovations.com> wrote:
>
> Well if any lone googlers ever find this, and want to know what
> happened. I did fix it with this, but I still think the right way is
> to some how create a new structure that is "inherits" the
> GSourceFuncs and adds a place to store the event handle and the
> protected data (in this case global_int). If there was an example of
> how to create a source, or some doc on a source life cycle, that
> would be helpful. I did look at the source, but was quickly lost. I'm
> guessing the main loop architecture involves multiple "sources",
> "fds", and "realization callbacks" all being able to exist without
> "extras". So for instance 1 fd could trigger 5 sources, which each
> result in glib calling a variable number of callbacks. If only there
> was more time to spend on these things....
I may be missing your point (I would have to read through the
back-posts to make sense of it), but if you want to create your own
source object to hold its own protected/private data, it is just this:
struct MySource {
GSource source;
/* my data, such as a gpointer but it could be anything and as much member data
as you want */
gpointer data;
};
It is created with:
MySource *my_source = (MySource*) g_source_new(&source_funcs, sizeof(MySource));
/* initialise data */
my_source->data = my_object;
For more information see this, in particular the section "Creating new
sources types":
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
An idle object may already do much of what you want. With windows, I think
it uses a window event object under the hood.
Chris
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
