[Techtalk] More questions about C and GTK+ stuff

[Wim De Smet]

On 5/17/07, Wolfgang Petzold <petzold at villa-chaos.de> wrote:
> Michelle Konzack:
> > Now I have to find out, how I can put the collected data fro,
> > my_cool_func() back into the GtkTreeView widget...
>
> Well, in short -- I have no experience.
>
> Looking at your code skeleton, I would try to get some
> GTK data structure that you need to update from within
> the new thread into the "param" parameter. As far as I
> can tell, "param" can be any data structure you like
> (e.g. your GtkTreeView widget, or even an array of
> widgets), you cast it to "void *" to fit it into the
> general signature of the callback function for the new
> thread, and since this callback function knows what
> data structure it has been given, you should be able
> to cast it back.
>
> Does that sound reasonable to anyone else?

I'm not up on the details of GTK+ but I'm assuming that you'd want to
eventually use some sort of trigger to start the thread. The thread
should be able to get a callback function to the widget somewhere that
it can call to have it update. The widget should use a protected
access method to the data so it doesn't try to read any raw data that
is only partly written.

One way I would consider doing it is calling my_cool_func with a
pointer to your callback function, and a pointer to the data
structure. Your data structure would be something you create functions
for like:
t_message_list *message_list_create() --> returns a pointer to a
struct which you can make like this:
typedef struct _t_message_list {
 t_sem* lock;
 ...data
} t_message_list;

and then access it with accessor functions like:
some_list_type* get_messages(t_message_list list)
which would then handle locking and stuff on the data. Obviously you'd
use as many glib data structures as possible in this. You can even
extend it a bit further, making it a full model/view/controller type
thingie by storing a list of callback methods and calling all of them
in turn from the data collection thread whenever a data update is
made.

This is about the same as Wolfgang's method except for maybe some
extra wrapping. I'm not sure just in how far you can prevent the
widgets trying to refresh the list on other events, it all depends on
what you're doing. I hope this makes some kind of sense...

greets,
Wim