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

List:       kde-devel
Subject:    Re: [PATCH] Transparency support and bugfixes
From:       Geert Jansen <g.t.jansen () stud ! tue ! nl>
Date:       1999-02-22 15:34:58
[Download RAW message or body]

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]