Re: multi head porting

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> The attached patch allows to compile gtk head on win32
> again (not supporting multiple screens yet). 
> It was done with the major goal to minimize the required 
> changes on the backend code.

Thanks a lot for looking at this. I've been meaning to try
and get some time to get the other backends straightened up 
but haven't had any time.

Did you see:

 http://mail.gnome.org/archives/gtk-devel-list/2002-April/msg00103.html

I'm not sure that minimizing the required changes to the 
backend code is really the right goal. I think, instead,
the right goal is minimizing the total amount of backend
code.

If we take your approach of:

==
void
gdk_display_beep (GdkDisplay * display)
{
  g_return_if_fail (GDK_IS_DISPLAY (display));

  gdk_beep ();
}
===

Then we need to implement:

 gdk_display_beep:  in gdk/x11/ and gdk/
 gdk_beep:          in gdk/x11/ and gdk/win32

While if we turn it around and do:

====
void
gdk_beep (void)
{
  gdk_display_beep (gdk_get_default_display ());
}
====

Then we need to implement:

 gdk_beep:         in gdk/
 gdk_display_beep: in gdk/x11 and gdk/win32

Which is both less implementation and a more straightforward 
implementation.  The Win32 gdk_display_beep() implementation should be 
as simple for now as changing

 void
 gdk_beep (void)

to 

 void
 gdk_display_beep (GdkDisplay *display)

For code that really does need to be duplicated between all
single-head ports, it certainly makes sense to figure out a way 
to put that in gdk/, though it might be easier to do one port first
(say Win32) and then try to figure out from there what makes
sense as common code. 

> With this goal in mind there 
> are some places where it could get huge improvements if the
> multi-head api isn't inscribed in stone yet :
> 
> gdk_colormap_get_screen()
> Only the multi-head version needs to store a screen with
> every colormap. Single Head version would return the 
> default screen. [The GdkScreen* field from the GdkColormap 
> struct could be removed and the multi-head version would
> maintain it's own hashlist to remember the Colormap/Screen
> relations.]
> 
> gdk_visual_get_screen()
> Same logic as for gdk_colormap_get_screen(), removing
> GdkScreen* from _GdkVisual struct, whiches content needs to be 
> maintained by the backend.

We could move the GdkScreen structure in to the X11 private
part ... I don't really see much of a difference though.
 
> gdk_event_* ()
> Removing the display parameter from the gdk_event_* () function
> again and determining it from the window given in _GdkEventAny
> would allow for multple event queues but did not enforce
> them. [They appear unnecessary on win32 even if it would support
> multi-head. And they are obviously unnecessary for any gdk port
> which is bound to single-head through real backend 'limitations'
> (linux-fb, directfb ?).]

The hierarchy we have here is:

 * GdkDisplay ... a set of monitors on one system with an attached 
   keyboard and mouse.

 * GdkScreen - a separate virtual area of one or more monitors,
   with it's own set of colormaps and visuals.

 * gdk_screen_get_n_monitors() [etc]... find out how many monitors
   a screen is made

To my knowledge, win32 can "only" do multiple monitors, so I
don't think there is ever going to be multiple screens or
multiple displays for win32.

But I do think that it  makes sense that if you have a separate
display ... a separate keyboard and mouse ... then you have a
separate event queue.

In the case of a port supporting only a single GdkDisplay, they
can just ignore the GdkDisplay * parameters to 
gdk_display_put_event() and so forth, and use an event queue.
 
> If we could agree on single-head being the common case (for which
> to optimize) and multi-head being advanced where some extra
> code doesn't matter that much, further improvements to the
> backend independent code are possible, e.g. by allowing
> display and screen to be NULL in the api and maybe totally 
> eliminate the need to have GdkScreenSingle and 
> GdkDisplaySingle classes ...

I'm not sure what you mean by 'optimize' here. 
 
 - Optimize work for backend authors. As I said above, I think
   the most important thing is to optimize on-going maintainence,
   rather than to optimize the amount of work that we have to
   do right now.

 - Optimize efficiency? I don't see any significant efficiency
   gains that are possible by prioritizing single head.

 - Optimize for app authors? None of the non-multihead API has
   been removed, so it's possible to write non-multihead-aware
   apps and widget just as before.

   I've tried the allow NULL to mean the default before in various
   places and never been very happy with the result ... it 
   gives you an odd looking API and obscures what is going
   on for the user. Plus, it doesn't work in languages where
   methods are really methods.

Single case is a special case of multihead, if we try to organize the
code the other way around, it will be more complicated and 
messier ... a similar problem to having GtkCTree derive from
GtkCList.
 
> What do you think ?
> And if you think all the above doenn't make much sense: Is
> the patch in its current form ok to commit ?

I'd really like to see something more like what I outlined
in my mail... move the non-multihead variants into the common 
code and only duplicate the multihead variants. 
(With non-multihead backends ignoring the screen/display 
arguments.)

Regards,
                                        Owen