From kde-core-devel Thu Jan 24 15:55:43 2002 From: Hamish Rodda Date: Thu, 24 Jan 2002 15:55:43 +0000 To: kde-core-devel Subject: Re: Resize and Rotate extension / kcontrol module; new KTimerDialog class X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101188907922236 An update... >Another TODO for this to all work properly is having toolkits recognise = the >screen size change so that menus are still placed correctly. Does Qt tak= e >care of this at the moment (I'm using the core server atm. so I can't > check)? (answering myself :) Yep, it does this fine... However, I am having anoth= er=20 problem with Qt: Xft fonts are rendered too small and with size decreasin= g=20 proportional to decreasing screen resolution, once the screen is resized. Keith Packard says: "Are you smashing DisplayHeight and DisplayHeightMM in the X display=20 structure? Xlib doesn't do that on it's own as we're not sure it's a goo= d=20 idea for all applications (yet). Just do: =20 DisplayHeight(dpy,screen) =3D (new display height) =20 and things may work a bit better." If any Qt gurus know what's going on.... >>Also, I thought the rotation events might be triggered by something els= e >>already (i.e. when you rotate your screen ?). so duplicating it in kcon= trol >>is maybe not the right thing. Or do you always have to do it manually ? An addition will be made to the RandR protocol to send an event from the=20 server advising of the change... it will be up to us to make the change /= =20 prompt the user, etc. >>Another unsolved part for me was how it interfers with Xinerama and >>multihead. >> >>Does anybody know ? > quoting Keith: "Yes, there are issues as RandR doesn't have a separation between the roo= t window and the screen number. It may be relatively easy to add the scre= en=20 number in the relevant places and have things "just work"." As for the ETA of the extension in the core server, the resize part is a=20 possibility for XFree86 4.3, due sometime this summer. The rotate and dep= th=20 parts will take longer. Hamish =20