[Appeal] Translucency effect

Aaron J. Seigo aseigo at kde.org
Wed Apr 13 19:10:22 CEST 2005


On Wednesday 13 April 2005 05:11, Hans Oischinger wrote:
> > ah, ok.. cool... what's the delay on hover? i suppose i can see that when
> > i see your patch =)
>
> delay between moving the mouse over the taskbarbutton and starting the
> translucency effect.

i was looking for the number =) and that number is 300ms. the mouse over 
effects in kicker are 250ms.

> > i'd like
> > to have some "rules" that we can follow so things are consistent. e.g.
> > when to use transparency, at what levels and what those levels mean.
>
> Finding rules for stuff like this can  be a rather hard task as it depends

well, not pariticularly. in this case i case see the need immediately for two 
rules:

time between stopping the mouse over an object and an effect occuring. this 
should be the same between the KickerTip mouse over effects as well as this. 
in fact, this should probably be cannonized in KickerSettings and used 
everywhere there are such mouse hovering effects.

the other rule would be the opacity level, such that "15% (or whatever) is the 
level used to show that a window is not currently of interest to us" =)

> course be done. I only wanted to present the idea with this.

yes, i understand =)

> > and we do need to completely redo the transparency in kicker. completely.
> > rip out the old crap and replace it with proper COMPOSITE support, so
> > that the background of kicker is translucent, but things like icons
> > remain opaque.
>
> Do you think we should do this for kde 3.5?

no, for 4.0

>
> > i'll be looking for the patch =)
>
> You'll find it attached.

ok, a couple of comments. first, all new code in kicker needs to following the 
style in kdebase/kicker/HACKING ...

btw, giving a QTimer a parent means you don't have to delete it in its owner's 
dtor manually. for the unexposite you probably don't need a continuously 
firing timer either, just track mouse exit events. in fact, i don't think 
this will appear to work properly to the user when there are "empty spots" on 
the kicker and the mouse is put to rest over those empty spots (this happens 
when the number of TaskContainers % number of rows > 0)

there also seems to be a lot of redundancy here, like per-TaskContainer 
QTimers when really only one is needed per taskbar. the timer gets restarted 
with each mouse move that isn't a drag, even if the task is already opaqued. 
the multiple calls to KWin::setTranslucent seem a bit heavy handed as well, 
but maybe those are cheap?

anyways, the draft shows the basic concept.. it just needs to be cleaned up 
and finished a bit; i think it's a pretty cool feature and a good use of 
opacity!  =)

btw, i'd also love to get the pager to using COMPOSITE to show true previews 
as well.. but that's another thing....

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20050413/ae5bc2b1/attachment.pgp


More information about the Appeal mailing list