Re: gedit runtime error
Re: gedit runtime error
- Subject: Re: gedit runtime error
- From: Jeremy Huddleston <email@hidden>
- Date: Tue, 18 Nov 2008 22:38:15 -0800
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:
On 2008 Nov 18, at 14:18, William Davis wrote:
Ive just installed gedit using macports and get this runtime error:
macintosh:~ frstan$ gedit &
[1] 31566
macintosh:~ frstan$ Xlib: extension "RANDR" missing on display "/
tmp/launch-AEpBLV/:0".
gtk+ always attempts to use the XRandR extension. Jeremy thinks
it's not useful;I think it'd be a good way to let users select
whether the dock and/or menu bar are useful,
How exactly does "select whether the dock and/or menu bar are
useful" fall under Resize and Rotate?
Worded poorly, sorry. Someone asked some time back about being able
to specify if the menubar and/or dock were part of the area
available to X11; XRandR lets you change it dynamically.
Well, TBH, we don't need XRandR for that (the menu bar area is not
included, now for instance), and that's not really what XRandR is
for. XRandR is for Resize and Rotation...
"""
The Resize and Rotate extension (RandR) is a very small set of client
and server extensions designed to allow clients to modify the size,
reflection, rotation and refresh rate of an X screen. RandR also has
provisions for informing clients when screens have been reconfigured.
"""
This stuff is actually handled natively on OSX through the Display
Properties in System Preferences, so there's no need for the
extension. We could implement the extension and let it be a frontend
to the Display Preferences, but I don't see any practical usage for
that.
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:
if(!_xrandr_available) {
XWindowAttributes rattr;
XGetWindowAttributes(dpy, DefaultRootWindow(dpy), &rattr);
dim.w = rattr.width;
dim.h = rattr.height;
}
doSometingWithDim(dim);
XRandR isn't about making the server smarter, it's about making
*clients* smarter.
The main reason users care about XRandR is to set the screen
resolution, refresh rate, etc... I'm not sure it's worth the effort to
implement that frontend to Display Properties in X11. Show me a
counter example, and I'll gladly bump the priority of RandR in the
server...
--Jeremy
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden