[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David De La Harpe Golden
Subject: Re: Native scrollbars? [was: visible-bell patch for Mac OS X]
Date: Sat, 13 Feb 2010 05:45:21 +0000
User-agent: Mozilla-Thunderbird (X11/20091109)

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]