Pablo Sanchez posted on Thu, 09 May 2013 09:52:56 -0400 as excerpted: > [ Comments below, in-line ] > > On 05/09/2013 09:50 AM, Duncan wrote: >> Duncan posted on Thu, 09 May 2013 06:06:12 +0000 as excerpted: >> >>> Now I just have to permanently mount the hardware, and reconfigure >>> plasma and superkaramba and all my kwin hard-positioning rules... >>> which will take some time and patience, but shouldn't be too terrible. >> >> I just finished superkaramba and plasma, and wow, I hadn't realized >> just how geeked out it'd look until now. > > Screen shot!!! :) > > I've been using conky and gkrellm forever but perhaps `change is in the > air'
OK, these are full resolution, full-color pngs. Since I'm running three stacked full-hd monitors, that's 1920x3240 resolution for the full-screen (4.6 MB), (almost) the same width but a third the height for superkaramba- only image. Viewing in a browser that allows toggling between full-size and fit-to-window is recommended. (Semi-NSFW warning on the full-screen. Bikini-clad firefox skin that I forgot about until after the snap. The superkaramba-only version is safe, however.) Full-screen: http://wstaw.org/m/2013/05/11/duncan-fullscreen.png Some things can be noted here. 1) As I mentioned earlier the top monitor's only 1/4 the size (1/2 in either direction) but the same resolution. Modern xorg uses standard 96dpi (I believe the same as MS Windows and/or Apple OSX, but I've not done servantware in years so wouldn't know from experience), so the fonts come out way tiny. I'm in my 40s and part of the reason for the bigger main displays was to avoid having to wear reading glasses (or using kwin's zoom effect, as I was doing previously) all the time when I'm working at the computer. So I bumped the superkaramba font size WAY up (36 for the readouts, 32 for the log) to compensate for the smaller monitor. That's why it's so much bigger than the working window fonts. 2) The other two (almost) full-screen-maximized (1/3 desktop) apps are pan, the gtk-based news-client and what I use for this list, fetched as a newsgroup via gmane.org's list2news service, and (titlebar/border-less) claws-mail in feed-reading mode. 3) The reason they're /almost/ full-screen is because I have kwin window rules setup to make them that way. The reason for that can be seen with the (half-screen-tiled) firefox window I have open as well, behind claws- mail, but titlebar still exposed due to the /almost/ full-screen claws. That allows easy switching back and forth between them, with focus- follows-mouse and click-to-raise. 4) Window translucency is also evident. This has been a critical part of my workflow management since kde3; I didn't realize just HOW critical until I had problems with it in early kde4 (4.2/early-4.3 era) due to bugs that were later fixed. It's not fully evident here due to the green of the feed listings, but the translucency is set so under the right conditions I can read reference material in an on-top-but-unfocused window while typing into the focused and also readable window below it. 5) Before someone asks, the middle and bottom screen backgrounds are stock plasma-pod (picture-of-the-day) plugins, the middle one being fpod (flickr-pod), the bottom epod (earth-science-pod). epod has a new image daily, fpod has several rotating images available each day, so if you don't like one, restart plasma or switch to something else and back to fpod, and it'll pick one of the others. The top one is a random image I came across on the net, possibly from the 17-gig myspace images archive someone torrented a few years ago (while myspace was still at perhaps 80% of its peak popularity). The copy I have is only 388x273, but it scales reasonably nicely... The firefox skin is TORI PRAVER SWIMWEAR, by SaSSyGirL, available from the main firefox skins site. The kde color scheme is modified from darkblue-deb from kde-look. 6) My only panel, small and auto-hide, can be seen at the bottom left. The plasmoids are kickoff (which I don't use much as I have hotkey launching configured for everything I use regularly, and use krunner most of the rest of the time), kde-classic-launcher set to bookmarks (which I use a LOT), quick-access, from kde-look, set to open to the desktop dir, which in turn includes a symlink to a "dir" dir, with symlinks to various filesystem locations in the rest of the system, thus allowing me to browse to pretty much anywhere with fewer clicks than I'd otherwise require, and of course systray. The icons in systray are of course the notifier, pan, superkaramba, claws- mail (mail-mode instance), claws-mail (different icon theme, feeds mode instance, yes, I run two separate instances as I don't like mail and feeds combined in the same instance), qtmpc (=qt-music-player-client, an mpd frontend, mpd=music-player-daemon), klipper, kmix. I prefer to have all systray icons shown, so that's everything running in the tray. Superkaramba-only: http://wstaw.org/m/2013/05/11/duncan-superkaramba.png The first six graphs are per-core CPU activity (6-core AMD fx6100). Top/cyan: user% 2nd/purple: system% 3rd/green: nice% 4th/red-orange: I/O-wait% 5th/yellow: total core usage, % 6th/white: current frequency, MHz (1.4 GHz, full=3.6 GHz) Superkaramba has native sensors for most of the percentages but is missing i/o-wait. I created a patch to add it, filed as kde bug #274906, but unfortunately I've not had a peep from any kde dev since it was filed in 2011, so it's still not in the shipped product. https://bugs.kde.org/show_bug.cgi?id=274906 Of course gentooers can simply drop that patch in /etc/portage/patches/ kde-base/superkaramba/ (with a .patch extension) and all further superkaramba updates will automatically include it. The frequency is pulled using grep/sed from the appropriate /sys/ file. (The i/o-wait can be pulled from the appropriate procfs file via grep/sed instead of using the patch I use, but of course that's far higher overhead as it's extra applications that must run at every update, with a 1 second update time here, so dropping that overhead via that patch is definitely worth it!) Seventh is the memory activity graph, reporting MB used: Top/cyan: application 2nd/purple: buffer 3rd/green: cache 4th/red-orange: total physical used (~2.6 gig) 5th/yellow: total physical memory (16 gig) 6th/white: swap used (obviously zero here) Again, I'm using a superkaramba patch for buffers and cache. kde bug #275070: https://bugs.kde.org/show_bug.cgi?id=275070 Eighth is system power/voltage/fans: Top/cyan: volts-core (hundredths-volt so 0.86) 2nd/purple: volts-mem 3rd/green: fan-cpu (rpm) 4th/red-orange: fan-rear 5th/yellow: power-cpu (watts) 6th/white: load-average (1 minute, hundredths) Some of these used the build-in superkaramba sensors, some are grep/sed- ed from the (lm-)sensors command-line output or sysfs/procfs. Nineth is unused ATM. Tenth is system temps (C): Top/cyan: cpu (cpu-reported, a relative number not an actual temp for amd fam10+) 2nd/purple: southbridge 3rd/green: northbridge 4th/red-orange: cpu-socket (chipset reported) 5th/yellow: gpu 6th/white: hard drive (/dev/sda, thus the "a") Following that, eleventh and twelfth, are double-stacked net activity, graphing both up and down and labeled with bits/bytes per second, each one maxing at eight times the previous one. These are superkaramba native sensors. Finally, the double-width "time and top" text-readout: Top/cyan, local time (24-hour with seconds) 2nd/yellow, date (weekday, mm,dd) 3rd/yellow, time UTC (dd, 24-hour to minute) 4th/yellow, time last distro tree sync (the partition's unmounted, so blank, dd 24h to minute) 5th/yellow, time boot (dd, 24h to minute) Next six lines, top six CPU using apps, percentage CPU (ps -Ao pcpu,comm piped to suitably process the output). Bottom three lines, top three memory using apps, percentage memory (ps - Ao pmem,comm, piped...) Then below that, across the full screen in green, are the last 19 lines from /var/log/messages. If anyone's interested, I can post the superkaramba theme file. Obviously some bits (the number of CPU cores, fan/voltage/power/temps sensors, etc) will need reconfigured per-system, and those using a superkaramba without my patches will either need to turn off that functionality or use the higher overhead grep/sed-the-appropriate-files/ commands method. Similarly, logging functionality differs per distro and often will require passwordless sudo access configured for whatever command is used to tail the log due to permissions issues, so that'll need customized. But it'd still be a great example and a good head start at your own superkaramba theme file. =:^) Meanwhile, one final link, to the kde techbase superkaramba theme configuration documentation: http://techbase.kde.org/Development/Tutorials/SuperKaramba -- 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.
