Re: Gdk support for multiple Screens

[Owen Taylor <otaylor gtk org>]

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

> On Fri, Jun 26, 1998 at 12:51:38PM -0400, Owen Taylor wrote:
> > julian.gosnell@nomura.co.uk writes:
> > > Are there plans to support multiple screens ? Is it included in a project plan ?
> > >  Is there a timescale ?
> > 
> > It has been discussed some. (Partly in the context of the Xprt
> > extension, which would require support for multiple displays)
> [...]
> 
> I'm almost done with porting my previous patch and testing a few
> things: hopefully in a few days I'll commit the changes to a
> separate branch for others to test.
> 
> >  - XID's need to be tracked on a per-display basis.
> 
> Done.
> 
> >  - Events need to be retrieved from multiple event queues and
> >    dispatched to the correct window.
> 
> Done.

Great!
 
> >  - All globally stored information such as the list of XInput
> >    devices, the list of visuals, the current Input Method, needs
> >    to be tracked on a per-display basis.
> 
> Almost done: I need help to find what is needed in the context
> structure for the input method...

The problem is that the GdkIM stuff assumes that only one Input
Context can be active at once. This is completely false when
you go to multiple displays, so needs to be reworked. But it
isn't used by applications, so this shouldn't be a problem.

> I'll probably add a gdk_context_set_user_data(GdkContext*, char* key, gpointer data)
> so extensions such as gdkimlib or gtkgl will be able to store data
> in a per-display manner.

For Imlib, I'm planning to add such a mechanism to Colormaps - 
since they are per-screen, that should relieve the need to
do it per-context. But it could be useful for other extensions.
 
Of course, the global context should be used for very little -
basically just when creating new objects. In other circumstances, the
display or context should be stored on a per-object basis.

> >  - Code such as gdk_font_load() and gdk_colormap_new() that 
> >    uses gdk_display to figure out the display needs an alternate
> >    method of getting the current display. One possibility 
> >    is a 'context' structure that holds the current display
> >    and screen for such calls. New variants could be added
> >    for multiple-display-savvy programs.
> 
> 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.

I'd rather see:

 gdk_init(&argc, &argv);
 GdkContext *gdk_context_get_default();
 GdkContext *gdk_context_new (const gchar *display);

Or something like that.

> The existing interface that doesn't provide a mean to know
> the display will use a global variable (gdk_current_context).
> 
> > GTK:
> > 
> >  - The code for handling selections and DND needs to be able
> >    to handle multiple such events going on on different displays
> >    at the same time.
> >  - A way to specify the visual for newly created windows is 
> >    needed. (Perhaps gtk_widget_push_screen() to go along with
> >    gtk_widget_push_visual(), etc.)
> 
> 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.

1) doesn't work here - the locking is in place, the problem
is that the different threads shouldn't change what the
other threads set.

2) Hard to do and maintain backwards compatibility.

3) I think this is probably the right approach here. This probably
   requires a call to gdk_threads_init_thread() for each 
   new thread.

[ Another potential problem is that we probably will soon support
  storing gtkrc data in a root-window property. But I don't
  see supporting multiple sets of GtkRC data within one application.
  So it would probably only pay attention to the root window 
  of the initial display ]

Regards,
                                        Owen