Re: gdk backend dependencies in gtk

[Owen Taylor <otaylor redhat com>]

"Matthias Clasen" <matthiasc poet de> writes:

> Before starting on completing the gdk X backend api docs,  I decided
> to take a look at why one would need to access the backend at all.
> Here is a list of all the not-gdk-backend-independent widgets (judging
> by #include "x11/gdkx.h") I found:
> 
> gtkclipboard
> gtkcolorsel
> gtkplug
> gtksocket
> gtkselection
> gtktreeview
> gtkwindow
> 
> gtkplug/gtksocket are completely X specific, not much we can do here.
> gtkcolorsel/gtktreeview/gtkwindow seem to work just fine without the gdk
> backend includes.
> gtkselection needs gdk_window_lookup
> gtkclipboard needs a way to get a current timestamp:
> gdk_x11_get_server_time/GetMessageTime
> 
> Is it ok if I remove the gdk backend includes from gtkcolorsel, gtktreeview
> and gtkwindow ?

Yes, I believe they are just leftovers and/or accidedental 
cut-and-paste.

> Furthermore, I would propose to add
> 
> GdkWindow *gdk_window_lookup (GdkNativeWindow *)

Exporting this function in the cross-toolkit headers seems reasonable
to me. (As Hans pointed out, it should be GdkNativeWindow not
GdkNativeWindow *). 

> guint gdk_get_current_timestamp (GdkWindow *)

Well, equating gdk_x11_get_server_time() with GetMessageTime() is
basically just wrong. GetMessageTime() gives you the time for the last
event retrieved from the message queue, while
gdk_x11_get_server_time() forces an event to be generated and gets the
time from that event.

I don't think an equivalent of gdk_x11_get_server_time() is possible
with the Win32 API because there is no way to look ahead in the
message queue without getting the intervening messages. (GDK could go
ahead and translate the intervening messages into GdkEvents, but that
would have some strange side effects and would best be avoided.)

It's intentional that gdk_x11_get_server_time() is not named anything
obvious because it is almost always the wrong thing to use. It's slow,
and it doesn't provide the same protection against races that using a
real timestamp from the activating event provides. It's used
for a very specific purpose (always using non-decreasing timestamps
for requesting the selection), and I think it's pretty open 
to abuse if publically exported.

GtkClipboard intentionally does _not_ have timestamps in its 
public API because getting the timestamps right is hard and 
I wanted to get it right once instead of forcing everybody to
learn how to do it.

Finally, note that the Win32 selection code completely ignores
timestamps, so from a practical point of view, rand() would work as
well as GetMessageTime().

> to the gdk frontend in order to remove the backend dependencies from
> gtkclipboard and gtkselection.

I'm not sure that aggressively trying to get rid of all backend
dependencies from these files make sense. In implementing optimum
clipboard code on, say, Windows, there is some balance between:

 - Working exactly like X
 - Interoperating with the native system clipboard.

The GdkSelection API is very low-level and trying to interoperate with
the system clipboard at that level is going to be a huge mismatch.
gtkselection.c contains all sorts of very X specific code for the X
selection protocol - splitting the data up into little chunks, sending
messages back and forth, putting data into properties.  It may be
"covered up" from direct X access some gdk_* functions, but the gdk_*
functions don't form any sort of natural API.

(If I was implementing GdkSelection nowdays, much of the X specific
handling would probably be in GDK, but when I did it the main loop
handling for timeouts, etc, was in GTK+.)

There is a on-going tension here that shows up for selections dnd,
plug socket, etc, between me:

 "The details of IPC mechanisms work in GDK are based on how the 
  native X IPC mechanisms work, and are designed for interoperability
  with other X applications not using GDK. Ports to other windowing
  systems will need different details for their IPC mechanisms"

And the people working on ports:

 "The details of how the IPC mechanisms work in GDK leak out 
  to the application API so we can't just go and use the native
  IPC mechansims on Win32. Plus, we'd have to rewrite a lot of
  code since it's all based around the X IPC mechanisms."

There is something to be said for both points of view. I think if we
do want to be a viable toolkit for applications on Windows we really
do have to make sure that clipboard and DND operations interoperate
with native apps. But I know it's hard for people to design and
propose ways to change the application APIs to make this possible when
its a big struggle just to keep ports compiling. To some extent this
may have to be a GTK+-3.0 issue.

In any case, I believe that viewing the current GDK/GTK+ split as the
split between port-independent and port-dependent code in these cases
is not right, and either we have to do a lot of code movement
(not really feasible for GTK+-2.0 at this point), or we have
to accept port-specific code in libgtk.

Regards,
                                        Owen