[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 18:28:10
[Download RAW message or body]



On Mon, 22 Feb 1999, Roberto Alsina wrote:

> On Mon, 22 Feb 1999, Timothy Whitfield wrote:
> 
> > 
> > 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.
> 
> The problem is that it's not really transparency (like glass) we are 
> looking for, but transparency (like glass) with letters on it :-)

Why do we need letters? They don't look cool. ;-)

Ok we are about to find out exactly how much I don't know about X.

<IMHO>
It seems as if we are saying that X uses the reverse-painters algorythm as
far as sending rect updates, only in this case we want to use the painters
algorythm.  So in order to do this we have to use a non-transparent widget
like currently implemented in order for kwmbgnd not to paint over our
letters.

But is there any reason why we can't force kwmbknd to update before we do,
by sending a rect update to applications behind the window
with the transparency and then put the letters on?

Note: I did not volunteer as I am not even sure whether what I am saying
is possible, or just shows my ignorance about X message processing.
 </IMHO>

> 
> If you tried to adapt QWidget's transparency support to it, you would 
> have to mask all the characters. I am not sure that's practical.
> 
> > Hint. Hint. I would love to see transparency and/or background selection
> > in kvt/konsole.
> 
> konsole has background support! Try the "circuit" profile.
> I still haven't found where you configure that, but I'm looking ;-)
> 
> > 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
> > > 
> > 
> > 
> 
>  ("\''/").__..-''"`-. .         Roberto Alsina
>  `9_ 9  )   `-. (    ).`-._.`)  ralsina@unl.edu.ar
>  (_Y_.)' ._   ) `._`.  " -.-'   Centro de Telematica
>   _..`-'_..-_/ /-'_.'           Universidad Nacional del Litoral
> (l)-'' ((i).' ((!.'             Santa Fe - Argentina
>                                 KDE Developer (MFCH)
> Life isn't short. It's just that death is longer.
> 

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