Re: [gtk-list] Re: Gdk support for multiple Screens

[Paolo Molaro <lupus lettere unipd it>]

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.

>  - 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...
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.

>  - 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().
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...

lupus