Re: Native scrollbars? [was: visible-bell patch for Mac OS X]

[David De La Harpe Golden <david@harpegolden.net>]

Stephen J. Turnbull wrote:
> David De La Harpe Golden writes:
> 
>  > Emacs could make the scrollbars native and this would make sure
>  > they weren't overdrawn
> 

[Just to be clear, I was quoting the gtk page, gtk+ guys wrote the above 
not me ]

> I suspect that going to native scrollbars would annoy a lot of users.
>

I'm not clear that's what the gtk+ guys mean in context by "native", 
however.  That wouldn't make sense in context, because there'd be no 
gtk+ drawn scrollbars for emacs to stomp on?

GNU Emacs indeed has a compile-time choice of "toolkit" (native as you 
[Stephen T.] mean it) scrollbars, or the emacs-internal ones.  The 
toolkit ones are significantly disliked, yes, however I think they're 
quite widely used, perhaps unlike the xemacs case.

So I think the gtk+/emacs bug may show up (I don't actually see it on my 
system, but my gtk+ might be too old)  with the _toolkit_ scrollbars 
from the emacs perspective, since emacs thinks they're a child X11 
window and thinks it's okay to clear the parent window, which perhaps
eats the gtk+ drawn scrollbar which isn't in a separate X11 child window 
anymore in recent gtk.

So I think gtk+ guys mean there's a way for emacs to request
gtk to continue to use "native" (real X11 child) windows at the gtk/gdk 
level:

Well, there is a way to do it app-globally- set env var GDK_NATIVE_WINDOWS=1
http://blogs.gurulabs.com/dax/2009/10/what-gdk-native.html

I'm not familiar enough with gtk to know if it's possible for emacs
to ask for only the gtk+ toolkit scrollbars to be "native" in the sense 
gtk+ guys seem to mean it, at least based on my current potentially 
incorrect understanding as above.