Has KDE 4 caught up with KDE 3 yet?

Posted Apr 17, 2010 12:17 UTC (Sat) by nix (subscriber, #2304)
In reply to: Has KDE 4 caught up with KDE 3 yet? by wstephenson
Parent article: Aaron Seigo on the Future of KDE (Datamation)

The missing functions, in brief:

- Starting with the minor stuff, I'm used to being able to run programs on the root window, or at least display their output there. Can't do that in KDE4. Thanks to a comment here yesterday I now know I have to do some plasma hacking to fix this, which should be fun. :)

- In fvwm+KDE3, I have bound virtually everything to keys (so maximize vertically and horizontally are on different keys). I have several hundred keybindings at this point, but I don't have several hundred keys. So I use key sequences heavily. These appear to have disappeared from KDE4, with no replacement.

- For that matter, khotkeys in KDE4 apparently only allows access to wm functions available over dbus. Virtually nothing related to specific windows appears to be available over dbus. Maybe I just haven't found it, but I'd have expected binding 'maximize this window' to a key to be obvious!

- In fvwm, I use layering and matching to customized window classes to have a set of borderless, titlebarless procmeters displaying a dozen critical stats on different machines down the right-hand-side of the screen. The rightmost of all fills most of the RHS, is at the same layer as everything else, and is the procmeter for the local machine: as it is on the same layer, maximizing windows butts up against this procmeter and does not occlude it. The others are at a higher/lower layer (switchable with a hotkey, hyper-=/hyper-+, where hyper is PrtSc and flips on the mod5 bit). The effect is that with one keystroke I can cause all but the local-system procmeters (and the xdaliclock and pager) to vanish beneath the active window, or reappear again.

(Screenshot, with procmeters in raised position: <http://www.esperi.org.uk/~nix/temporary/procmeter-configu...>)

I've been using procmeters arrayed like this for nearly fifteen years now: if they're not running, I feel almost like the machines have suddenly gone opaque on me. With them there, I can feel the pulse of the machine: because procmeter doesn't normally fork, I can even spot it and guess what's wrong when fork() has started to fail!

In fvwm2 this is about ten lines, no matter how many procmeters happen to be present, plus a -name parameter to give the rightmost procmeter a class other than 'ProcMeter3':

# Flip procmeters to the background
AddToFunc "BegoneProcmeter" "I" All (ProcMeter3, Layer 6) Layer 0 2
+ "I" All (XDaliClock, Layer 6) Layer 0 2
+ "I" All (ProcRightmost, Layer 5) Layer 0 3
+ "I" All (FvwmPager) Layer 0 2

# Flip them back into the foreground again
AddToFunc "ReturnProcmeter" "I" All (ProcMeter3, Layer 2) Layer 0 6
+ "I" All (XDaliClock, Layer 2) Layer 0 6
+ "I" All (ProcMeter3, Layer 3) Layer 0 5
+ "I" All (FvwmPager) Layer default
+ "I" All (FvwmPager) Lower

Key KP_Subtract A 5 BegoneProcmeter
Key equal A 5 ReturnProcmeter

Key KP_Begin A S5 Maximize 100 100

In KWin, it appears to be impossible to do *any* of this. There's no layer management, no binding of raise/lower to keys, no *nothing*. Plasmoids plainly can't do it because they're nailed to the desktop background, while these procmeters spend most of their time raised *above* the active window.

What am I missing? Is there some secret scripting engine I'd missed? 'cos this is really not a lot to demand of a window manager (fvwm 1 could do it way back in 1995, although there were no layers back then so I had to use raise/lower), and if KWin can't even do this I suspect it's not for me.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 17, 2010 23:04 UTC (Sat) by nybble41 (subscriber, #55106) [Link]

I'm not sure how one would go about maximizing a window under KWin via DBUS, but you can do it easily under a variety of EWMH-compliant window-managers (including KWin and FVWM) with wmctrl <http://tripie.sweb.cz/utils/wmctrl/>:

wmctrl -i -r 0x04000016 -b add,maximized_vert,maximized_horz

In addition to the window ID (-i), as shown above, you can also select the target window by WM_CLASS (-x) or title (default). You can also control other flags, such as 'sticky', 'above', 'shaded' and 'hidden', move and resize windows, switch virtual desktops, and change the focus.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 19, 2010 20:31 UTC (Mon) by rfunk (subscriber, #4054) [Link] (17 responses)

Regarding your ProcMeter issue, I use the System Load Viewer plasmoid to keep tabs on the pulse of the machine. It's not as detailed as your Procmeter setup, but I'm pretty sure there are other plasmoids that give more detail.

In KDE4 you just have to start thinking in high-level terms of plasmoids and widgets, rather than in low-level terms of borderless windows.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 19, 2010 21:38 UTC (Mon) by nix (subscriber, #2304) [Link] (7 responses)

Well, yeah, but plasmoids can't give you info on remote machines (you can't ssh to another machine and run a plasmoid there), and as I mentioned, plasmoids are nailed to the desktop background, which is completely useless if you want them to float above your windows most of the time. :/

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 19, 2010 21:52 UTC (Mon) by rfunk (subscriber, #4054) [Link] (6 responses)

A plasmoid can do anything any other program can do. Your plasmoid can be written to ask another machine for its stats.

And in fact plasmoids now seem to get cross network capability ("share this widget on the network") automatically. I haven't tried it and don't know the details of it though.

And they're only nailed to the desktop background if that's where you put them. They can also be on a transparent panel if you like.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 19, 2010 22:10 UTC (Mon) by nix (subscriber, #2304) [Link] (5 responses)

Aha! So all I need is a way to have a triple-width vertical panel with three plasmoids on it, and, er, it still doesn't work because they can't adjust their depth independently because they're nested on a single entity at the side of the screen. (And it's not as if I can use one panel on each side of the screen, because the whole point of this is that stuff overlapping your window on the right hand side is often not obscuring anything important. On the left, it's quite different. Also, they should be next to each other for visual-comparison's sake.)

Gah.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 16:50 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (4 responses)

While I'm unsure plasmoids can do all you want, they CAN run in a separate window if you like. Furthermore, KWin has a pretty powerful custom configuration. It does not work on non-window items like plasmoids on the desktop but it DOES work on plasmoids in a window - though I'm unsure if they are identified properly for you to do what you want.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 22:54 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

It looks like plasmoids in a window and the ability to position them precisely and hotkey-control their raising/lowering would do the trick. Unfortunately the latter still seems undoable, and if all the plasmoids have the same window class and name (as it appears they do), I don't see how KWin can distinguish between them to nail them in the right places. (But maybe it doesn't need to. I'll give it a try this weekend.)

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 24, 2010 8:48 UTC (Sat) by jospoortvliet (guest, #33164) [Link] (2 responses)

You might be completely right. However, fixing the window class and name issue might be pretty doable, and adding the needed hotkey capabilities to kwin might also be possible.

Another thing, as I'm behind a plasma desktop now I can check out a few things, so let me do that.

I don't know what you need exactly, but under the global keyboard shortcuts (kwin) I see a lot of shortcuts. you can also give individual windows a shortcut and configure their options under 'right mouseclick on decoration > advanced'. Combined, does that bring you what you need?

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 24, 2010 9:42 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

Oh, I'm sure it's possible. It's just not *there*. :/

Ah well, the kde devs are not telepaths and I'd never mentioned any of this before. I'll repost it on the kde@ list shortly.

Combined and window shortcuts would let me switch focus to the window on a keystroke. These windows contain nothing but procmeters that don't respond to keystrokes, so giving them the focus is a waste of time; and it raises the window but does not lower it. also, the 'maximize does not cover the outermost procmeter' still isn't satisfied :/

gah. this took *five minutes* with fvwm2.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 24, 2010 10:06 UTC (Sat) by jospoortvliet (guest, #33164) [Link]

Well, I'm assuming you've seen all the capabilities of Kwin by now (I did find shortcuts to lower an active window but that's not what you need either is it?) so yes, I guess this simply isn't there. I wish you luck finding a dev interested in writing these features (or figuring out how to do it yourself).

Cheers and enjoy the weather :D

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 16:20 UTC (Fri) by jschrod (subscriber, #1646) [Link] (8 responses)

AFAIU, all plasmoids run in the same process. The "low-level term" of borderless windows has the BIG advantage that one of them crashing won't bring down my whole desktop. Processes were invented for a reason...

While Web browser rightily start to use more processes to shield windows or tabs from each other, KDE starts to integrate everything and its darling into one big giantic mess, able to overwrite memory of each other's plasmoids at will.

And this is called a Good Design(tm) nowadays. I'm getting old.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 16:52 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (4 responses)

on the other hand, having 20+ processes (a number of plasmoids which is conservative on many setups) will eat memory like crazy. I'd rather have them in one multi-threaded process. Plasmoids should become more and more scripted (ECMA, python, ruby, etc) in the future and only the core plasmoids will be C++. And should obviously be as much stabilized and tested as possible...

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 17:37 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

if they are well written to begin with they should not eat significantly more memory when run as separate processes then when running on one giant process.

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 24, 2010 8:44 UTC (Sat) by jospoortvliet (guest, #33164) [Link] (2 responses)

As I'm not a developer, I can't really argue this. The only thing I know is that the plasma devs told me that running each plasma widget (panels, background and every widget on them) in a separate process would eat memory like crazy and introduce a lot of overhead in synchronizing things. The latter has to do with the synchronizing of animations they do and saving power as well - events are gobbled up and fired at certain intervals to wake up the proc as little as possible, saving power on battery. This is hard if not impossible when running in separate processes, where all the separate plasmoids would wake up the proc at different points in time preventing it from sleeping or clocking down.

I greatly respect the core plasma hackers and I'm sure the situation might be more complex than you think...

Has KDE 4 caught up with KDE 3 yet?

Posted May 3, 2010 19:21 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

with the linux COW feature, they won't use much more memory.

synchronization would be an issue, but how close does the animation of different things need to be synced? and why? In anycase, this is what Futex are good for.

wakeups can be batched by the OS (there have been some articles on this recently)

I suspect that the core plasma hackers are focused so tightly on their use-case and world that they are missing the other advantages.

putting everything in one process is great for some things, but it makes things very fragile as there are a LOT of ways for things to go wrong.

Has KDE 4 caught up with KDE 3 yet?

Posted May 3, 2010 20:22 UTC (Mon) by jospoortvliet (guest, #33164) [Link]

Hmmm... I'm unsure if the reasons behind the one-process thing have been documented somewhere, couldn't find something quickly. If you want you could ask on #plasma (freenode) and see if anyone knows - maybe there are indeed possibilities and if you can argue a good case I'm sure the plasma devs would listen... I suspect it wouldn't even be that hard to write a proof-of-concept, and for that I'm SURE the devs would support you...

Again, I can't really argue about this, but I certainly would appreciate a more stable Plasma so if you could find it in your hart to put in the effort to make it possible, my blessing is yours ;-)

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 23, 2010 22:52 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

And in KDE4 *Konsole* does that as well. Unless you specifically demand otherwise *all your Konsoles run in the same process*, to facilitate dragging tabs between konsoles.

Whoever thought this was a better idea than having each tab a separate process and the containing window another one was an absolute maniac. It is evident to everyone (other than, apparently, the Konsole authors) that you do not want *every shell you own* to implode *simultaneously* if Konsole has a bug...

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 25, 2010 14:22 UTC (Sun) by halla (subscriber, #14185) [Link] (1 responses)

How is calling the konsole authors "absolute maniacs" "polite, respectful and informative"?

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 25, 2010 15:32 UTC (Sun) by nix (subscriber, #2304) [Link]

Perhaps it was somewhat hyperbolic :) still, it's a pretty accurate reflection of what everyone I have discussed this with has said; generally it starts with 'they did *what*? Why would anyone ever consider that a good idea?' and segues into a desire to not have anything to do with KDE ever again: I am generally able to deflect this by mentioning the existence of --no-fork and konsole replacements... Why is --no-fork not the default, anyway?

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 28, 2010 10:50 UTC (Wed) by daenzer (subscriber, #7050) [Link] (1 responses)

> I'm used to being able to run programs on the root window, or at least
> display their output there. Can't do that in KDE4. Thanks to a comment
> here yesterday I now know I have to do some plasma hacking to fix this,
> which should be fun. :)

FWIW, you can't do that with compositing anyway, as the root window contents are clobbered by the compositing manager.

P.S. I couldn't live without my gkrellm any more than you could without your procmeters. :)

Has KDE 4 caught up with KDE 3 yet?

Posted Apr 28, 2010 12:00 UTC (Wed) by nix (subscriber, #2304) [Link]

I tried gkrellm years ago but it just looked... wrong, and at the time running lots of them on remote machines was tricky for reasons I forget. I should try again someday; it's much more flexible than procmeter.

(Now back to trying to figure out why X crashes and wrecks my console on exit in 2.6.33/4 but not in 2.6.32 :/ gah. Bugs, bugs, all around me bugs...)