D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  @abetts This ticket was closed and replaced with a newer patch. Please read 
up on a discussion before commenting! :)

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Andres Betts]

abetts added a comment.


  Could a different approach work here? No change on hover, but just on click? 
The user controls the entire action.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  Now superseded by D13192 .

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  @ngraham You ok with abandoning this? Then I'll write an alternate patch this 
week that makes tab switching fast for moves from the panel button or 
horizontally and more strongly delayed for diagonal moves into the content area.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Henrik Fehlauer]

rkflx added a comment.


  > If it's a problem, then we could hold off on this and I spend some minutes 
moving Kicker's triangle filter to Kickoff.
  
  I suggested exactly that in my original comment. As you seem to know that 
particular code, I'm sure Nate would appreciate any help.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  If it's a problem, then we could hold off on this and I spend some minutes 
moving Kicker's triangle filter to Kickoff. I suspect David's code may be 
better and more general, but then he isn't busied up with something this small.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Henrik Fehlauer]

rkflx added a comment.


  In D11848#269495 , @hein wrote:
  
  > Do you think tab to entry move is a problem in practice? Don't users just 
move vertically from the tab?
  
  
  In my experience (observing users working on tasks, and evaluating 
eyetracking studies) users tend to move towards something they can see, with 
the intention to click on it later. In the first part of my video the mouse 
(following the movement of the eyes) moves from the tab to the arrow, and for 
the second part of the video the mouse moves from the tab to the entry 
consisting of text and icon.
  
  In particular I'm concerned about the second case.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  > Not sure I understand? My video is about moving from the tab bar to the 
entries inside the tab, not about moving between tabs.
  
  This explains our misunderstanding. The original reason Kickoff had the delay 
- as also noted in the earlier discussion - is for the move from the panel 
button to the tab. I didn't realize we had switched topics.
  
  Do you think tab to entry move is a problem in practice? Don't users just 
move vertically from the tab?

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  For the record, here's the triangle filter in Kicker in action:
  
  https://youtu.be/d20RYgNEDcs
  
  You can see it both switch immediately on the horizontal move, and not switch 
as the cursor goes over 4-5 adjacent categories diagonally on the way to K3b.
  
  The values should be roughly similar to QMenu, although the behavior is 
different (and imho a little bit nicer): In QMenu only the switching of the 
subdialog is delayed, but the hover effect on the items happens anyway, so it's 
visually quite busy. You see the blue hover highlight move under your cursor 
without the dialog changing. The implementation in Kicker simply discards the 
diagonal events during the move, so not even the hover effect happens (but when 
the cursor stops during a diagonal move, it will still switch).

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Henrik Fehlauer]

rkflx added a comment.


  That's why I mentioned "or am I wrong". At least when comparing Kicker and 
Kate, it's pretty clear that there's a difference in behaviour, leading to my 
conclusion. My comment was based on testing what users see, I'm sorry if you 
misunderstood that as critique on your implementation.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  As mentioned in this discussion, both Kicker and Dashboard have triangle 
filters. Please make sure you review discussions in full before commenting; it 
doesn't help if comments are made based on wrong assumptions or misinformation. 
Especially with such a panicky and guilty attitude. It's really frustrating to 
have put work into making that triangle filter work nice, and then someone with 
no clue go "it's all bad and users will drop Plasma". Have more respect for 
your fellow devs.
  
  The use case for a triangle filter in Kicker and Kickoff is also very 
different. In Kicker it's really needed because if you accidentally graze the 
wrong category you likely wind up in the wrong subdialog. In Kickoff it's much 
more likely that the accidental grazing just makes tab switching happen earlier 
but then the user hits the right tab after and it moves to that.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Henrik Fehlauer]

rkflx added a comment.


  @ngraham Are you sure the Kicker menu has a triangle filter at all? I don't 
think it has, making your video a bad example (or am I wrong?). Try comparing 
with a QWidget based menu, which for me is much easier to operate than Kicker 
or Kickoff with your patch.
  
  And BTW, I did not deliberately move the mouse slowly. It's a regular speed, 
and users of trackpoints would move even slower.
  
  I strongly disagree with your notion that "simple by default" means having no 
filter (or filter-like workaround) for Kickoff. It's exactly the type of user 
who has trouble in accurate pointing and who is slow who needs the filter most. 
It's not a feature only for experts. As Kicker does not have the filter, 
Kickoff is our only option left for those users. If you take that away, they 
may just drop Plasma.
  
  How about we meet in the middle, and don't hardcode it: 
https://lxr.kde.org/search?_filestring=&_string=SubMenuPopupDelay

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Henrik, if you move your cursor that slowly, even a triangle menu filter 
won't help you. Try such a slow speed with any other sub-menu paradigm. If I 
move my cursor as slowly as you depict in your video in Kicker or a sub-menu in 
one of our apps, I get the same effect.
  
  F5871730: Kicker.webm 
  
  Triangle menu filters are actually accelerators for experts. For decades, 
I've observed regular users move their cursors in straight horizontal and 
vertical lines to access sub-menus. They intuitively grasp that they shouldn't 
pass the cursor over another content area. It's only experts who want to move 
in quick diagonal lines and whose high-efficiency use cases are enhanced by 
triangle filters. And it's important to support experts! But we mustn't forget 
"Simple by default".
  
  FWIW, I'm all for the triangle menu filter, myself. Sadly I lack the 
technical ability to do it; that kind of back-end algorithmic programming is 
quite far from my area of expertise. I was kind of hoping that @davidedmindson 
would revive his old code for it. But for the above-mentioned reasons, I don't 
think this is a prerequisite.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Henrik Fehlauer]

rkflx added a comment.


  > This patch reduces it to 50ms, which is low enough to make switching feel 
instantaneous, but still high enough to prevent accidental tab switching when 
moving the mouse diagonally and clipping another button.
  
  I'm not sure if the patch is working right for me? Contrary to your video, I 
get this (and I'm sure the pointer speed of regular users is much slower):
  
  F5871449: kickoff-delay.webm 
  
  In D11848#242794 , @abetts wrote:
  
  > I am all for reducing the time but maybe keep some lag to tackle the points 
already made in the ticket
  
  
  @abetts Can you confirm you are okay with how it works in the video above?
  
  In D11848#238485 , @hein wrote:
  
  > Nate, you misunderstood my original comment. The problem isn't going from 
tabs to content, it's going from the panel button to a tab. That's why the 
delay was likely added (I've never worked much on Kickoff vs. the other menus 
we ship, but I have vague memories).
  
  
  @hein I'm a bit surprised that you are accepting the patch then? FWIW, I 
think the triangle filter should be implemented before this patch, and not the 
other way round. Optimizing the delay is good, but introducing the usability 
bug is worse IMO.

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, abetts, hein
Cc: rkflx, rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Andres Betts]

abetts added a comment.


  +1

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts, hein
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Thanks, Eike! @davidedmundson, are you okay with this now?

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts, hein
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Friendly ping!

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  In D11848#242794 , @abetts wrote:
  
  > I am all for reducing the time but maybe keep some lag to tackle the points 
already made in the ticket
  
  
  Yes, this patch reduces it from 250ms to 50ms.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Andres Betts]

abetts added a comment.


  I am all for reducing the time but maybe keep some lag to tackle the points 
already made in the ticket

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Friendly ping!

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  In D11848#238485 , @hein wrote:
  
  > Nate, you misunderstood my original comment. The problem isn't going from 
tabs to content, it's going from the panel button to a tab. That's why the 
delay was likely added (I've never worked much on Kickoff vs. the other menus 
we ship, but I have vague memories).
  
  
  Hmm, I'm not sure what the problem is for this case. Why is it a bad thing if 
the view changes when your mouse moves across the buttons after you open the 
menu? Isn't that the whole point of making the view change on hover?

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  Nate, you misunderstood my original comment. The problem isn't going from 
tabs to content, it's going from the panel button to a tab. That's why the 
delay was likely added (I've never worked much on Kickoff vs. the other menus 
we ship, but I have vague memories).

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  In D11848#238363 , @davidedmundson 
wrote:
  
  > That second diagram literally has that arrow crossing through the History 
tab...
  
  
  Yes, I drew the arrow that way deliberately to illustrate that it still works 
okay for the absolute worst case scenario:
  
  - Right-most tab is active
  - User decides to move the mouse diagonally to position it over the text of 
an item low down in the list, in the process crossing over the History tab
  
  Virtually all other use cases will not have the above constraints and the 
user can be expected to move the cursor straight up.
  
  I just increased the timer to 50ms, and here's a video showing that there 
isn't a problem:
  
  F5781330: Works fine-2018-04-01_17.07.40.webm 

  
  That said, I agree that a very lenient triangle filter might work better 
here, so I'm willing to give it a shot.
  
  In D11848#238363 , @davidedmundson 
wrote:
  
  > I did once write a generic QML implementation of a triangle menu filter, 
implementing something like 
http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown 
  >  https://phabricator.kde.org/P183
  >
  > The reason I didn't push forward with it was because I found afterwards it 
didn't solve the bug I was trying to solve, moving the mouse to task manager 
tooltips, where my mouse is moving outside an area we control. Would cover the 
kicker/kickoff cases fine. I can revisit that if wanted.
  
  
  That sounds like a sane, humane, and re-usable solution!

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham updated this revision to Diff 31134.
ngraham added a comment.


  Increase threshold to 50ms until I/we can implement a triangle filter thingy

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11848?vs=31068=31134

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

AFFECTED FILES
  applets/kickoff/package/contents/ui/FullRepresentation.qml

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added a comment.
This revision now requires changes to proceed.


  That second diagram literally has that arrow crossing through the History 
tab...
  
  I'm not approving something that replaces one bug with a different known bug. 
Even if it will affect fewer people.
  
  Especially if kicker has some code we can copy paste.
  
  I did once write a generic QML implementation of a triangle menu filter, 
implementing something like 
http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown 
  https://phabricator.kde.org/P183
  
  The reason I didn't push forward with it was because I found afterwards it 
didn't solve the bug I was trying to solve, moving the mouse to task manager 
tooltips, where my mouse is moving outside an area we control. Would cover the 
kicker/kickoff cases fine. I can revisit that if wanted.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: rikmills, hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  I agree with @hein that the reason is probably " a poor man's implementation 
of lazy menus".
  
  The thing is, it's an inappropriate application of the feature and isn't 
necessary here. Allow me to put on my Usability Consultant hat and me 
illustrate why:
  
  Lazy menus are critically important for traditional horizontal menus that 
have cascading sub-menus. With this pattern, when you move your cursor 
diagonally to quickly to reach a sub-menu item, it unavoidably has to pass over 
several other top-level menu items to reach the desired sub-menu item, as 
illustrated with Kicker and an arrow showing the corsor's path to reach a 
sub-menu item:
  
  F5780979: Kicker.png 
  
  As you can see, without some logic to handle this case, another top-level 
item would become activated the moment the cursor leaves the current menu area.
  
  But with Kickoff, the user interface is different. Let's look at the same 
basic task and with an arrow describing the worst-case-scenario cursor movement:
  
  F5780980: Kickoff.png 
  
  Kickoff does not implement the pattern of horizontal menus with cascading 
sub-menus. Instead, it has a tabbed UI that renders the "lazy menus" feature 
inapplicable for the following reasons:
  
  - The top-level items (the tabs) are large square buttons, not small 
horizontal rectangles; even with a diagonal movement, there is a good chance 
the cursor never leaved the area of the current tab
  - You can always move your mouse vertically to reach the desired item within 
a tab, because the hover area for entries within tabs take up the whole 
horizontal space
  - Even in the worst-case scenario where a user is on a far right tab, doesn't 
realize that the whole horizontal area is a click target, and moves their 
cursor slowly and diagonally to reach a left-aligned item that's near the 
bottom of the list , even then the cursor only just barely clips the area for 
another tab and the cursor will only be there for a millisecond or two
  
  In conclusion, the "lazy menus" pattern only applies to traditional 
horizontal menus with cascading sub-menus and is inapplicable to Kickoff. 
Therefore, the long delay that attempts to provide this unneeded feature is 
itself unneeded.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  And FWIW, the main reason there's a delay right now is probably as a poor 
man's implementation of lazy menus. If you're hitting the menu button in the 
lower-left of the screen and then move the pointer to, say, the third or forth 
tab, you're likely to graze adjacent tabs in the process. The delay is there to 
avoid Kickoff switching in that event, to make it feel calmer and more elegant.
  
  The Kicker menu e.g. contains (albeit smarter) code to handle a similar 
problem. It interprets purely vertical and diagonal mouse pointer moves 
differently, so that if you move vertically in the menu it will switch 
categories and open subdialogs immediately, but if you move diagonally into a 
subdialog there's some delay to avoid grazing adjacent categories switching the 
subdialog to that category.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Eike Hein]

hein added a comment.


  It's also worth noting that the way the delay and the animation are currently 
implemented makes it pretty ugly even in the case of an accidental overshoot. 
If you do A->B->A in quick succession, the move from B back to A doesn't 
commence until the animation moving from A to B has finished playing. This can 
make it feel like Kickoff is running behind and struggling to keep up.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: hein, cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Christoph Feck]

cfeck added a comment.


  I didn't say it is a problem. I just asked if we know it isn't a problem for 
them. There must have been a reason the delay was added in the first place.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Why is it a problem if the tabs change when you overshoot the target? Not 
doing this makes Kickoff feel slow and ponderous.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Christoph Feck]

cfeck added a comment.


  If they accidentally shoot too far, and want to move back without the tabs 
changing in between.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham added a comment.


  Since the tabs are immediately below the content area that they affect, I 
have trouble understanding what possible usability concern would come into play 
here.
  
  If someone moves their cursor very slowly across tabs and makes the view 
change multiple times, then... there's no problem at all, just a feeling of 
lightness and responsiveness.
  
  Can you explain how a user could "need" the delay?

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Christoph Feck]

cfeck added a comment.


  Do we have studies from users that did not complain, because they need the 
delay? I am thinking about touchpad or trackball users, that cannot move as 
fast a regular mouse.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D11848

To: ngraham, #plasma, davidedmundson, abetts
Cc: cfeck, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D11848: [Kickoff] Reduce hover delay before switching tabs

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: Plasma, davidedmundson, abetts.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  the 250ms delay before switching tabs on hover makes Kickoff feel slow, and 
I've actually seen users mistake this for a performance problem (!)
  
  This patch reduces it to 15ms, which is low enough to make switching feel 
instantaneous, but high enough to prevent accidental tab switching when mozing 
the mouse quickly.

TEST PLAN
  Use Kicker and mouse over the tabs. Rejoice that your computer no longer 
feels like it's walking through molasses!

REPOSITORY
  R119 Plasma Desktop

BRANCH
  faster-kickoff-tab-switch-on-hover (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D11848

AFFECTED FILES
  applets/kickoff/package/contents/ui/FullRepresentation.qml

To: ngraham, #plasma, davidedmundson, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart