Re: [Gtk-osx-users] GTK-OSX not clipping between non-toplevel sibling widgets

[John Ralls <jralls ceridwen us>]

On Jul 8, 2009, at 7:02 PM, Ken Cheetham wrote:

>
> I said:
>
>    Hello -- We have a cross-platform windowing system written in lisp,
>    which on the Linux platform is built on top of GTK, where it works
>    fine.  Now I'm trying to bring it up on GTK-OSX, and there's a  
> basic
>    problem.  It comes up and runs, but from what I'm seeing on the
>    screen, it appears that it's not doing basic clipping between
>    non-top-level windows (GTK widgets), and so a window often gets  
> drawn
>    over sibling or cousin windows that are in front of it.
>    ...
>
> John Ralls said:
>
>  Sorry, I haven't any idea -- I don't even understand what you mean by
>  "clipping".  You'll have to try the GTK list
>  (http://mail.gnome.org/mailman/listinfo/gtk-list ).
>
> The problem is specific to GTK-OSX (since our code works fine on GTK  
> on
> X), so my question doesn't seem suitable for the general GTK list.   
> This
> is a question for whoever ported GTK at a low level from the X window
> system to Quartz for the Mac.  Is this the right list for that?

No.  As I said before, GTK-OSX is a build system with some integration  
bits around the edges. The Quartz implementation really is part of GTK 
+ itself: Take a  look at http://git.gnome.org/cgit/gtk+/tree/gdk/ 
quartz. See? It's part of GTK+. You'll have to go talk to the GTK+  
team to resolve it. I don't know how much help you'll get there, as  
Richard Hult, the fellow who did the interface code, has withdrawn  
from working on GTK+. There are some of his former Imendio colleagues  
still there, though, so you might get lucky.

>
> By clipping I mean the general technique where a windowing system
> prevents content from being drawn outside the window that it's being
> drawn in, or where other windows are in front of the window that's  
> being
> drawn.  GTK-OSX does appear to be successfully avoiding drawing the
> contents of a widget over that widget's child widgets that are in  
> front
> of it, but is not avoiding drawing content over sibling or cousin
> widgets that are in front of it.
>
> GTK prefers a "packing" model where it fits sibling widgets
> side-by-side, and so sibling widgets typically do not overlap each  
> other
> in a GTK app.  Our windowing system that we ported to GTK several  
> years
> ago, on the other hand, was designed long ago on a different model  
> where
> an application places windows explicitly at arbitrary positions and  
> with
> arbitrary overlap between siblings.  So we use the GtkFixed class for
> our generic windows.  We also call gtk_fixed_set_has_window on each  
> one,
> passing TRUE, which causes each GtkFixed widget to use a real X  
> window,
> and I assume that it's the underlying X window system that's doing the
> clipping between the sibling X windows.
>
> So my guess is that GTK-OSX (GTK on Quartz) is not doing something
> similar to achieve clipping between sibling widgets.  Maybe
> gtk_fixed_set_has_window isn't creating a Quartz window for the  
> GtkFixed
> widget, or maybe non-top-level Quartz windows don't automatically do
> clipping between siblings.  But I don't know Quartz at all, and so I
> don't have a good guess about that.  I didn't have much success  
> googling
> for that info.

Ah. Well, at least I now understand the problem (I think...). But I  
don't know the GTK code at that level (actually, I suspect  that it  
will be in GDK, the abstraction layer between GTK and the underlying  
windowing system), and I don't know that anyone outside of Apple knows  
the code at that level in Quartz, since it sounds like something that  
API users shouldn't have to worry about.

I suggest, as a first step, noodling around in the gdk/quartz code and  
see if gtk_fixed is even supported.

Regards & good luck,
John Ralls