[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: [PATCH] Transparency support and bugfixes
From: Timothy Whitfield <timothy () datasync ! com>
Date: 1999-02-22 16:47:45
[Download RAW message or body]
I may be misunderstanding here, because I have only read part of the
conversation, but are we talking about loading the desktop background from
a file? What is wrong with real transparency? It seems that we should be
able to tell the background to redraw a certain segment of itself, and if
I am not mistaken QWidget already has support for transparency.
Hint. Hint. I would love to see transparency and/or background selection
in kvt/konsole.
But I think without {true} transparency, this is not what I want on my
system.
Timothy
On Mon, 22 Feb 1999, Geert Jansen wrote:
> mark.donohoe@symbian.com wrote:
>
> > I'm not particularly keen on adding futz to the desktop. We already
> > have a ridiculous range of configuration options for backgrounds.
> > However, most of what you propose seems reasonable.
> >
> > > The thing I did is modify kbgndwm so that it exports the desktop as a .ppm
> > > file to ~/.kde/share/apps/kbgndwm/desktop_x.ppm.
> >
> > This sounds rather crude and although it may turn out to be acceptably efficient
> > I'd suggest you investigate the shared memory solution soon.
>
> I agree, shared memory is more elegant. But it also has some drawbacks:
> * If kbgndwm gets KILLed, the shared memory segments stay floating around
> forever.
> * If the user has 4 different desktops and only uses one transparent
> window on one, he will have all 4 (huge) pixmaps in memory. (but on
> the other side, if you have 10 programs using it, shared memory is more
> efficient)
> * I don't know if this is still the case but some systems (early Linux and
> (current?) FreeBSD) were very limited in the number and size of shared
> memory segments available. My Linux 2.2 seems OK though (128 segs of 32MB)
>
> The efficiency is also not that bad using files. Typically an application
> will load the pixmap once on startup and will never change it. The file
> approach puts the penalty with the programs using it, not with the system.
>
> These are just some thoughts. I will think about it some more.
>
> > Since getDTBackground returns the pixmap don't use 'get'. Further, the name is
> > rather cryptic and doesn't seem to capture what you're actually doing. I'd
> > suggest you call this function KApplication::desktopPixmap instead.
>
> Ok.
>
> > Translucency and transparency effects in KPixmap would be very
> > welcome. However, please add these independently of this desktop
> > loader.
>
> Ok, how about:
> KPixmap::mix(const QColor& color, int perc);
> KPixmap::shade(int perc);
>
> > I'm also uneasy that a general pixmap handling class should have an
> > ordinary public member which creates a specialised instance of itself.
>
> QPixmap also does this, e.g. QPixmap::load(), loadFromData(), and
> convertFromImage(). I considered it to be more like a loading function.
> Do you still think it is bad?
>
> > Is this really needed ? It seems to me that it should be
> > KApplication's job to load the pixmap and apply the effects
> > explicitly. At worst a factory function or, yeuch, subclass seems more
> > appropriate.
>
> I agree with you that it is KApplication's job to load the Pixmap but I
> think it is the user who has to apply the effects. The effect have IMO
> little to do with the application and can also be different for each window.
>
> Cheers,
> --
> Geert Jansen, email: <geertj@stack.nl>
> (future) Phylosopher and Physicist PGP key ID: 0xD2B5E7CE
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic