| Summary: | Panel Auto-Hide Duration/Delay Missing | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | David Rankin <drankinatty> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | a.samirh78, aseigo, coreyoconnor, doc.evans, echukwuogor, g0tt, kde-2011.08, pingvinzilla, sven.burmeister, thijs22nospam, tribaal, xrigou |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Adds a delay to showing and hiding autohide panels
Adds a delay to showing and hiding autohide panels. Add configurable delays ; plus other autohide changes Add configurable delays ; plus other autohide changes |
||
|
Description
David Rankin
2009-06-27 06:50:06 UTC
the timeout is currently 200ms Could one not use the "windows can cover" feature if one has an unsteady hand or lack of mouse movement control? That way it only hides after a click which is not that much work and there is no need for additianal GUI options. Unhiding stays the same. (In reply to comment #2) > Could one not use the "windows can cover" feature if one has an unsteady hand > or lack of mouse movement control? sure, one could not use this feature at all. that's not really an answer to a feature request. i would certainly say that i don't consider that i don't consider myself to have a particularly unsteady hand or lack of movement control, yet i find the default delay frustrating since upgrading from kde v3 to v4. > That way it only hides after a click which > is not that much work and there is no need for additianal GUI options. is "no need for additional GUI options" such an overriding design goal that users must suffer? from a usability perspective, "not that much more work" seems a shortsighted way to describe forcing a change in usage... I can confirm this issue in KDE 4.3.1. I have neither a steady hand nor a particularly unsteady one, but moving across an open panel is like walking on eggs to make sure that it will not hide. Please add an option to increase the delay. Thanks. I have a panel with quicklaunch plasma widget in it at the top of my screen set to auto hide. I use chromium browser to surf the web and my laptop touchpad isn't perfect. I've lost count of how many instances of amarok, firefox, kmail, kget, etc., I've had to close after an attempt to change tabs. Please this feature will really be appreciated. I second Ekeluo Chukwuogor. I use the same setup (top autohide panel a'la "quicklaunch") and find it very troublesome to work with applications like the Google Chrome (due to it's tabs residing on the very top of the window) which i definitely like. The simplest solution would be to add an option to increase the autohide/appear delay time. Created attachment 40250 [details]
Adds a delay to showing and hiding autohide panels
The delays are currently constants in panelview.h. This should, no doubt, be configurable.
Created attachment 40450 [details]
Adds a delay to showing and hiding autohide panels.
This patch implements the autohide behavior I expect. However the patch is incomplete: The LetWindowsCover functionality is currently disabled; The unhide hint is currently disabled.
Both of these were disabled only to ease focusing on just the autohide behavior.
Created attachment 40459 [details]
Add configurable delays ; plus other autohide changes
* Adds a configurable delay to showing and hiding autohide panels. The configuration variables are: delayBeforeHide, delayBeforeShow
* Keeping the mouse still in the unhide trigger area accelerations showing the panel. This is optional and is controlled by the configuration variable: stillMouseSpeedsShow ( yea. kinda a silly name )
issues:
* The UI does not expose the delay configuration variables
* The LetWindowsCover functionality is currently disabled; The unhide
hint is currently disabled.
Both of these were disabled only to ease focusing on just the autohide
behavior.
stillMouseSpeedsShow is a genius idea! If you could integrate this patch with the corner bug [1], I will be back to using hidden panels! Thanks! [1] https://bugs.kde.org/show_bug.cgi?id=224008 Created attachment 40534 [details]
Add configurable delays ; plus other autohide changes
changes since last patch:
* Possibly resolved regression where a panel would not be visible on all desktop.
* updated to patch latest in svn
still same issues as before
Ah darn. I totally misunderstood parts of the previous implementation. My patch is too complex and introduces too many regressions with this in mind. Will retry and post a, hopefully, simpler patch soon. Hello, I think the code from Kwin for hot corners should be used for auto hide panels also. The one where you have to actually push against the corner to trigger the panel. In the long run something like "mouse velocity" might be the right solution: http://forum.kde.org/brainstorm.php#idea86182_page1 Corey: if you are hoping to get this included upstream (which you may not, and that's cool too) then you really ought to be bringing this to plasma-devel@kde.org and/or reviewboard.kde.org the patch you posted, however, was as you noted far, far too complex. for instance, it creates an NxM matrix of interaction features thanks to the multiple enumerations. that is the last thing we want in this code which is already difficult enough to test and keep in order. that said, i really don't think it is worth making the before/after duration configurable. if steady hands are an issue, don't use autohiding panels. if the timeout is to short in general, we can increase it. but these kinds of options just lead to more configuration UI for the benefit of a very small group of people at the cost of everyone else. mouse acceleration based unhiding is similarly a really bad idea imho. it means you have to take a "run" at the screen edge and if there is one thing that mouse input devices are good at it's working up that kind of momentum against screen edges accidentally anyways. as such, i eally don't see it being anything more than a curiosity or an annoyance, depending and what your experience with it is. sharing code with kwin for screen edge activations is in the works, btw, though for other reasons (resolving screen edge trigger conflicts). in short, if you wish to work on panel behaviour, please contact the developers on plasma-devel@kde.org. there are open tasks there, one of which is to abstract out the hiding code from the rest of the PanelView code so it can be used by other plasma shells (and krunner, for that matter). another is to track active popups better (right now we have a few regressions there, even) *** This bug has been confirmed by popular vote. *** I just installed 4.4.76svn1127506 and found out that my auto-hide panel won't get out of my way before 5 long seconds have passed after I pulled it up. But how can I disable this time wasting delay? This bug and bug 267277 are essentially duplicates. Since the other one has a bit wider range of use cases argued, and contains the current discussion, I'm closing this one. *** This bug has been marked as a duplicate of bug 267277 *** |