80897 2004-05-04 16:24:37 +0000 focus under mouse - focus stealing preventinon doesn't work 2013-09-24 19:58:01 +0000 1 1 4 Plasma kwin general unspecified Debian testing Linux RESOLVED WONTFIX NOR wishlist --- 1 kde-bugs kwin-bugs-null bkorb brendan brian erkintek kde rlk 0 oldest_to_newest 228774 0 kde-bugs 2004-05-04 16:24:37 +0000 Version: (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages the granularity of the "focus stealing prevention level" should be more fine grained: - if i choose "normal" any opening window grabs the focus -- this is not only annoying but also a security issue as eg passwords you're just typing appear elsewhere - level "high" prevents _any_: widow to pup up in the forground, instead the button on the wiondowbar flashes there should be made a decision whether the user is typing something or not and thus depending on this decision the window should grab the focus or not. used together with "focus under mouse" even the case "i'm just reading and the new window gets the focus :-(" could be managed 228821 1 l.lunak 2004-05-04 18:07:09 +0000 This is one of the reasons I added extra text to description of the 'mouse (strictly) under mouse' policies saying that these policies break several other kwin features. With other focus policies it should work fine. I'll leave this report open as wishlist, as maybe it's possible to get focus stealing prevention somehow working even with those policies, but it's hard enough even with reasonable focus policies. 321902 2 rlk 2005-03-07 20:19:18 +0000 I'd like focus stealing to be complete, even with "focus strictly follows mouse". For background, I use focus strictly follows mouse, with both auto raise and click raise turned off. I'd like to have focus stealing entirely disabled, so that the focus is *only* where I choose to move the mouse. I'm fully aware of what this means, and it's what I want: if I move the mouse into a window that's partially obscured, and start typing, my typing will go into that window, and I may be typing blind. That's exactly what I want. Likewise, I don't want pop up windows to grab the focus under any circumstances. In fact, I'd like windows to pop up *away* from the mouse where possible if the mouse is over a window. I prefer focus (strictly) under mouse so that I can entirely defocus. I'm not certain whether this is exactly the same thing, but whenever a window is popped up, the desktop is forcibly switched out from under me to whichever desktop the window pops up on. In addition, certain windows (such as those spawned by javaws) always seem to get focus whenever I switch into a desktop containing these windows, even though I'm using focus strictly follows mouse. What it really boils down to is that I simply don't want the focus to ever change except by my action, and I want to be able to have no focus in addition to focus on the window of my choice. Other than alt-tab (which I never use), what other features are broken by focus (strictly or otherwise) under mouse? 471438 3 l.lunak 2006-09-20 17:03:20 +0000 *** Bug 134330 has been marked as a duplicate of this bug. *** 629803 4 bkorb 2008-07-27 20:12:09 +0000 "wishlist"? http://www.codinghorror.com/blog/archives/001011.html http://en.wikipedia.org/wiki/Focus_stealing -- ``This is considered a major annoyance by most users'' It is a bug. Brain damage inspired by Microsoft Windows and emulated in KDE. Setting focus stealing prevention to "extreme" is insufficient in KDE. There is one and only one reasonable exception: xv (and similar programs that might need to capture window content via selecting "current"), but even then it should be possible for the program to capture what it needs without stealing back focus. If setting prevention to "extreme" is not strong enough, then you have to invent a term to mean "absolutely, positively, never, ever allow any program to steal focus, period. No exceptions". That should be strong enough. 630027 5 l.lunak 2008-07-28 14:22:42 +0000 I have no problem accepting a patch from somebody smarter than me. 630029 6 rlk 2008-07-28 14:28:59 +0000 In bug 134339 you stated: Focus stealing prevention doesn't work with focus (strictly) under mouse focus policies because of difficulties with these focus policies. A patch is welcome. What are the difficulties with these focus policies that prevent focus stealing prevention from working? If it's window manager features like alt-tab and such, that's fine -- I have no problem with those not working. But please be specific. 630057 7 bkorb 2008-07-28 15:17:11 +0000 ``I have no problem accepting a patch from somebody smarter than me.'' I'd hope that somebody more familiar with the code than me could do it without an extreme amount of effort. After all, how many different functions in the code actually set focus? if (focus_policy == DO_NOT_EVEN_THINK_ABOUT_REFOCUSING) return; If it isn't close to that easy, maybe the code needs some reworking. And, for what it is worth, setting focus with keyboard shortcuts does not make any sense with focus under/follows mouse policies. Not only would I not complain about them being disabled, I think it would be a bug to have them actually work. If the mouse controls focus, then perforce the keyboard cannot. 630061 8 l.lunak 2008-07-28 15:28:28 +0000 I don't remember anymore, it was a long time ago. In general, focus under mouse policies break normal assumptions about how focus works. For example, the basic rule of focus under mouse is that the window under the mouse is active. If the window under the mouse is to be always the active one, then this rule conflicts with any other rule about which window should be active, such as with focus stealing prevention. I don't remember the details, but it was simply too much work for too little gain. 630082 9 bkorb 2008-07-28 16:24:03 +0000 "too little gain" -- let me explain why I use "focus follows mouse". When you must click to focus, unless you are careful to hit the title bar, the click is passed to the application and it responds to the click. More often than not, this perturbs the "current position" in that application. This can be a great inconvenience. To avoid that problem, you can use the "alt-tab" method of navigation, but when you have two wide-screen monitors and a half dozen or more windows in each of several desk tops, um, that doesn't work so well either. So, you're back to mouse selection wherein you have to make sure you get it exactly on the title bar, without touching any functional buttons that may be up there, too. For me, the gain would not be "too little", other than the fact that there is a monumentally huge learning curve in getting to understand the KWin code. Thank you for your time and consideration. Regards - Bruce 630092 10 rlk 2008-07-28 17:00:19 +0000 I guess I see one problem with focus follows mouse, but it need not apply to focus strictly follows mouse. If the mouse is over the root window, then with focus follows mouse the focus is delivered to the last window to have focus, while with focus strictly follows mouse (my preference), nothing has focus (or rather, the root window has default focus, but since it doesn't accept keyboard events, that doesn't matter. Now let's suppose a new window pops up under your mouse; it gets focus by either FFM or FSFM. If your mouse is over a window, then what should probably happen is that the new window pops under the existing window, so there's no problem, but if the mouse is over the root, it will suddenly get focus. With FFM, that defeats focus stealing prevention, but with FSFM, it's "stealing" focus that just isn't there to begin with (or you could say that it's "taking", but not "stealing", focus). I'm willing to live with that particular exception to focus stealing prevention, and with FSFM, it's arguably not even an exception to begin with. Another possibility would be that newly created windows never get focus *at all* until you perform some specific action to give focus. For example, moving the mouse into the window (if the mouse is over the window where it popped, you'd move the mouse out and back in), or clicking on the title bar, or explicitly raising the window (which I do with a keystroke -- alt-f1 -- that's explicitly bound to that). 630300 11 bkorb 2008-07-29 04:30:44 +0000 ``if the mouse is over the root, it will suddenly get focus. With FFM, that defeats focus stealing prevention'' Yep, true enough. Also enough of an end-case that I don't really care. This scenario would not yank me from one desk top to another. This scenario would not yank my mouse from my current window to another existing window and give it focus. Those are my crucial gripes. End cases where exact meaning become fuzzy can go any way and I don't care a lot. It is the day to day Thunderbird and even emacs yanking me about that I find unacceptable. ``I'm willing to live with that particular exception to focus stealing prevention, and with FSFM, it's arguably not even an exception to begin with.'' I think we're pretty much in complete agreement. We just need to convince someone intimate with the code to improve the focus stealing prevention for mouse-following focus policies. :) 765902 12 brendan 2009-05-27 21:31:09 +0000 Can we get the severity bumped up? Its a "brain dead inspired" security flaw! 1153675 13 cfeck 2011-08-14 09:50:25 +0000 *** Bug 280051 has been marked as a duplicate of this bug. *** 1153676 14 cfeck 2011-08-14 09:52:09 +0000 Bug 280051 suggests that this is a bug (that could affect security), not a feature request, and severity should be raised accordingly. 1153708 15 mgraesslin 2011-08-14 12:49:53 +0000 (In reply to comment #14) > Bug 280051 suggests that this is a bug (that could affect security), not a > feature request, and severity should be raised accordingly. I disagree: focus under mouse is a broken concept. Users who use it are aware of the limitations including the fact that focus stealing prevention does not work. If users want to have the functionality of a reasonable focus policy, they have to use one of those. The only solution I see to fix this "bug" is to remove the unreasonable focus policies. 1153719 16 bkorb 2011-08-14 13:39:38 +0000 ``focus under mouse is a broken concept'' And I think that clicking a window to set focus *AND THEN PASS THROUGH THE CLICK* is a broken concept. Furthermore, since my work tasks take me from window to window all the time, I would be continually having to click the window and then adjust current place (reclick) within window -- assuming I can remember where I was. Over and over and over again. All day long. Broken. FSFM is much better than that, even if some of you think I am wrong to find it more convenient. 1153720 17 mgraesslin 2011-08-14 13:44:10 +0000 > FSFM is much better than that, even if some of you think I am wrong to find it > more convenient. If focus follows mouse is working for you, just use it. Focus follows mouse belongs to the reasonable focus policies. Only Focus under mouse and focus strictly under mouse are broken from the concept. 1153721 18 thomas.luebking 2011-08-14 13:47:02 +0000 FTR: The security issue claim is completely bogus. What do you think how kglobalaccel (global shortcuts) works? (Your application has the focus and nevertheless another application can react to keyboard events... just think about it... Run "kcmshell4 keys", try to set "a" as shortcut to anything, now try to enter that char anywhere. A keylogger would just not eat it but pass it on to the client or use XTest to pipe it back into the system when unsure where to drop it) => The protection against malware is to not run it. Now run "pinentry-qt4" and enter "getpin" when it asks what to do. Next try to trigger any global shortcut, including alt+tab or whatever. (for the ubuntu users: ctrl+d quits pinentry after you closed the window) Usually any client can "read" the input to all other clients unless one client actively grabs the keyboard. At this time the focus state of the window doesn't matter anymore and /this/ is, how secure input in X11 works - not by hoping to have the focus or whatever (what doesn't get you *anything* in this regard) geee... ;-) =================== On topic: i'd say anyone here's precisely asking for "Focus Follows Mouse" (read: "FOLLOWS", not "UNDER") which allows for focus stealing prevention as well as alt+tab and will not pass the focus to a client that randomly shows up under the pointer (what is however different from focus stealing) A wish to separate focus from raising (ie. allow the client to raise but not pass it the focus alongside the stealing prevention) is iirc pending somewhere else in this bugzilla and not hard to do at all. ============ F(S)UM are rather for old (maybe now rather "dead"?) X11 geeks and perhaps users of window tiling. Removing them might be a little bold, but since there's plenty of space in that dialog below the setting, there could indeed be a "Don't be stupid - you don't want this!" message. But if I was a ditributor targetting certain kinds of users, i'd just remove them downstream. Moving away the mouse is worse than anything and -i'd say- no option at all and moving away the window can easily collide with window geometry requests as well as with the requirement to find *some* decent position for the client. 1153723 19 rlk 2011-08-14 13:58:02 +0000 Why can't it be made to work, and why is it a broken concept? See my suggestion in #10 above: if you can't find somewhere reasonable to put the window that doesn't collide with the existing window, pop it *under* the current window (this would work with both FUM and FFM), or even at the very bottom of the stack altogether (just above the root window). The two typical issues I have are: 1) At startup, I'm starting a number of things (several xterms, emacs, pidgin, and firefox). When pidgin starts up, it puts up a password prompt in the center of the screen. Firefox takes longer to start up, so it pops up over the password prompt. I either have to take a chance on typing my password before Firefox pops up, move the password prompt to somewhere on the screen I hope firefox won't pop, or wait for firefox to come up before typing my password to pidgin. 2) I have some huge spreadsheets, and LibreOffice takes its time getting started, in any event. So I want to start that spreadsheet, and while it's getting going, do something else. It might take 20-30 seconds between clicking the icon and the spreadsheet window even getting created, during which I can't do anything else because the spreadsheet might pop up at any moment. 1153726 20 thomas.luebking 2011-08-14 14:18:59 +0000 Did you ever try "focus FOLLOWS mouse" then? 1153753 21 rlk 2011-08-14 16:17:41 +0000 <grin type="sheepish">Thanks, that combined with high focus stealing prevention appears to do exactly what I want (on superficial testing).</grin> However, there's a comment that "high" focus stealing prevention probably doesn't work with mouse focus policies. That doesn't appear to be the case, so why is that comment there? 1153767 22 thomas.luebking 2011-08-14 17:41:42 +0000 (In reply to comment #21) > However, there's a comment that "high" focus stealing prevention probably > doesn't work with mouse focus policies. Forgive my ignorance: "there" is "where"? 1153785 23 rlk 2011-08-14 19:15:26 +0000 My apologies; it's in the Help for Window Behavior in the KDE Help Center (not to mention that I misread it -- it states "This setting is probably not really usable when >not< using mouse focus policy"). I guess I'm having a bad day :-( (Now, if I could only figure out how to turn off smooth scroll in the help center; the Konqueror setting doesn't apply to it. But that's a subject for another bug.) 1153985 24 rlk 2011-08-15 14:23:28 +0000 So FFM has one important problem: if I use keyboard accelerators to raise/lower windows, the focus doesn't change (or it changes to something other than what I expect) when I lower the window under the mouse. This is a rather serious problem for my working style. I normally create a stack of xterms (2 or 3, but sometimes more) at the top right of the screen (all 80x72, so they're a strictly coinciding stack of windows). I typically also have a Firefox and one or more emacs windows scattered about. I use alt-F2 as my accelerator to lower a window (don't ask why I use that accelerator; I doubt it matters, but just for completeness; alt-F1 is raise, alt-F2 is lower, alt-F3 is minimize, probably from back in the X9 days when xwm was the only window manager). My expectation is that when I do this the window under the mouse (another xterm) is the one that will receive focus, but instead something else gets the focus. 1154075 25 thomas.luebking 2011-08-15 19:42:12 +0000 "of course" - because the focus follows crossing (window borders) events what does not happen. Otherwise you'd end up with FUM and with the same issues regarding the focus stealing. KWin could however act differently for events triggered by itself or rather explicitly provide "lower window AND put focus to the window with the cursor above it if using FFM" atm. you can change the focus chain from "recently used" to "stacking order" what passes the focus to the most top one (in this situation) - i think there's another report with such request (to prefer the cursor position - see bug #159989) Interesting that we get all this requests on the again atm, seems KDE4 gets adopted by the geeks ;-) @EVERYONE: would FFM alongside a 3rd option for the next focus (bug #159989) fit your needs? ("so that we can close this bug, spend more time on the other, write a patch and get it fixed") Seriously: afaics focus UNDER mouse will never work with any focus stealing protection. Iff you can prove different, that'd be great. 1154084 26 rlk 2011-08-15 19:55:26 +0000 From what I can determine, FFM combined with focus stealing prevention *and a change to the focus chain to pass focus to the window immediately under the mouse* would work for me. The special case of "Kwin could however act differently for events triggered by itself" would not be sufficient: when a window closes of its own accord (e. g. by exiting from an xterm), I want the focus to pass to the window under the mouse (and if that's the root window, focus should pass to the root window). This suggests a policy of "focus strictly follows mouse", which would probably be what I want. The workarounds described in 159989 (use either autoraise or click to raise) are specifically *not* acceptable to me. 1154090 27 rlk 2011-08-15 20:00:59 +0000 By the way, my usage pattern has no concept of "recently used" window. I don't use alt-tab navigation between windows, so I don't want the window manager selecting some arbitary window to receive focus. 1154145 28 bkorb 2011-08-15 22:52:29 +0000 And, for more completeness, here's my usage pattern: I have lots of windows open that are all highly sensitive to "current position". Like "rlk", I haven't the foggiest notion of which window may be next-most-recently-used. I know where my mouse is. I never, ever, *ever* want focus yanked from where I am working without explicit action on my part. That little pop-up task manager would be cool for that, if only it did not pop up for windows that are gone and if the "come and see me" window were always flagged with that red star. It is broken and the subject of other bug reports. So, don't yank me around. Another crucial point is that I do not want to perturb windows in order to give it focus. If I click it, the click gets passed through and current position is trashed. If I use keyboard shortcuts, I have no control over which window is going to become "in focus". So, I like moving the mouse and let that be my indicator as to what I want to become in focus. No need for extra keystrokes. No clicking and perturbing windows. Just move the mouse and now that window has focus. Simple. Easy. Clean. Fast (0.2 second setting). That's the way I need to work. I don't really give a hoot what the policy name is. That is the behavior I need. My current policy is called "Focus Follows Mouse", only just now learning that there is a distinction between that and "Focus Under Mouse". A clear warning with a description of the distinction would be helpful for folks without the detailed knowledge that many folks here have. With all of that said, I must confess that I haven't been yanked about recently the way I was several years ago when I first came upon this bug report. It is possible (likely?) that some intervening fixes made the situation more bearable. The main remaining gripe about the situation is that with "extreme focus stealing prevention", many windows pop under and remain hidden because the task bar thingey doesn't necessarily highlight the new window with that little red star. With that glitch fixed, I think I'd be a happy camper. (vis-a-vis focus management anyway) 1154158 29 thomas.luebking 2011-08-16 00:31:39 +0000 (In reply to comment #28) > I never, ever, *ever* want focus yanked from where I am working without > explicit action on my part. -> FFM, extreme stealing protection (i later read that you tend to agree ;-) > If I click it, the click gets passed through and current position is trashed. FTR: You are aware that you can only give it the focus or in addition raise it but NOT pass the click to the client? (kcmshell4 kwinoptions, "window actions") > It is possible (likely?) that some intervening fixes made the situation more > bearable. Since 2008? I don't think so. > With that glitch fixed, I think I'd be a happy camper. One could actually use the compositor to (translucently) display the window on top of the stack and then "melt" or at least fade through to it's actual stack position (this is only visual. it would never intercept clicks or affect the focus) 1192845 30 thomas.luebking 2011-12-01 12:29:11 +0000 Git commit f7140b7ff0763335d3996ce3e635325d7a25bea7 by Thomas Lübking. Committed on 22/08/2011 at 13:53. Pushed by luebking into branch 'master'. add mouse preference against focus chain there's currently no GUI config item, use kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true qdbus org.kde.kwin /KWin reconfigure BUG: 159989 CCBUG: 80897 FIXED-IN: 4.8 M +59 -31 kwin/activation.cpp M +61 -46 kwin/kcmkwin/kwinoptions/windows.cpp M +2 -0 kwin/kcmkwin/kwinoptions/windows.h M +2 -0 kwin/options.cpp M +1 -1 kwin/options.h M +17 -0 kwin/workspace.cpp http://commits.kde.org/kde-workspace/f7140b7ff0763335d3996ce3e635325d7a25bea7 1220993 31 rlk 2012-01-31 03:33:36 +0000 This is still not working in KDE 4.8.0 (OpenSUSE 12.1 KDE:Distro:Factory, kwin-4.8.0-722.4.x86_64). If I use meta-F2 (which I've bound to lower window), the active window doesn't always become the one under my mouse. Sometimes I have to do this a few times to get the incorrect behavior, but as best as I can tell the behavior is the same as in 4.7.4. I'm attaching my kwinrc. 1220994 32 68358 rlk 2012-01-31 03:34:47 +0000 Created attachment 68358 kwinrc with KDE 4.8.0 NextFocusPrefersMouse does not appear to work. 1221201 33 thomas.luebking 2012-01-31 13:17:45 +0000 Lowering a window does not activate another. FFM is not FUM, will not be and can not be. If we'd change the behaviour like this, you could immediately forget about focus stealing prevention and just use FUM anyway. Affected are situations when another window becomes activated because the current one is minimized, closed or you change the desktop or so. 1221217 34 rlk 2012-01-31 13:53:52 +0000 Actually, lowering a window *does* result in a different window being activated with FFM as well as with FUM. Sometimes that window happens to be the one under the mouse, and sometimes it's a different one. The problem here is that when I lower a window by means of my keyboard accelerator, even with this latest change sometimes kwin picks a different window to activate. What I want, in essence, is for windows to not grab the focus unless I make a decision to do so. So if a window pops itself up, it should not grab the focus (like FFM with high focus stealing prevention), but if I lower a window by means of a keyboard accelerator or something, it should recalculate the current window. 1221319 35 thomas.luebking 2012-01-31 16:53:35 +0000 (In reply to comment #34) > Actually, lowering a window *does* result in a different window being activated yes, sorry. you're right. This is the "lower" ./. "toggle raise and lower" situation. The lower shortcut/mouseop picks the topmost client and activates it - no idea whether this is really sane and how to handle, but the patch and config item deals only with picking the "next" client to activate what this code simply doesn't do. => we need to figure what to do when the user lowers a client (for the toggle variant doe not alter focus), but that is a different issue. 1228770 36 rlk 2012-02-20 14:21:40 +0000 It should pick the topmost client *that is under the mouse* to activate. That may result in the same client staying active, if it is the only one under the mouse. This is the only behavior that makes sense to me. 1228815 37 thomas.luebking 2012-02-20 15:48:28 +0000 That is actually about to change - the history of that lower ./. toggle raise/lower has been sorted out as well (mostly because of the keyboard shortcut, that one will likely change for 4.9) https://git.reviewboard.kde.org/r/103975/ 1229126 38 rlk 2012-02-21 14:04:59 +0000 So no relief for another 6 months? :-( The current behavior appears objectively wrong to me, at least from a user standpoint. "Focus under mouse" should have the focus under the mouse whenever possible. Activating a random (from the perspective of the user) client, that isn't under the mouse, makes no sense whatsoever. 1229155 39 thomas.luebking 2012-02-21 16:27:43 +0000 Actually for the "unreasonable" focus policies it's ok to skip that change for even 4.8 since they're also bypassed for the "activateNext" stuff (which the current behavior apparently was derived from) because the focus is supposed to be always mouse driven - we just cannot alter the "regular" behavior (including FFM) w/o introducing a new regression. Ultimately the lowerClient slot was then abused to get the alt+esc shortcut behavior, common among several systems. 1229158 40 rlk 2012-02-21 16:34:47 +0000 What is alt-esc (sorry, I use accelerators)? What's the bottom line here? Can focus under mouse be made to work properly, do we need a new policy that does do the right thing, or what? 1229236 41 thomas.luebking 2012-02-21 19:39:58 +0000 the alt+esc shortcut triggers some sort of inverse alt+tab where the current client is deactivated and positioned on the bottom of the stack (no, wasn't aware myself until recently ;-) To support both, the alt+esc behavior and the former "plain lower" we'll have to introduce a new shortcut, thus new visible string, thus wait for 4.9 The "alt+esc" condition however makes absolutely no sense in the pure mouse drive F(S)UM policies (but does in FFM & CTF) what means it doesn't have to be implemented there at all (so the window is just lowered and the focus stays with the mouse, since this is what F(S)UM is about) The behavior for lowering the window with the mousebutton will in 4.8.1 be (in general!) to pass the focus to the client under the mouse (which may be the same one) unless the lowered client didn't have the focus anyway. In addition it's possible and justified to skip that alt+esc shortcut behavior for F(S)UM (and 4.8.1 as well) For 4.9, the "lower window" shortcut and the "alt+esc inverse tabboxing" shortcut should become distinct - regardless of the focus policy. Altogether this has however ABSOLUTELY nothing to do with this actual bug being about FUM & focus stealing prevention - that's no gonna work anyway. ---- inb4 "finally": it wasn't that easy to sort out what happened when and (probably) "why" in this regard. 1229239 42 rlk 2012-02-21 19:49:32 +0000 Ah. I don't use alt-esc (or alt-tab, for that matter). I have alt-f2 bound to Lower Window (alt-f1 bound to Raise Window, and alt-f3 bound to Minimize Window). This comes from the old X10 xwm behavior. Using FUM, this only deactivates the window if it results in the mouse being immediately over a different window when it's lowered. If lowering the window results in the same window being under the mouse, it stays active. What I want is this behavior combined with focus stealing prevention. I don't care what it's called. With FFM, it looks like the behavior is *almost* correct, except for shifting focus to what appears to me to be a random window rather than the one immediately under the mouse. 1233653 43 thomas.luebking 2012-03-07 20:54:57 +0000 Git commit 095c602617949afc55e34d0634f8de8357ca28eb by Thomas Lübking. Committed on 21/02/2012 at 23:55. Pushed by luebking into branch 'KDE/4.8'. - lower windows does not change focus for F(S)UM - lower by shortcut honors nextFocusPrefersMouse setting REVIEW: 104041 M +10 -3 kwin/useractions.cpp http://commits.kde.org/kde-workspace/095c602617949afc55e34d0634f8de8357ca28eb 1233738 44 rlk 2012-03-08 03:53:49 +0000 Don't know all of the details of the code, but that looks right. 1237540 45 thomas.luebking 2012-03-17 22:06:02 +0000 I'm closing this bug that initially says "make FSP work with FUM" as won't fix because that cannot fix and the whole thing turned to anything different and nobody can read through all this ;-) In case there are other issues or suggestions regarding FFM, please check whether such report is already present or head over to the brainstorm section of forum.kde.org (unless you're really sure the behavior is actually a bug and no way intended) you may also be interested in https://git.reviewboard.kde.org/r/104316/ 1395584 46 rlk 2013-09-06 19:39:44 +0000 So it looks like there are a few new policies in 4.11, but they still don't do what I'm looking for. The one of interest is "Focus follows mouse - mouse precedence" which is described as "This is mostly the same as Focus Follows Mouse. If an active window has to be chosen by the system (e. g. because the currently active one was closed) the window under the mouse is the preferred candidate. Choose this if you want a hover controlled focus." What I want is for newly-created windows to be at the top, but to not receive focus until I take action to give it focus (by moving the mouse into them). If I set focus stealing prevention to medium, new applications that I pop from something else receive focus even though they're not under the mouse. Say, for example, that I have an xterm window on the right side of my screen, and type "emacs" into it. The emacs window is created at the left side of the screen, and receives focus. It should not (by my preference) receive focus. If I set focus stealing prevention to high, then new applications don't get focus, but in some cases they're left at the bottom, invisible. Starting emacs from xterm works correctly (the emacs window is at the top of the stack, but does not receive focus). However, if I launch an application from the KDE menu or from the panel, that application remains hidden at the bottom of the window (presumably I would miss reminder windows that way). I want it visible, just not receiving focus. Both of these *almost* do what I want, but in both cases, the things that don't work are severely problematic. 1395595 47 bkorb 2013-09-06 21:15:00 +0000 (In reply to comment #46) > So it looks like there are a few new policies in 4.11, but they still don't > do what I'm looking for. Thank you. You described my preferences perfectly! 1. new windows should always be visible 2. they should never receive focus until the mouse moves into it. How visible is a "resolved -- won't fix" bug anyway? Does that mean the KDE project would like us to file another? One that describes these remaining relatively minor anomalies? 1395597 48 thomas.luebking 2013-09-06 21:35:42 +0000 (In reply to comment #46) > So it looks like there are a few new policies in 4.11 No. Only the GUI got bumped to better reflect available focus policies. > What I want is for newly-created windows to be at the top, but to not > receive focus until I take action to give it focus Unrelated to focus policy. This is matter of focus stealing prevention *only*, not distribution. The window gets the focus because it asks for it, focus management is possible (in contrast to with F(S)UM) and the stealing prevention is "too low" to prevent it. What you complain about is simply that focus and layer are tied. See https://bugs.kde.org/show_bug.cgi?id=110543 and http://forum.kde.org/viewtopic.php?f=83&t=101833 and https://git.reviewboard.kde.org/r/110919/ > If I set focus stealing prevention to medium, new applications that I pop > from something else receive focus even though they're not under the mouse. This has nothing to do with the mouse, see above. 1395598 49 thomas.luebking 2013-09-06 21:43:18 +0000 (In reply to comment #46) > So it looks like there are a few new policies in 4.11 No. Only the GUI got bumped to better reflect available focus policies. > What I want is for newly-created windows to be at the top, but to not > receive focus until I take action to give it focus Unrelated to focus policy. This is matter of focus stealing prevention *only*, not distribution. The window gets the focus because it asks for it, focus management is possible (in contrast to with F(S)UM) and the stealing prevention is "too low" to prevent it. What you complain about is simply that focus and layer are tied. See https://bugs.kde.org/show_bug.cgi?id=110543 and http://forum.kde.org/viewtopic.php?f=83&t=101833 and https://git.reviewboard.kde.org/r/110919/ > If I set focus stealing prevention to medium, new applications that I pop > from something else receive focus even though they're not under the mouse. This has nothing to do with the mouse, see above. 1395599 50 thomas.luebking 2013-09-06 22:04:11 +0000 (In reply to comment #47) > How visible is a "resolved -- won't fix" bug anyway? Not. The bug won't fix ever. > Does that mean the KDE project would like us to file another? No, attach to the proper bug. This one "focus under mouse - focus stealing preventinon doesn't work" is a logic conflict. If the focus is controlled by the mouse, it's not controlled by something else. This is not a WONTFIX but a CANNOTFIX. > One that describes these remaining relatively minor anomalies? It's not "minor anomalies". See links. 1395733 51 kde 2013-09-07 19:10:32 +0000 (In reply to comment #50) > This one "focus under mouse - focus stealing preventinon doesn't work" is a logic conflict. If the focus is controlled by the mouse, it's not controlled by something else. This is not a WONTFIX but a CANNOTFIX. It's not a logic conflict... because focus stealing prevention does more than just prevent focus stealing: it also prevents desktop yanking. On low focus stealing prevention, some applications such as thunderbird often switch desktops under the user, even with focus under mouse. 1395743 52 thomas.luebking 2013-09-07 20:05:32 +0000 (In reply to comment #51) > It's not a logic conflict... because focus stealing prevention does more > than just prevent focus stealing: it also prevents desktop yanking. On low > focus stealing prevention, some applications such as thunderbird often > switch desktops under the user, even with focus under mouse. "Unlikely" The Exreme setting (and only that) would prevent an _active_ thunderbird window on one virtual desktop to pass the focus to another thunderbird window on another virtual desktop. Ie. if you tried to open a message window by doubleclicking the message and the message is on another virtual desktop, thunderbird would send you there except you rule that away as "extreme". That's it. What you much more likely encounter (because there's somewhere a bug we tagged invalid) is that thunderbird (or firefox or songbird), which is a veeeeeery important application, switches the current desktop in order to be able (or not) to gain the focus for sure (because the usual behavior of WMs is to deny focus passing to other dektops) - or abuse the "tool" hint (meant for pagers and taskbars) to activate the window forcefully. Neither could be blocked in the WM and is just a mozilla annoyance. If you can explain how to trigger this in (preferably) firefox or thunderbird, i'll check what it does in particular but if it's just "opening thunderbird on a different virtual desktop changes that desktop" that's client cheating for sure and not be prevented by any focus stealing prevention. 1395746 53 kde 2013-09-07 20:35:54 +0000 (In reply to comment #52) It's a while ago since I had observed these issues, so maybe things have changed/improved since then. In Thunderbird, it used to switch desktops whenever a networking error happened which brought up an error dialog box. Nowadays, Thunderbird uses a different GUI element (flashbox?) to notify of such asynchronous errors. In Firefox, it used happen if a site opened an alert() box. This is no longer an issue either, because Firefox now shows javascript alerts within its main window, rather than opening a dialog box. A Lotus Notes client running within wine would also on occasion switch desktops. All 3 could be cured with Focus Stealing Prevention (I had it on "High" for mozilla windows, and "Normal" for all others) I've now set back my focus stealing prevention to None, and will see whether there are still any other misbehaving apps, and will report them here as soon as I see some. 1395753 54 thomas.luebking 2013-09-07 21:06:00 +0000 Not required Happens when a window on a different virtual desktop opens a modal dialog. (Your description sounded like that and "qdbus org.kate-editor.kwrite-24635 /kwrite/MainWindow_1/actions/file_open trigger" easily proved it) No idea why that happens, but it's not correct. The focus is where the mouse is and the mouse is not on the other desktop but in yakuake. The mouse is not even on the kwrite window/dialog afterwards. 1395761 55 thomas.luebking 2013-09-07 21:47:19 +0000 https://git.reviewboard.kde.org/r/112585/ 1395890 56 bkorb 2013-09-08 17:30:54 +0000 ``Summary:do not allow desktop changes for mapping windows and unreasonable focus policies'' ``if (!isOnCurrentDesktop() && options->focusPolicyIsReasonable()) {'' This patch seems a bit judgmental on people's preferences. Any policy that disallows an application from switching desktops from underneath you is, perforce, "unreasonable". It explains why it is so, so difficult to get this bug fixed. 1395900 57 thomas.luebking 2013-09-08 18:01:54 +0000 (In reply to comment #56) > This patch seems a bit judgmental on people's preferences. > Any policy that disallows an application from switching desktops > from underneath you is, perforce, "unreasonable". It explains > why it is so, so difficult to get this bug fixed. First off: this is no way what patch does or says - there's also the "allow" check (which is determined by FSP which are bypassed by the "unreasonable" policies) and this is all *in detail* explained in the review request. Second: this is not related to *this* bug at all, but cooked up by a comment from Alan, who has been - different from other people - very productive and professional on the topic and provided valuable input. Third: If you wish to complain about F(S)UM being tagged as "unreasonable" in the code, please build a time machine and complain to the developer who added/named it so like 8 years ago. There will be no bullshit discussion about whether that's an acceptable function name (read the commit history to figure why the developer than picked that name, i don't care about such the least) and there will be no rename in the KDE4 cycle only to trigger merge conflicts with KDE5 branches. 1396475 58 mgraesslin 2013-09-11 13:47:05 +0000 (In reply to comment #57) > and there will be no > rename in the KDE4 cycle only to trigger merge conflicts with KDE5 branches. and also not in the KDE5 branch. I personally like the name. As a developer one also needs sometimes a little bit of fun and reading code with method names like that just make me smile :-) After all it's just a method name. 1399290 59 thomas.luebking 2013-09-24 19:58:01 +0000 Git commit 07f89501ef738686d1e40297209aa971c667376c by Thomas Lübking. Committed on 07/09/2013 at 21:35. Pushed by luebking into branch 'KDE/4.11'. no VD change for activation & unreasonable policy F(S)UM mean "the focus is where the mouse is" the mouse is not on the other virtual desktop (and it was even granted regardless of the actual geometry/position) The "unreasonable" focus policies expose an issue about the present linked handling of "allow activation" and "allow raising" (see https://git.reviewboard.kde.org/r/110919/ ) Activation would match "extreme" (if the window maps on the same virtual desktop, half a mile away from the mouse, it won't receive the focus) but not regarding raising (which is actually an issue entirely different from FSP) REVIEW: 112585 M +1 -1 kwin/manage.cpp http://commits.kde.org/kde-workspace/07f89501ef738686d1e40297209aa971c667376c 68358 2012-01-31 03:34:47 +0000 2012-01-31 03:34:47 +0000 kwinrc with KDE 4.8.0 kwinrc text/plain 5444 rlk WyRWZXJzaW9uXQp1cGRhdGVfaW5mbz1rd2luLnVwZDprZGUzLjByMSxrd2luLnVwZDprZGUzLjJY aW5lcmFtYSxrd2luX2ZvY3VzMS51cGQ6a3dpbl9mb2N1czEsa3dpbl9mb2N1czIudXBkOmt3aW5f Zm9jdXMyLGt3aW5fb25fb2ZmLnVwZDprd2luX29uX29mZixrd2luM19wbHVnaW4udXBkOmtkZTMu Mixrd2luX2JsYWNrbGlzdC51cGQ6QmxhY2tsaXN0LTQuNSxrd2luX2JsYWNrbGlzdC51cGQ6Qmxh Y2tsaXN0LW9wZW5TVVNFLTExLjQsa3dpbl9ibGFja2xpc3QudXBkOkJsYWNrbGlzdC1vcGVuU1VT RS0xMTQsa3dpbl9yZW1vdmVfZWZmZWN0cy51cGQ6a3dpbjQuN19lZmZlY3RzCgpbQmxhY2tsaXN0 XVtCbHVyXQpBZHZhbmNlZCBNaWNybyBEZXZpY2VzPURSSSBSNjAwOi06Ny44LjEsRFJJIFI2MDA6 LTo3LjguMgpBdGk9UmFkZW9uIEhEIDM2NTA6LTozLjMuOTkwMQpJbnRlbD1NZXNhIERSSSBJbnRl bChSKSA5NDVHTSBHRU0gMjAxMDAzMzAgREVWRUxPUE1FTlQgeDg2L01NWC9TU0UyOi06MS40IE1l c2EgNy4xMCx0cnVlLEdNNDUgRXhwcmVzcyBDaGlwc2V0IEdFTSAyMDEwMDMyODotOjcuOC4yLEdN NDUgRXhwcmVzcyBDaGlwc2V0IEdFTSAyMDA5MTIyMTotOjcuNy4xLDk2NUdNIEdFTSAyMDEwMDMy OCAyMDEwUTE6LTo3LjguMiw5NjVHTSBHRU0gMjAwOTEyMjEgMjAwOVE0Oi06Ny43LjEsSXJvbmxh a2UgTW9iaWxlIEdFTSAyMDEwMDMyODotOjcuOC4yCk5WSURJQT1HZUZvcmNlIDYxNTAvUENJL1NT RTI6LToxOTUKCltCbGFja2xpc3RdW0xhbmN6b3NdCkFkdmFuY2VkIE1pY3JvIERldmljZXM9RFJJ IFI2MDA6LTo3LjguMSxEUkkgUjYwMDotOjcuOC4yCkludGVsPUdNNDUgRXhwcmVzcyBDaGlwc2V0 IEdFTSAyMDEwMDMyODotOjcuOC4yLEdNNDUgRXhwcmVzcyBDaGlwc2V0IEdFTSAyMDA5MTIyMTot OjcuNy4xLDk2NUdNIEdFTSAyMDEwMDMyOCAyMDEwUTE6LTo3LjguMiw5NjVHTSBHRU0gMjAwOTEy MjEgMjAwOVE0Oi06Ny43LjEsSXJvbmxha2UgTW9iaWxlIEdFTSAyMDEwMDMyODotOjcuOC4yCgpb Q29tcG9zaXRpbmddCkFuaW1hdGlvblNwZWVkPTMKQmFja2VuZD1PcGVuR0wKRGlzYWJsZUNoZWNr cz1mYWxzZQpFbmFibGVkPWZhbHNlCkdMRGlyZWN0PXRydWUKR0xMZWdhY3k9ZmFsc2UKR0xNb2Rl PVRGUApHTFRleHR1cmVGaWx0ZXI9MgpHTFZTeW5jPXRydWUKSGlkZGVuUHJldmlld3M9NQpPcGVu R0xJc1Vuc2FmZT1mYWxzZQpVbnJlZGlyZWN0RnVsbHNjcmVlbj10cnVlClhSZW5kZXJTbW9vdGhT Y2FsZT1mYWxzZQoKW0Rlc2t0b3BzXQpOYW1lXzE9Ck5hbWVfMj0KTmFtZV8zPQpOYW1lXzQ9Ck5h bWVfNT0KTmFtZV82PQpOdW1iZXI9NgoKW0VmZmVjdC1Cb3hTd2l0Y2hdClRhYkJveD1mYWxzZQpU YWJCb3hBbHRlcm5hdGl2ZT1mYWxzZQoKW0VmZmVjdC1Db3ZlclN3aXRjaF0KVGFiQm94PWZhbHNl CgpbRWZmZWN0LUN1YmVdCkFuaW1hdGVEZXNrdG9wQ2hhbmdlPWZhbHNlCkJvcmRlckFjdGl2YXRl PTkKQm9yZGVyQWN0aXZhdGVDeWxpbmRlcj05CkJvcmRlckFjdGl2YXRlU3BoZXJlPTkKCltFZmZl Y3QtQ3lsaW5kZXJdCkJvcmRlckFjdGl2YXRlPTkKCltFZmZlY3QtRGVza3RvcEdyaWRdCkJvcmRl ckFjdGl2YXRlPTkKCltFZmZlY3QtRmxpcFN3aXRjaF0KQm9yZGVyQWN0aXZhdGU9OQpCb3JkZXJB Y3RpdmF0ZUFsbD05ClRhYkJveD1mYWxzZQoKW0VmZmVjdC1QcmVzZW50V2luZG93c10KQm9yZGVy QWN0aXZhdGU9OQpCb3JkZXJBY3RpdmF0ZUFsbD03ClRhYkJveD1mYWxzZQoKW0VmZmVjdC1TcGhl cmVdCkJvcmRlckFjdGl2YXRlPTkKCltFbGVjdHJpY0JvcmRlcnNdCkJvdHRvbT1Ob25lCkJvdHRv bUxlZnQ9Tm9uZQpCb3R0b21SaWdodD1Ob25lCkxlZnQ9Tm9uZQpSaWdodD1Ob25lClRvcD1Ob25l ClRvcExlZnQ9Tm9uZQpUb3BSaWdodD1Ob25lCgpbTW91c2VCaW5kaW5nc10KQ29tbWFuZEFjdGl2 ZVRpdGxlYmFyMT1SYWlzZQpDb21tYW5kQWN0aXZlVGl0bGViYXIyPVN0YXJ0IHdpbmRvdyB0YWIg ZHJhZwpDb21tYW5kQWN0aXZlVGl0bGViYXIzPU9wZXJhdGlvbnMgbWVudQpDb21tYW5kQWxsMT1N b3ZlCkNvbW1hbmRBbGwyPVRvZ2dsZSByYWlzZSBhbmQgbG93ZXIKQ29tbWFuZEFsbDM9UmVzaXpl CkNvbW1hbmRBbGxLZXk9QWx0CkNvbW1hbmRBbGxXaGVlbD1Ob3RoaW5nCkNvbW1hbmRJbmFjdGl2 ZVRpdGxlYmFyMT1BY3RpdmF0ZSBhbmQgcmFpc2UKQ29tbWFuZEluYWN0aXZlVGl0bGViYXIyPVN0 YXJ0IHdpbmRvdyB0YWIgZHJhZwpDb21tYW5kSW5hY3RpdmVUaXRsZWJhcjM9T3BlcmF0aW9ucyBt ZW51CkNvbW1hbmRUaXRsZWJhcldoZWVsPU1heGltaXplL1Jlc3RvcmUKQ29tbWFuZFdpbmRvdzE9 QWN0aXZhdGUgYW5kIHBhc3MgY2xpY2sKQ29tbWFuZFdpbmRvdzI9QWN0aXZhdGUgYW5kIHBhc3Mg Y2xpY2sKQ29tbWFuZFdpbmRvdzM9QWN0aXZhdGUgYW5kIHBhc3MgY2xpY2sKQ29tbWFuZFdpbmRv d1doZWVsPVNjcm9sbAoKW1BsdWdpbnNdCmt3aW40X2VmZmVjdF9ibHVyRW5hYmxlZD1mYWxzZQpr d2luNF9lZmZlY3RfYm94c3dpdGNoRW5hYmxlZD10cnVlCmt3aW40X2VmZmVjdF9jb3ZlcnN3aXRj aEVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0X2N1YmVFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVj dF9jdWJlc2xpZGVFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9jeWxpbmRlckVuYWJsZWQ9ZmFs c2UKa3dpbjRfZWZmZWN0X2Rhc2hib2FyZEVuYWJsZWQ9dHJ1ZQprd2luNF9lZmZlY3RfZGVza3Rv cGdyaWRFbmFibGVkPXRydWUKa3dpbjRfZWZmZWN0X2RpYWxvZ3BhcmVudEVuYWJsZWQ9dHJ1ZQpr d2luNF9lZmZlY3RfZGltaW5hY3RpdmVFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9kaW1zY3Jl ZW5FbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9leHBsb3Npb25FbmFibGVkPWZhbHNlCmt3aW40 X2VmZmVjdF9mYWRlRW5hYmxlZD10cnVlCmt3aW40X2VmZmVjdF9mYWRlZGVza3RvcEVuYWJsZWQ9 ZmFsc2UKa3dpbjRfZWZmZWN0X2ZhbGxhcGFydEVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0X2Zs aXBzd2l0Y2hFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9nbGlkZUVuYWJsZWQ9ZmFsc2UKa3dp bjRfZWZmZWN0X2hpZ2hsaWdodHdpbmRvd0VuYWJsZWQ9dHJ1ZQprd2luNF9lZmZlY3RfaW52ZXJ0 RW5hYmxlZD1mYWxzZQprd2luNF9lZmZlY3RfbG9naW5FbmFibGVkPXRydWUKa3dpbjRfZWZmZWN0 X2xvZ291dEVuYWJsZWQ9dHJ1ZQprd2luNF9lZmZlY3RfbG9va2luZ2dsYXNzRW5hYmxlZD1mYWxz ZQprd2luNF9lZmZlY3RfbWFnaWNsYW1wRW5hYmxlZD1mYWxzZQprd2luNF9lZmZlY3RfbWFnbmlm aWVyRW5hYmxlZD1mYWxzZQprd2luNF9lZmZlY3RfbWFrZXRyYW5zcGFyZW50RW5hYmxlZD10cnVl Cmt3aW40X2VmZmVjdF9taW5pbWl6ZWFuaW1hdGlvbkVuYWJsZWQ9dHJ1ZQprd2luNF9lZmZlY3Rf bW91c2VtYXJrRW5hYmxlZD1mYWxzZQprd2luNF9lZmZlY3Rfb3V0bGluZUVuYWJsZWQ9dHJ1ZQpr d2luNF9lZmZlY3RfcHJlc2VudHdpbmRvd3NFbmFibGVkPXRydWUKa3dpbjRfZWZmZWN0X3Jlc2l6 ZUVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0X3NjYWxlaW5FbmFibGVkPWZhbHNlCmt3aW40X2Vm ZmVjdF9zY3JlZW5zaG90RW5hYmxlZD10cnVlCmt3aW40X2VmZmVjdF9zaGVldEVuYWJsZWQ9ZmFs c2UKa3dpbjRfZWZmZWN0X3Nob3dmcHNFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9zaG93cGFp bnRFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF9zbGlkZUVuYWJsZWQ9dHJ1ZQprd2luNF9lZmZl Y3Rfc2xpZGViYWNrRW5hYmxlZD1mYWxzZQprd2luNF9lZmZlY3Rfc2xpZGluZ3BvcHVwc0VuYWJs ZWQ9dHJ1ZQprd2luNF9lZmZlY3Rfc25hcGhlbHBlckVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0 X3NwaGVyZUVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0X3N0YXJ0dXBmZWVkYmFja0VuYWJsZWQ9 dHJ1ZQprd2luNF9lZmZlY3RfdGFza2JhcnRodW1ibmFpbEVuYWJsZWQ9dHJ1ZQprd2luNF9lZmZl Y3RfdGh1bWJuYWlsYXNpZGVFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF90cmFja21vdXNlRW5h YmxlZD1mYWxzZQprd2luNF9lZmZlY3RfdHJhbnNsdWNlbmN5RW5hYmxlZD10cnVlCmt3aW40X2Vm ZmVjdF93aW5kb3dnZW9tZXRyeUVuYWJsZWQ9ZmFsc2UKa3dpbjRfZWZmZWN0X3dvYmJseXdpbmRv d3NFbmFibGVkPWZhbHNlCmt3aW40X2VmZmVjdF96b29tRW5hYmxlZD10cnVlCgpbUG9wdXBJbmZv XQpQb3B1cEhpZGVEZWxheT0xMDAwClNob3dQb3B1cD1mYWxzZQpUZXh0T25seT1mYWxzZQoKW1N0 eWxlXQpCb3JkZXJTaXplPTEKQnV0dG9uc09uTGVmdD1NUwpCdXR0b25zT25SaWdodD1ISUFfX1gK Q3VzdG9tQnV0dG9uUG9zaXRpb25zPWZhbHNlClBsdWdpbkxpYj1rd2luM19veHlnZW4KU2hvd1Rv b2xUaXBzPXRydWUKCltUYWJCb3hdCkxheW91dE5hbWU9dGh1bWJuYWlscwpMaXN0TW9kZT0wClNo b3dUYWJCb3g9dHJ1ZQoKW1dpbmRvd3NdCkFjdGl2ZU1vdXNlU2NyZWVuPXRydWUKQXV0b1JhaXNl PWZhbHNlCkF1dG9SYWlzZUludGVydmFsPTc1MApBdXRvZ3JvdXBJbkZvcmVncm91bmQ9dHJ1ZQpB dXRvZ3JvdXBTaW1pbGFyV2luZG93cz1mYWxzZQpCb3JkZXJTbmFwWm9uZT0xMApDZW50ZXJTbmFw Wm9uZT0wCkNsaWNrUmFpc2U9ZmFsc2UKRGVsYXlGb2N1cz1mYWxzZQpEZWxheUZvY3VzSW50ZXJ2 YWw9MApFbGVjdHJpY0JvcmRlckNvb2xkb3duPTc1MApFbGVjdHJpY0JvcmRlckRlbGF5PTUwMApF bGVjdHJpY0JvcmRlck1heGltaXplPWZhbHNlCkVsZWN0cmljQm9yZGVyVGlsaW5nPWZhbHNlCkVs ZWN0cmljQm9yZGVycz0xCkZvY3VzUG9saWN5PUZvY3VzRm9sbG93c01vdXNlCkZvY3VzU3RlYWxp bmdQcmV2ZW50aW9uTGV2ZWw9MwpHZW9tZXRyeVRpcD1mYWxzZQpIaWRlVXRpbGl0eVdpbmRvd3NG b3JJbmFjdGl2ZT10cnVlCkluYWN0aXZlVGFic1NraXBUYXNrYmFyPWZhbHNlCk1heGltaXplQnV0 dG9uTGVmdENsaWNrQ29tbWFuZD1NYXhpbWl6ZQpNYXhpbWl6ZUJ1dHRvbk1pZGRsZUNsaWNrQ29t bWFuZD1NYXhpbWl6ZSAodmVydGljYWwgb25seSkKTWF4aW1pemVCdXR0b25SaWdodENsaWNrQ29t bWFuZD1NYXhpbWl6ZSAoaG9yaXpvbnRhbCBvbmx5KQpNb3ZlTW9kZT1PcGFxdWUKTW92ZVJlc2l6 ZU1heGltaXplZFdpbmRvd3M9ZmFsc2UKTmV4dEZvY3VzUHJlZmVyc01vdXNlPXRydWUKUGxhY2Vt ZW50PVNtYXJ0ClJlc2l6ZU1vZGU9T3BhcXVlClJvbGxPdmVyRGVza3RvcHM9dHJ1ZQpTZXBhcmF0 ZVNjcmVlbkZvY3VzPWZhbHNlClNoYWRlSG92ZXI9ZmFsc2UKU2hhZGVIb3ZlckludGVydmFsPTI1 MApTbmFwT25seVdoZW5PdmVybGFwcGluZz1mYWxzZQpUaWxpbmdEZWZhdWx0TGF5b3V0PTAKVGls aW5nT249ZmFsc2UKVGlsaW5nUmFpc2VQb2xpY3k9MApUaXRsZWJhckRvdWJsZUNsaWNrQ29tbWFu ZD1NYXhpbWl6ZQpXaW5kb3dTbmFwWm9uZT0xMAo=