Re: Gdk support for multiple Screens

[Owen Taylor <otaylor gtk org>]

Paolo Molaro <lupus@lettere.unipd.it> writes:

> > > With my patch you call gdk_init() for every new connection:
> > > gdk_init returns a pointer to a GdkContext structure you can
> > > use later with gdk_context_push().
> > 
> > Hmmm, I'm not sure that this is the right appoach. gdk_init()
> > initializes a lot of stuff which is global to all displays.
> 
> The gdk_init() function is changed to initialize global stuff
> only once :-)

Well, yes, but then you are using gdk_init() for one thing on
the initial call, and something else on subsequent calls.
Which strikes me as a bit of an odd design.
 
> > I'd rather see:
> > 
> >  gdk_init(&argc, &argv);
> >  GdkContext *gdk_context_get_default();
> >  GdkContext *gdk_context_new (const gchar *display);
> 
> With that you loose the ability to handle gdk options on a per-display
> basis: think of enabling/disabling xshm or any other per-display
> option we may add later...

But I'm not sure that having to built argv vectors is
the best interface for programmatically setting such things.
And the user has only supplied one set of of command line
arguments. Perhaps it is the best way. Certainly it doesn't
have to be decided this moment.

> > > GTK would require few changes: the problem is to make this work
> > > flawlessly with threads...
> > 
> > There are three ways to deal with global data structures and
> > threads:
> > 
> >  1) Lock global data.
> >  2) Avoid global data.
> >  3) Make global data per-thread.

[...]

> > 3) I think this is probably the right approach here. This probably
> >    requires a call to gdk_threads_init_thread() for each 
> >    new thread.
> 
> I was thinking mainly about APIs that are not multi-display savvy:
> we'll have replacements for that anyway, so people using threads
> should use those replacements. ie
> 	gdk_context_load_font(GdkContext *, gchar*);
> instead of
> 	gdk_load_font();

Consider not that, but rather:

 gtk_window_new()
 gtk_dialog_new()
 gtk_font_selection_dialog_new()
 [...]

Each toplevel widget needs an implicit argument for which
display/screen it gets created on.

Of course, we could create new variants for all of these.
But, the alternative is _per-thread data_. That is:

  gtk_widget_push_display () 

affects only widgets created within one particular thread.

All thread libraries provide functionality for storing data
particular to one thread, so this type of thing is quite
easy to do.

Regards,
                                        Owen