Dale posted on Tue, 22 Nov 2011 06:14:14 -0600 as excerpted: > Alex Schuster wrote: >> Dale writes: >> >>> Jerome Yuzyk wrote:
>>>> kwin --replace & >>>> >>>> It tells kwin to replace itself with itself. Works for me, the screen >>>> refreshes and panels reload and a couple apps were un-minimized but >>>> memory dropped instantly and it's a lot easier than logging out and >>>> in. >> Wow, that's great! I just hate to log out and restart all my stuff that >> was running. Thanks! >> >>> When I did this, it went all wonky. I went from 8 desktops to one and >>> all my apps went to the one desktop. Other than all that, it worked >>> fine. LOL >>> >>> Now to logout and back in again to fix all this. :/ >> Wow, that's bad! I just hate to fix things like this. That's why I back >> up my .kde directory so often. > If you try this, just try it at a point where you won't lose anything. > That said, everything worked but it was just a single desktop, like > winders has. Ewwwww!! After I logged back in, it went back to normal. > Well, one of the settings changed on my taskbar but I fixed it. > Just wanted to give a heads up that this may not work for everyone. By > the way, I'm on Gentoo with KDE 4.7.3. FWIW... everything collapsing onto a single desktop would be expected, as the window-manager that was tracking all that data just got replaced! =:^( I've not used the --replace trick, but I've used... killall kwin; sleep 2; kwin & ... which does basically the same thing, except leaving the desktop without a window-manager at all for a couple seconds. All the window borders are lost as well, plus always-on-top and no-border and similar settings. Then when kwin restarts, the windows get their borders back and of you have window rules, they get re-enforced, so my window rule that sets pan (which I use for this list and keep open all the time on a dedicated news desktop) to its own desktop returns it to desktop 3, where the window rules says it goes. But all of the "volatile" state disappears, so stuff like always-on-top and no-border windows that were set manually, not enforced by window rules, gets reset to normal. And all windows that aren't set to a specific desktop by window rules remain on the single desktop that the new kwin found them on when it started. So as I said above, nothing that's not expected by loss of all that state that the window manager was tracking when you replaced it. =:^) It's still better than the whole system crashing down unexpectedly, or even than kwin crashing on its own and not restarting, both of which I used to see occasionally, back when I was seeing a similar memory leak in kwin. And if like me you have wheel-scroll events on titlebars set to move the window to other desktops, and wheel-scroll events on the bare desktop set to switch desktops (without moving the windows), it's easy enough to hover-and-wheel them back into place. And the app I normally run borderless (it's actually a window rule but only set to apply initially, not force, so when kwin comes up and the window's already running it doesn't apply the rule since the window didn't just appear, kwin did) is easy enough to switch back to borderless, since I have a hotkey setup to toggle that, as well. Still, if you weren't expecting it and didn't realized that was the normal effect of loss of window manager state when it was replaced, yeah, all that could be disturbing and confusing, and cause one to reboot even if it's no big deal, just due to the confusion. But once you're expecting it and know why it happens, it's not such a big deal any more. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
