[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Resize and Rotate extension / kcontrol module; new KTimerDialog class
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-24 5:43:15
[Download RAW message or body]

On Wed, 23 Jan 2002, Dirk Mueller wrote:
>On Don, 24 Jan 2002, Hamish Rodda wrote:
>> device that rotates it will actually be useful :)  Kwin needs some work to
>> detect these events and appropriately resize/relocate apps, especially
>> kicker and kdesktop, as you can see from the screenshots.
>
>Yes, interesting. I was actually working on the reverse of it - make Qt
>listen to resize/rotation changes (fixing QDesktopWidget). The problem was
>that it won't go into Qt before 3.1. I managed to get kdesktop to adjust to
>screen rotations, but that was it. I still have the code somewhere.

Sounds good. Waiting for Qt 3.1 is a bit of a non-issue, unless there are 
people already using TinyX in production that we want to support; plus, won't 
Qt 3.1 be out by time KDE 3.1 comes out? The real benefits will come once the 
core xfree86 server supports the extension and a large portion of the users 
can utilise it. I would be interested in this code if you could dig it up for 
me.

>We could duplicate such a class in a KDE lib, but then all apps need to be
>changed back from QDesktopWidget to a KDesktopWidget.
>
>But thats not too bad as only kdesktop, kicker and kwin currently have to
>really react to the events.

hmm - lxr.kde.org couldn't produce any usage of QDesktopWidget for me...? This 
reminds me - I was wondering if maybe the resize and rotate functionality 
should be moved to kwin and accessed through eg. DCOP calls. That way kwin 
wouldn't even have to listen for the events, just resize and move around the 
windows.

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 take 
care of this at the moment (I'm using the core server atm. so I can't check)?

>Looking at your kcontrol module.. hmm. Do you notice that you hardcoded a
>lot into it ? like the display (":0.0") ?

Yes, I was impatient to see it working :) That's not a problem, we either use 
the DISPLAY environment variable, or get the needed connections from Qt (I 
saw how to access them once, can't locate them now).

In kcontrol, is there any way for me to replace the error message I'm seeing 
where libXrandr.so is not available (I have two X servers installed) to a 
more friendly error message, just for this module? Perhaps an onLoadError 
could be added to the desktop file and kcontrol extended appropriately? 
Although, it makes sense that the module wouldn't get compiled if you don't 
have the library, so it's probably just me who would see this error.

>Also, I thought the rotation events might be triggered by something else
>already (i.e. when you rotate your screen ?). so duplicating it in kcontrol
>is maybe not the right thing. Or do you always have to do it manually ?

I've no doubt that there is some mechanism for this, but as to how to detect 
it, I've no idea. Quite possibly it is an X video driver issue that the randr 
protocol should detect and send an event for that we can listen to. There are 
also situations where you want to be able to do this without affecting the 
screen, such as reading documents by placing a laptop or projector on its 
side.

>Another unsolved part for me was how it interfers with Xinerama and
>multihead.
>
>Does anybody know ?

The protocol is specified relative to the root window of each screen, so 
theoretically there are no problems in achieving the required configuration. 
Getting KDE to play nice might be a bit harder.  For the moment however, I 
would think that this situation would only be occurring at eg. Pixar where 
they can afford such equipment :)

I will bring up a few of these issues with Keith Packard and Jim Gettys, the 
authors...

Hamish
[prev in list] [next in list] [prev in thread] [next in thread]