Version: 3.3.0 (using KDE KDE 3.3.2) Installed from: Compiled From Sources Compiler: GCC-3.4.3 OS: Linux This is similar to Bug 86663 but with hidden panels, it rises to the level of a bug. If you have two panels meeting at a corner of the screen and they are *not* hidden, they do not overlap. But, if you have two hidden panels meeting at a corner and you are not careful and unhide both of them, they overlap and the second one to unhide is on top of the first one. There are various ways to fix this problem. 1. Unhiding the first one could lock the other(s) meeting at that corner so that it could not unhide while the first panel was visible. 2. The second one to unhide would not overlap the first one, but rather open behind it. 3. It could be possible to set the exact position of one end of (now) centered panels so that you could manually configure one of them not to cover the area that would be used by the other one(s). -- JRT
idea #1 would cause new bug reports (i can't unhide my panels sometimes!) idea #2 would simply rearrange the problem and not fix anything, really idea #3 is unnecessary and complex no, the solution is that when you unhide 2 panels... CLICK on the one you want on top or simply MOVE your mouse away a bit so that one of the hides again. or simply don't use setups like this in the first place =)
Re Comment #1 It is NOT possible to "CLICK on the one ... " so this is not a solution. Idea #1 would only apply to the area where the panels overlap so I do not see how this would result in more bug reports. The only people that would have a problem with it are those that want their panels to overlap [number = 0]. Idea #2 would exactly fix my problem. Test case. Make two panels that intersect at the upper left corner. The top panel needs to have have an Application Button at the left end. The left panel needs to have an Application Button at the top end. Try to click one of these two buttons and see that if you don't have perfect eye hand coordination it is very easy to get the wrong one. Specifically, if you want the top button on the left panel, you move the mouse to the left edge of the screen; the left panel appears. Move the mouse up to the top button and if you move it too far, the top panel appears and you click the wrong button. But, if the top panel appeared UNDER the panel that was already unhidden, there would be no problem. So, Idea #2 would 'really' fix the problem. Idea #3 was already requested by others (for panels that are not hidden) claiming that you could do it with OS/X on the Mac. Also, I did not intend to exhaust all possibilities with the listed 3 ideas. But, I will reduce it to WishList and see if there are other comments added. -- JRT
do not reopen bugs that i have closed. period. finito. feel free to add comments (which i'll get in my email) and *i* will decide whether it gets reopened or not. this is not your bug report, it is mine. noticed who it is *assigned* to? right. now, as for #3, yes, you can already manually configure it to not overlap as long as you don't set it to "expand to fill contents". i assumed you wanted something else. as for #2, what if you actually WANT the other panel? oh, right, now the behaviour is broken again. so NO, it isn't a fix. as for #1, what if they actually WANT to unhide the OTHER panel? now they'd have to re-hide the one they accidently unhid and select that other panel. so these fixes optimize it for YOUR behaviour, but YOU aren't the only user of kicker. as the maintainer i sort of have to take into consideration the over all usage of the program. i also need to keep in mind the code base ramifications of these changes. all things summed up, the answer is "This bug is closed as WONTFIX." do NOT re-open it.
Re: Comment #3 An apology for Aaron J. Seigo's remarks is requested. -- JRT
woah lets not fight please. I guess James could come up with an idea that might work, or he should make a patch himself (or ask someone to do it - that is what FREE software is about after all). btw, I myself think the current behaviour is best. option 2 would be counter-intuitive, I guess - the last unhiden bar should be on top.
Re Comment #5 To clarify option 2: This would only apply while the mouse was in the small area where the two Panels overlap. If it was outside that area the selected panel should be on top (or the other panel would have already hidden). I use "Immediate" autohide so there may be additional considerations when a delay is chosen which I did not originally consider. This is an example of why bugs should be discussed rather than summarily closed. It should be obvious that a Panel that is no longer selected, but rather is only waiting for the delay to time out, should not remain in front of a Panel that is currently selected. Given that clarification, why do you think that the last unhidden bar should be on top? AJS has complained that I am just stating how I "feel" when actually I have presented a test case in Comment #2 based on my actual useage. If you follow my test case, you will see that the Panel first selected is the one that is wanted. For the current option (which appears to be an accident -- a bug, not deliberate design) to be desired you would need to present a case where the Panel selected second is the one that is actually wanted and is needed while the first selected panel has not yet automatically hidden yet. Keep in mind that only the button(s) on the end of the Panel overlap and if the Panels are the same size, this is ONLY one button on each Panel that overlaps. This would appear to further restrict the possible instances where the Panel selected second was the one that was needed before the other panel was automatically hidden. Note that, users already intuitively know what to do to make a panel auto hide: move the mouse out of the panel so doing this should also make that Panel be on the bottom if it is waiting for the delay to time out. -- JRT
An additional and related problem is that the "icon mouseover effects" also don't have the correct X priorities and they can pop up behind another normally hidden Panel.
> An additional and related problem [...] this is not related to this bug report at all and is fixed in SVN trunk.