[kde-linux] kwin needs 300M?

[Duncan]

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