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

List:       kde-core-devel
Subject:    kdesky (was: Re: Changes to DialogBase and KAboutDialog)
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-07-12 10:02:44
[Download RAW message or body]

On Sun, 11 Jul 1999, Dirk A. Mueller wrote:

> Mirko Sucker <mirko.sucker@unibw-hamburg.de> wrote:
> 
> > ° the root window manager does not use the root window. It appears as 
> > a window managed by kwm. I have seen this behaviour in Kaiserslautern,
> > but thought it was fixed there?
> 
> It can't be fixed at the moment...

Making kdesktop (including the kbgndwm contents) a full-screen window
without kwm-borders and the correct focus stuff is easy (I did that some
time ago). In fact it looks and behaves exactly like a root-window
desktop, but since it doesn't really paint on the root-window any apps which 
paint on the desktop are non-functional. So you can have a fully-working
kdesktop with nice background, but apps like qt/example/desktop don't work
(obviously) .

So this is no real solution IMHO.

I think the real problem is the fact that KIconContainer is a QScrollView.
From what I know (and tested) it is not possible to make the QScrollView
(and the viewport, or anything else) be a child-widget of 
QApplication::desktop() . 

So the only way I see is to extend KIconContainer in such a way that it
it can paint it's contents to a specified widget.

Konqy then needs a KIconContainer in a QScrollView, so KonqHTMLView might
inherit QScrollView, specify viewPort() as widget to the KIconContainer
(and also re-implement drawContentsOffset and call KIconContainer to paint
in there, or?) .

KDesky might simply specify QApplication::desktop() as widget and I guess
it has to deal with the WPaintDesktop widget flag in some way then.

Oh, and we have be careful with the background stuff of KIconContainer I
think.

Opinions? Did I miss/forget something?

Greetings,
 Simon

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