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

List:       kde-devel
Subject:    Re: [PATCH] Transparency support and bugfixes
From:       mosfet <mosfet () jorsm ! com>
Date:       1999-02-22 19:05:13
[Download RAW message or body]

Oh, and one other thing, using this mechanism you *really* get what is behind
the window, not necessarily the desktop pixmap. For example, if your window is
on top of a KFM window you'll see KFM, not the desktop, through it.

I don't know if this is what you want or not ;-) 

On Mon, 22 Feb 1999, mosfet wrote:
>I did not follow this discussion entirely, and deleted the older emails (I'm on
>a *lot* of lists), but from what I can tell you guys want transparent windows.
>
>The best way I could find to implement this is when a widget is resized or
>moved to get the desktop QWidget via QApplication::desktop(), hide the window
>(or move it offscreen), bitBlt the rect that the window was obscuring to a
>QPixmap, reshow the window, and then repaint with the cached QPixmap. 
>
>This is similiar to what other transparent terminals do, and since the widget
>is only hidden during operations like moving or resizing it does not flicker
>too badly.
>
>I played with this a little but have encountered problems with the repaint... 
>
>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]