> On July 24, 2015, 1:25 a.m., David Edmundson wrote: > > the panel doesn't currently hide when the mouse leaves, only when another > > window gets focus. > > > > Do you have focus follows mouse set? > > David Kahles wrote: > Yes I have, without focus follows mouse it works as expected, I didn't > think about that. Is this something we don't fix? > > David Edmundson wrote: > ah cool, it explains the different behaviour. > > >Is this something we don't fix? > > I don't know, I don't think we want to change the normal experience for > this one edge-case. If you explicitly click on another window, there's no > reason to make this delay closing. > > On the other hand, if we are going to provide an option to do a thing we > should damn well actually support it. > > Does kwin expose if the user has focus follows mouse (we have a similar > bug with the add widgets dialog and this option) ? > If so can we come up with a good compromise that doesn't complicate code > too much? > > David Kahles wrote: > > I don't know, I don't think we want to change the normal experience for > this one edge-case > [snip] if we are going to provide an option to do a thing we should damn > well actually support it. > > I fully agree to both statements. There are multiple bug reports about > this/smimilar problems. In bug [1] Martin Gräßlin said > > We could alter the behavior of the add widget dialog by allowing Plasma > to query KWin's focus policy, but I would not recommend to go that road. > > Martin: Could you explain why you wouldn't do this? > > [1] https://bugs.kde.org/show_bug.cgi?id=262835#c8 > > Martin Gräßlin wrote: > Sure I can explain a little bit about it. We have several focus > strategies going from click to focus to focus strictly under mouse. With > every step the mouse gets more precendence. The strategies F(S)UM are called > "unreasonable" in the KWin source code. The idea is to pass focus always and > only to windows under the mouse. It's the users wish to have it behave that > way and that includes that windows close when focus changes. Given that I > consider it as wrong in Plasma to work around the users wish as it's also > against what the users of these strategies expect. > > That said I think we all agree that F(S)UM is not reasonable and that we > should not consider them. So lets look at FFM. Here the situation is similar: > KWin has an additional focus delay, but default that's 300 msec. So only if > the user moves the cursor to another window and stays there it will switch > focus and then close the window. Again I consider this as the users wish and > the expected result if the window closes. > > Now exporting to Plasma would mean introducing a complex protocol to > announce the currently used strategy and focus delay time for both X11 and > Wayland. It's kind of making Plasma interpret deep KWin internals. It's also > extremely KWin specific so with other window managers it wouldn't work. > > If the default of 300 msec is too short, we should rather look into > getting a better default into KWin than trying to work around in Plasma.
Thank you for your explanation. > It's the users wish to have it behave that way and that includes that windows > close when focus changes. Given that I consider it as wrong in Plasma to work > around the users wish as it's also against what the users of these strategies > expect. I think the users wish only applies to normal windows, which don't close when they loose focus. But this is a different case, as the plasma windows behave abnormal. > Now exporting to Plasma would mean introducing a complex protocol to announce > the currently used strategy and focus delay time for both X11 and Wayland. > It's kind of making Plasma interpret deep KWin internals. It's also extremely > KWin specific so with other window managers it wouldn't work. I understand the technical problems, would be very ugly. > If the default of 300 msec is too short, we should rather look into getting a > better default into KWin than trying to work around in Plasma. I don't think this would fix it. I have my delay usally set to 0ms because a higher delay interrupts my workflow. But again: this is no normal window, so the normal delays don't work here. It's even worse at the widget explorer dialog (Yes I know, a different issue, but related), because I have to move my mouse over 2 monitors to get there. This would need a delay of about 1sec. >From a user perspective, as I said above, I think we shouldn't increase the >normal delay, because this are abnormal windows. Saying we should respect the >users choice isn't right too IHMO because of the same reason. I think it's wrong that plasma windows behave so much different than normal application windows. Of course this saves click to focus users a mouse click, but brings big drawbacks to users of different focus strategies. I think we should alter the behavior of plasma windows if we support multiple focus strategies, but this is just my personal opionion, as I don't know the design reasons for the focus policy of the plasma windows. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124434/#review82849 ----------------------------------------------------------- On July 24, 2015, 11:51 a.m., David Kahles wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124434/ > ----------------------------------------------------------- > > (Updated July 24, 2015, 11:51 a.m.) > > > Review request for Plasma and Martin Gräßlin. > > > Repository: plasma-workspace > > > Description > ------- > > Wait (per default) 600ms to hide the panelconfigview, because > sometimes it happens that a user inadvertently leaves > the panelconfigview with his mouse. > Then he/she has to reopen the panelconfigview because it hides > immediately. 600ms should be long enought to move the mouse back into > the panelconfgview and prevent the hide. > > > Diffs > ----- > > shell/panelconfigview.h 98705d13875c92acdc46355f600ce8541e4596f4 > shell/panelconfigview.cpp dee2acc8618bf6341de1427dc18c2a2a00463c15 > > Diff: https://git.reviewboard.kde.org/r/124434/diff/ > > > Testing > ------- > > Using the panel configuration bar works much better now as it doesn't hide > immediately. > > > Thanks, > > David Kahles > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
