[Appeal] Translucency effect

Hans Oischinger hans.oischinger at h3c.de
Thu Apr 14 13:48:31 CEST 2005


> 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.
Yes, that makes sense.

> 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" =)
Configuring this transparency stuff has some intersections with KControl's 
"Window Beahaviour / Translucency" module which configures kompmgr.
It also poses the question whether the smooth fadein/fadeout setting specified 
there should also apply for the taskbar effect or if it should be configured 
at two places or if it should be configured at all.
Very much of a usability question. 

My straightforward approach would be not to introduce another configure option 
and just use the kompmgr settings.

> ok, a couple of comments. first, all new code in kicker needs to following
> the style in kdebase/kicker/HACKING ...
OK I'll look into it.

> btw, giving a QTimer a parent means you don't have to delete it in its
> owner's dtor manually.
right.

> 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)
Right. currently it sets the opacity of all windows every x ms which is of 
course insane. I'll use the corresponding events for it.

> 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?
they are cheap but as I already said insane :)

> 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!  =)
Great. I'll provide a proper patch, soon.

> btw, i'd also love to get the pager to using COMPOSITE to show true
> previews as well.. but that's another thing....
That would be really cool but will pose a problem imo as COMPOSITE only works 
for windows that are "onscreen". Means: windows that are on the current 
desktop and not minimized. Other windows are not drawn into backbuffers. that 
also counts for other desktops.
That is mostly for memory reasons.

The Metacity guys (I think) have worked around it by implementing virtual 
desktops differently so that they are not really virtual desks to the X 
Server.
There may be other ways to do this that I'm not aware of. Maybe Thomas 
Luebking or Zack can bring some expertise here.

Greets, Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20050414/e5ce3195/attachment.pgp


More information about the Appeal mailing list