[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