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

List:       kde-devel
Subject:    Re: [PATCH] Transparency support and bugfixes
From:       Roberto Alsina <ralsina () unl ! edu ! ar>
Date:       1999-02-22 16:52:50
[Download RAW message or body]

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 :-)

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]