Re: Multihead support for GTK

[Erwann Chenede <Erwann Chenede ireland sun com>]

Hi,

Owen Taylor <otaylor redhat com> writes:

[...]

>Another idea for handling display information is what Java does.
>The Java model is:
>
> GraphicsEnvironment
>   GraphicsDevice            == screen
>     GraphicsConfiguration   == visual
>
>The main thing to note here is that a JFrame is associated with
>a particular GraphicsConfiguration, and the screen information
>is derived from that.
>
>Since every widget already has an associated Colormap, and colormaps
>are associated with visuals, and visuals with display, we already
>have sufficient information to know what display a widget is.
>So, the GTK+ interfaces do not really need to be extended, though
>they may fixed some.

That's a nice system, we could extend that mechanism  to associate 
the display connection to the colormap (and therefore each widget).
Good news !

>(The one thing to be careful of here is that I think visuals _are_
>allowed to be present on multiple screens though they don't
>have to be. So you might have to have a number of GTK+ visuals
>correspond to each X visuals in some cases.)

Nop, as far as I know, you have multiple visuals for a screen but not the
opposite (althrough you can have similar visual classes for different screen,
the visual selection will be a bit more complicated once the multihead is
integreted in gtk).

[ start of design stuff removed ]

>> One approached could be to create a GdkConnection to abstract the concept of
>> Display and screen (and other info I guess). All screen-dependent gdk object 
>> would inherit that GdkConnection.
>> All the multihead support could be grouped around the GdkConnection object.
>> All multihead interaction would go through this object.
>
>> e.g to set the desired screen :
>> 
>> gdk_screen_set(GDK_WINDOW(window)->connection,0).
>> 
>> If not specified explicitly GdkConnection would default the current screen.
>> This approach could minimize the API change needed.
>> The API change would be concentrated at the gdk level and at the Gtk 
>> level would not have to change much.
>
>I don't think that adding the capability to move GDK objects between 
>displays is really all that necessary. I think the current paradigm
>where a GDK object corresponds closely to an X object is fine;
>the separation layer that allows some independence is at the GTK+/GDK 
>split.

I wasn't clear :( , what I meant was we'll have an API call to indicate the 
screen to be displayed on to the widget (At creation time before the actual 
window corresponding to the widget is mapped).

[...]

>> > The way it should probably work is that the object should be defined
>> > completely in the port-specific directory and the structure should not
>> > be public - this means that it won't be possible to derive from
>> > GdkDisplay, but I don't think that really makes a lot of sense
>> > anyways.
>> 
>> I agree with you but, should we try to support that for windows also 
>> or will it need a specific design and implem. for each port ?
>> Anyway I guess our main concern is to make it work on X...
>
>I can't see what the relevance is to Windows. As far as I know,
>the only support for multiple monitors is simply extending the
>desktop area over multiple monitors. So, I think there will just
>be a simple stub implementation of GdkDisplay in the windows
>(etc.) port.

Alright, sorry for the silly question...

[ start of atom discussion removed ]

>
>The idea that Havoc had was that you have two layers of atom assignment;
>the atoms that an application sees are assigned within the toolkit.
>And then, these are translated on demand to atoms for the display.
>
>The only real downside I can see for this is that people might 
>occasionally expect atoms to correspond to the atoms they see 
>not through GTK+, and they might get confused; it makes debugging
>a little bit harder. But I think this is a smaller burden then
>the increased inconvenience of having to deal with the fact 
>that atoms are different for each display.
>
>We can also design it so in the case when only a single display
>is open, the GTK+ internal atoms match the atoms on the server,
>though this might prevent potential problems from being caught
>upfront.
>

Good idea, it might be a bit confusing but this will maintain backward 
compatibility.

>> > The API changes are the part that is important to get done real
>> > soon, but there obviously is a lot of underlying implementation
>> > work to be done as well.
>> > 
>> >  - Every use of global data in GTK+ and GDK needs to be examined
>> >    to see if the data is really per-display, not global.

We'll do that this week.

>> > 
>> >    Per display data probably usually should be made user data
>> >    on the GdkDisplay object; by that or some other mechanism it
>> >    needs to be cleaned up when the display is closed.
>> 
>> What do you really mean by user data ?
>
>User data is a mechanism in the GTK+ object system that allows
>arbitrary data to be attached to a widget, keyed by a string ID
>or quark. 
>
>For GtkObject, the primary interfaces are:
>
>void	 gtk_object_set_data	     (GtkObject	     *object,
>				      const gchar    *key,
>				      gpointer	      data);
>void	 gtk_object_set_data_full    (GtkObject	     *object,
>				      const gchar    *key,
>				      gpointer	      data,
>				      GtkDestroyNotify destroy);
>void	 gtk_object_remove_data	     (GtkObject	     *object,
>				      const gchar    *key);
>gpointer gtk_object_get_data	     (GtkObject	     *object,
>				      const gchar    *key);
>void	 gtk_object_remove_no_notify (GtkObject	     *object,
>				      const gchar    *key);
>
>With _by_id() variants for using quarks instead of strings. There
>are similar function for GObject, though naming is still a 
>little bit in flux.
>
>The relevance of object data to this particular situation is that
>quite a few things things need to be per-display. By exploiting
>object data on the GdkDisplay object, we avoid:
>
> 1) Having to add stuff into the GdkDisplay structure from
>    multiple unrelated bits of code.
>
> 2) Having to have lots of places where you keep a list mapping
>    from resource to display.


Ok, sounds good, so will need a GdkDisplay structure and a GdkConnection
(whatever the final name is) which includes a GdkDisplay and information
about the physical screen.

>
>> >    I know that the GtkStyle code, and also (the deprecated, perhaps
>> >    going to be removed) GtkTree code have this assumption in them.
>> 
>> Yes, GtkStyle could create interesting problems as the Style is not stored
>> in the X Server as for example X Resources are !
>
>Well, this assumes that you want the Style settings to be per-display.
>
>But making that assumption, probably the right way to do it is to
>make the global structures in gtkrc.c per-display and then have
>the concept of parsing in an RC file in the context of a particular
>display. We could then store the name of the theme file on the
>display in some fashion; in fact, there will be, in GTK+-2.0 a mechanism
>for configuring global settings via properties, so we can just use
>that setting. 
>
>(Storing the RC file itself on the display is
>problematical due to references to local resources like image files.)
>
>Luckily, the theme code in GTK+ has always been structured
>to allow different themes for different widgets, so there is no
>fundemental problem with having different styles/theme-engines
>and so forth per display.

I guess that for the moment this is not really important. The style applied to
the widget will be the one one which the process runs.

Thanks for the info and comments.

When is the next API freeze ? 

Regards,

	Erwann