Re: gedit runtime error
Re: gedit runtime error
- Subject: Re: gedit runtime error
- From: George Peter Staplin <email@hidden>
- Date: Wed, 19 Nov 2008 12:38:17 -0700
Quoted Brandon Allbery <email@hidden>:
On 2008 Nov 19, at 1:38, Jeremy Huddleston wrote:
On Nov 18, 2008, at 22:28, Brandon Allbery wrote:
On 2008 Nov 19, at 1:01, Jeremy Huddleston wrote:
On Nov 18, 2008, at 15:35, Brandon Allbery wrote:
not to mention adapting if the OSX monitor(s) are reconfigured
(without XRandR, X11 is incapable of handling size changes).
Uhm... that's not true. We do reconfigure correctly when
monitors are reconfigured (and have since sometime around 2.2.2 I
think).
And X clients find out about this how? That's the main reason for
XRandR: without it, the display configuration determined at
XOpenDisplay() time can't be changed (neither are there
appropriate events nor does xcb/xlib update its internal
structures).
It doesn't need to. If an app wants to know the size of the root
window, it should query it if XRandR is not available. If XRandR
is available, then it is told on change... so code should look like:
Unfortunately, last I checked that didn't update XLib's cached
information (the reason why resize didn't work before XRandR).
I think you're right. That's one of the problems that XRandR solves I
think. The DisplayWidth and DisplayHeight (plus the others for
width/height in millimeters) calls are actually macros that extract
the data from an initialized Display *, from XOpenDisplay(). So the
only way for an app to know of a root window size change (without
RandR) is to XOpenDisplay again, after closing the old, in order to
get updated cached values for the DisplayWidth and DisplayHeight, I
think.
Xlib.h:
#define DisplayWidth(dpy, scr) (ScreenOfDisplay(dpy,scr)->width)
I wonder how RandR works. I looked at the xorg/lib/libX11 git code,
and it doesn't appear to use RandR directly. I would have thought
they would implement it like the XCMISC extension is used in Xlib; so
that a sort of private event occurs that updates Xlib. Instead it
seems we select an event mask with RRSelectInput. I can see the
reasons for both ways. Lots of toolkits cache the width and height,
and even updating the Xlib Display structure wouldn't necessarily make
it so that all old clients work. Some apps might have unexpected
failures with the width and height changing between XNextEvent and
friends, so a new event type is probably the best way, as they
implemented it.
George
--
http://people.freedesktop.org/~gstaplin/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden