Re: [GnomeMeeting-devel-list] 1.00 Freeze

[PUYDT Julien <julien puydt laposte net>]

On jeu, 2004-01-29 at 09:37, Damien Sandras wrote:

> >Well, if it needs to be protected against concurrent access from two
> >threads, I consider it broken... If it doesn't, then why lock&unlock?

> That's not new. I thought you knew this since a long time. GTK and GDK
> are not thread-safe, so you always have to protect from concurrent
> access. Callbacks are automatically protected though, but not timers and
> idle functions or gconf notifiers.

Well, it seems I don't know as much as you think ;-)
It's bad.

> Notice GConf is not thread-safe either. So you have to use gdk_threads_
> to access GConf.

Wonderful... oh, the joy...

> >> > * how should the class get the name of the file to open (ui-wise)?
> >> I have to think about it.
> >
> >Eh, looking at the video devices page in the pref, I see there's already
> >something there! So I don't really have to care about the ui... But more
> >about how to do it clean and well.
> 
> Yes, we could get it from the GConf string. The code was already there,
> but requires a redesign. However, I'm not sure getting things from
> GConf inside that plugin is a good idea.

Not inside the plugin, but the call to Open has a PString parameter that
is unused for now...

Snark

PS: I'm now trying to understand why the following piece of code
compiled well in yesterday's package, and brings a compiler complaint
today: (from dialog.c)
GtkWidget *
gnomemeeting_error_dialog (GtkWindow *parent,
                           const char *primary_text,
                           const char *format,
                           ...)
{
  GtkWidget *dialog = NULL;
  va_list args;
   
  va_start (args, format);
 
  dialog =
    gnomemeeting_dialog (parent, primary_text, format, args,
                         GTK_MESSAGE_ERROR);
   
  va_end (args);
}

Shouldn't there be a "return dialog;" at the end!? (and I have a few
other problems like this this morning... 52 lines in the error log!)