Version: (using KDE KDE 3.1.1) Installed from: Debian testing/unstable Packages In a xinerama configuration, for example with one screen above the other and a vertical child panel on the lower screen, the panel hide button towards the upper screen does not work. This bug is essentially the same as bug #47748, which was marked RESOLVED INVALID. (The bug tracker does not allow normal users to reopen bugs.) However, the reasoning given for closing the bug, "I believe this is by design", was insufficient because if it is by design, it is certainly bad design. First of all, the edge between xinerama screens clearly has meaning in operations such as maximize. Why should it not be allowed to minimize a panel against this edge? Second of all, even if someone decides that this is not useful, having a button that defies the wish of the user and does nothing is CLEARLY A BUG. At worst, the button should be hidden.
The first part of this bug report is a wish. I personally agree with the concept of not allowing a panel to be hidden at the boundaries. One reason is that it is hard to show the panel again with a button on the midst of your screen. The second partis a valid though cosmetic, minor bug (marking as such). But it might not be easy to solve this as you can always re-arrange your screen which could invalidate existing hide-buttons.
I also find this annoying. Personally, I have 2 monitors in xinerama, and my main one, on which I have the panel full width, is on the left. If I want to play a game, or watch DVD, then I change metamode in X such that the right hand monitor is de-activated. (Otherwise I end up with the game/video split between screens - which is ugly!). At that point, I would like to hide the panel, using the right hide button. Yes, I know that one can have a left hand hide button, but this is easy to click by mistake instead of the K-menu. So in my case, I very much *do* want the non-working panel-hide button to work! [a "metamode" is the way that the Nvidia drivers refer to a combination of two modes on both displays. Nvidia call it "twinview"]
This still doesn't work in kde 3.4. It really would be nice if it were fixed :-) For me, the case below is desirable: |----------|----------| | | | | 1 | 2 | | | | | | | |=========*|----------| 1 and 2 are the monitors. The panel is on monitor 1, denoted by ===== The panel hide button is denoted by *.
This works for me in Nvidia's twinview, because the monitors are on different resolutions. The panel hides if it can go into the "unseen" portion of monitor 2. Interestingly, if you move your mouse below the seen area of the monitor, you can interact with the panel, opening menus and things, even while it's hidden. my setup: |----------|----------| | | | | 1 | 2 | | | | | |----------| |=========*| Hiding works like this: |----------|----------| | | | | 1 | 2 | | | | | |----------| |---------*|========= < Panel in "unseen" rectangle below monitor 2 Moving my mouse through the unseen area, I can still open the K Menu etc. The panel will refuse to hide into a visible area of the second monitor.
Interesting. Unfortunately, both my displays are identical. My workaround at the moment is to temporarily drag the panel onto display #2 and then switch off monitor #2. :-)
yes, this is still not fixed in 3.4. it's non-trivial to fix and i don't have a xinerama set up at home where i do most of my kde hacking. sadly.
Forgive me if this suggestion is daft, but surely this whole issue arises because there is some code to detect: Is the user attempting to hide the panel somewhere where it would be "meaningless" to hide it? If so, disable the hide-button. I'm guessing that the non-triviality of the fix is associated with the difficulty in determining whether a hide is meaningful or not. In that case, surely a better solution is to remove the test entirely, and just assume that if the user has turned on the hide button, then when it gets pressed, the user wants to actually do this! (So, we don't protect the user from doing something daft, but we do give the user the chance to do what he asks.) A refinement would be to remove the test only if xinerama is currently enabled.
> just assume that if the user has turned on the hide button, then when it gets > pressed, the user wants to actually do this when the hide action is activated in such circumstances, the panel simply moves over to the other xinerama screen. it doesn't actually hide (this is because the hiding is done by simply moving the panel off-screen)
I take it this is still broken in 3.5. I just confirmed that even on a same-resolution twinview setup such as Mr. Neill has, turning on panel "autohide" works fine. Why not just hide the panel the same way you would if autohiding?
It is still there in 3.5.1. I have the same setup as http://bugs.kde.org/show_bug.cgi?id=57963#c3 . I put my kicker on the left screen, because I use it more, and I put the hide button to the left because on the right it would defeat the "infinite depth" of the K button, so it is a real life bug for me.
I'm still seeing this bug on 3.5.4 Like Szokovacs Robert's setup, I like the infinite depth of the K button (throw the mouse at the corner and you're there, no matter how much farther the mouse goes). Instead of disabling the button, I would prefer that the hiding still occurs. Maybe if it's easier for the programmers, the panel could fade down past the monitor instead of off to the right onto visible screen. But it would still be preferable that it works off to the right as it normally does.
Kicker is no more mantained and all bugs/wishes will not be fixed/implemented in KDE3. A list of the most interesting/unresolved issues which is still valid for KDE4 has been created. Before reopening old kicker bugs on KDE4 Plasma, please try the new KDE 4.3.1, check the current behaviour and, only if you find new bugs or if you need a particular feature, open a new bug report. Remember that KDE 4 is a full rewrite of KDE 3 so some old features will not be re-implemented because the behaviour has be changed a lot on some sides. Thanks for the comprehension and enjoy the new KDE 4! -- FiNeX & D. Andres