david_edmundson wrote:Fixed this morning.
https://projects.kde.org/projects/kde/w ... ef320be3b1

Qt's default is to put in a silly animation which means we developers need to manually turn it off every time.
If this comes up anywhere else please tell me.

Hi David,

Thanks for this fix. Looking at the code diffs it appears you have set the delay for removing the Highlight to 0 or you have hardcoded it as disabled (sorry I haven't read through the qml code for Plasma Next - so not sure which).

IMHO there are 2 fundamental problems with the current Plasma implementation:

• Both the Window Thumbnails and the window Highlighting animations currently have a short delay before being deactivated (~500ms I would guestimate) - this needs to be closer to 0ms. Otherwise accidental trigger means the user is either confused or annoyed (or both!) - waiting for the work they were doing (which is now obscured) to be accessible again.
• The other half of the equation is that there should be a very short delay before first activating Window Thumbnails and the window Highlighting animation. Like a hover delay. This would ideally be in the order of ~250-500ms

This is default behaviour on Windows 7 (which no doubt had millions of dollars spent on usability research) and makes it much harder to trigger either of these animations when accidently moving the mouse into/ through the Superbar Bar area.

I find these 2 issues become more significant when using a vertical KDE panel. It becomes much easier to wander the mouse cursor (accidently) too far to the left and then even the Window Thumbnail animations (I always disable the Highlighting animation) become annoying. They appear too quickly and then take ~500ms to disappear after the mouse rollover is removed.

Robert

I absolutely agree with rwalker: The fact that lots window highlights and window thumbnails get triggered while moving the cursor over a well-filled taskbar is both confusing and annoying.

david_edmundson wrote:Qt's default is to put in a silly animation which means we developers need to manually turn it off every time.
If this comes up anywhere else please tell me.

Time to fix this in Qt, then, isn't it? Adding eye-candy by default which not only serves no purpose, but is actually detrimental to the user experience is something which must not happen in a toolkit! It seems like Qt needs some serious design/usability work of its own...

I really like the 'hover over the window button in the taskbar and it gets highlighted' thing, I use it all the time to quickly 'peek' from one window to the next when I've got lots of windows open so for me it's a useful animation, not just meaningless visual fluff like wobbly windows (which I use too but I wouldn't miss them!).

I totally agree that the window highlighting is triggered way to quickly when the mouse enters the taskbar as standard and there should be no delay in stopping the highlighting effect when leaves the taskbar too. Having said that, the delay on starting the window highlight thing would have a big effect on me being able to use it to peek at hidden windows quickly so I'd like to be able to tweak that if at all possible, if i set it so that it starts the window highlighting too quickly and it looks like a flickering mess then I've only got myself to blame (not KDE) and I can try & tweak it.

One thing that could do with addressing (although a bug report might be more appropriate) is that when I've got multiple windows of an application grouped together into one button on the taskbar and I hover over it the window highlight is triggered to reduce the opacity of all windows except the one you've got the mouse pointer over but the text based pop up menu that appears above the taskbar buttons when they've been grouped together that lets you choose exactly which of those windows you're selecting gets its opacity reduced too. It's not a huge pain, just not very elegant. I think that double checking what gets reduced opacity during the window highlight animation could do with some attention!!

ken300 wrote:One thing that could do with addressing (although a bug report might be more appropriate) is that when I've got multiple windows of an application grouped together into one button on the taskbar and I hover over it the window highlight is triggered to reduce the opacity of all windows except the one you've got the mouse pointer over but the text based pop up menu that appears above the taskbar buttons when they've been grouped together that lets you choose exactly which of those windows you're selecting gets its opacity reduced too. It's not a huge pain, just not very elegant. I think that double checking what gets reduced opacity during the window highlight animation could do with some attention!!

@Ken,

I really tried to read this. I did! But now my head hurts...

Robert

The last line is the most relevant bit:

I think that double checking what gets reduced opacity during the window highlight animation could do with some attention!!

A menu that should be visible suddenly fades away!!

Still slow animations, it really feels like 100.000 lines of code are processed while hovering from one icon to the next.

The menu still and the window information pop up (which is a totally useless feature imho) when you move from one window in the panel to the next

Hi Folks,

Just a quick come back/followup to this thread...

i've been trying out Plasma Next on my Kubuntu 14.10 install today (since it's not my daily driver). Colour me impressed! The hover delay for activating Window previews for Taskbar entries is perfect! Also the fact that the previews go away quickly when you leave the area is a big improvements. Thanks to the KDE devs!

Robert