Alex Schuster posted on Fri, 29 Oct 2010 21:12:31 +0200 as excerpted:
> I'm also having plasma trouble. Plasmoids tend to not remember their
> position and sizes, expecially folder plasmoids, but that's a minor
> problem. What causes much more trouble is that my activities get mixed
> up. I have one activity per desktop, and suddenly most desktops have the
> wrong activity. This has happened for 3-4 times now.
Yeah, that sounds like the same general issue..
One thing I understand from following planet-kde for awhile (I quit as
there wasn't so much stuff I was /really/ interested in and I have way
more feeds in akregator than I can keep up with as it is, and it was one
of the easiest for me to drop since I'm /not/ so interested in much of the
content), as well as following quite well the general FLOSS community
news, is that...
Plasma is still *VERY* *MUCH* a work in extremely active development.
Actually, while I understand reasonably well where they're trying to take
it, and why (based on what asegio etc have written), if you look back at
early kde4, the plasma interface was the big part of caused 4.0-4.2 to be
panned as badly as they were -- the rest of kde was at least /reasonably/
stable, but the desktop, panel and launcher services plasma provides are
EXTREMELY critical to a good GUI experience, and plasma simply wasn't yet
even beta quality with 4.2, let alone functional, polished and stable
enough to be rated the release quality that they were claiming as of 4.2
for kde4 in general. As a result, the unstable plasma ended up dragging
the reputation of all of kde4 thru the mud. Had it been anything /other/
than plasma, it wouldn't have been so bad, but as I said, the services
plasma provides are by very definition, absolutely critical to a
reasonable desktop experience.
Anyway... With 4.4 things were finally looking reasonably functional and
non-crashy on the plasma front, enough that with it, I finally considered
kde4 "release candidate" quality -- generally good enough to release, but
with a few niggling bugs that at least the engineering side would normally
want to get rid of before release.
In that regard, 4.5 did finally make what I'd consider release quality --
what really /should/ have been 4.0. But, as with any .0 release, there's
still improvements to be made, even if it's finally release quality...
Which brings us back to the topic at hand. As you likely recall, the
activity interface in 4.4 and previous was the zooming interface. But
that absolutely went over like a lead balloon in much of the community,
and the plasma folks ended up changing it. As it happens (or not, IMO
it's causatively connected), that's the same version that I finally
considered release-grade (it's causatively connected in that that change
was part of the /reason/ it finally felt to me like release grade, the
interface finally worked reasonably).
But, as with any such changes made that late in the cycle, between (should-
have-been) rc and final .0 release, the initial release version is often a
big buggy, and ultimately, a .1 release (or SP1) is needed to bring the
implementation in line with the vision for it.
Well, using kde4's actual versioning, that .1 release will be 4.6... and
based on the kde4 history so far, I can quite confidently predict that it
should be MARKEDLY better than 4.5, even if I'm /not/ following kde-planet
and therefore asegio's blog (in particular for plasma) as closely as I was.
What I think happened, then, is that they rather obviously screwed
something up in the switch from the activity zooming to the activity
scrolling interface. Least-wise, I don't recall this complaint appearing
anywhere, and I certainly never experienced the issue, with the zooming
interface, which by 4.4 was reasonably mature, stable and functional, even
if few actually found it as natural to work with as 4.5's activity
browsing interface.
BTW, I don't use the activity per desktop option, but IIRC it only
appeared in 4.4 or 4.5 as well, so its implementation probably isn't quite
stable yet, either. Also, while they've added it by popular demand, it
doesn't fit well the activity concept the plasma devs have, so they don't
tend to use it themselves, and it likely gets rather less testing than
desktop-unlocked activities as a result. That might be part of what
you're seeing if you're using the option.
> I [started from a clean config] some months ago, hoping that those many,
> many bugs are the result of some configs that got corrupted along the
> updates from KDE 4.2 to 4.3, 4.4 and 4.5. Some things were fixed indeed,
? but most problems stayed. This took half a day of work, so I'd hate to
> do this again whenever a KDE problem arises.
[mode=aol] As I made plain in the upstream posts, me too! [/mode]
> Maybe my setup is just over-complicated? When I look at screenshots of
> people using KDE4, they often only have two desktops. Well, I have eight
> desktops and activities, in case someone is interested, there are some
> screnshots here:
> http://www.wonkology.org/comp/desktop/2010-06-19/
>
> The current setup is a little different, but not much.
Wow! While your customization is rather different than mine, it's
certainly as customized. OTOH, you mention below that you're a Gentoo user
too, and Gentoo's known for the customization options it offers, so that
isn't /so/ surprising, I guess. =:^)
FWIW, it's rather old (4.2 era, when I was switching from kde3 to kde4 and
still had elements of both installed and running, together), but I still
use a generally similar arrangement to the one in the screen shot here:
http://members.cox.net/pu61ic.1inux.dunc4n/
I still have dual monitors in stacked config, tho I'm now running slightly
shorter ones, standard US 1080p HD, so the overall resolution is 1920x2160.
Likely as a result of the additional screen space the dual monitors gives
me, I don't actually use as many desktops as I might. I only use three,
and only have a single "activity"... tho due to the way plasma worked
pre-4.5 each monitor formerly displayed a different "activity", but the
two formed a single desktop. 4.5 has changed that somewhat and it's clear
that the intent is to have the whole desktop be the activity, even if each
monitor has its own separately configured background, but again, it's
clearly a WIP (work in progress), which sort of works, but I expect will
be MUCH more polished and functional in 4.6 (what arguably should have
been kde4's .1 release, by traditional measures).
I still have the big panel at the top, now all plasma, of course, with the
system activity graphs that were provided in the screenshot by kicker's
ksysguard applet now provided by the yasp-scripted (yasp=yet-another-
systemmonitor-plasmoid) plasmoid off of kdelook.org, since there appears
to be no proper ksysguard plasmoid to replace kde3's kicker applet. In
addition to the several yasp-scripted sysmon plasmoid instances (including
one tailing syslog), this panel also includes the systray.
Instead of the full-width bottom panel, since knewsticker was discontinued
(I still miss it) and I now use akregator for my feeds, I've only a very
short bottom-left panel set to auto-hide, with kickoff (which I don't use
much as all my regular apps are hotkey-launched) and a classic menu with
bookmarks and kcontrol menus, as the only plasmoids.
I have a digital clock displayed in one of my yasp-scripted instances, but
on the desktop, top monitor, I have a big analog clock plasmoid as well,
plus a narrow folderview to the left, a couple quick-access plasmoids
(kdelook), and yawp. The top monitor is still "auxiliary/overflow" usage,
since the usable area is smaller due to the sysmon panel taking up the top
third. As a result, the desktop is usually exposed enough so I can access
it without too much trouble, and the plasmoids I have there are thus
reasonably utilitarian (mainly filesystem access) in nature. I have the
over-desktop mouse-scroll function set to switch desktops, which is quite
convenient, since as I mentioned, the top monitor desktop is generally at
least partially exposed.
ON the desktop, bottom monitor, I have only a single plasmoid, the comic-
strip plasmoid you too mention. This is because the bottom monitor is my
"working" monitor, and I tend to have it covered by windows most of the
time. Since few comics update more frequently than daily, once I've seen
my comics for the day, I'm done, so covering it isn't a big deal.
Window-placement-wise, I REALLY like the drag-to-side-half-maximize (to
monitor, so it stays in the active monitor not over both) feature that
appeared in 4.4 and use it a LOT! (OTOH, on a dual-monitor stacked config,
the drag-to-top-to-maximize functionality is annoying, since it triggers
when dragging to the top of the BOTTOM screen too, and that's the MIDDLE
of the desktop. So that option's turned off.) My normal config (with
kiwn's customized window-rules applied to help) runs both konsole and
konqueror (my default browser, tho I use firefox as well) half-maximized,
so I get two instances side-by-side.
Kmail, akregator and pan (USENET/news client, about the only gtk app I run
other than firefox) run almost-maximized in the bottom monitor, with pan
getting its own dedicated "news" desktop. (As I mentioned above, I only
run three desktops, pan on one, and two others so I can have whatever
project open on one and still have the other for a second project or as a
free/overflow desktop.)
I say "almost-maximized", because I use custom kwin window rules to keep
those apps a title-bar's height shorter than full maximized. That way, I
can run a half-maxed browser/konsole/whatever on the same bottom monitor
and still conveniently click-raise either the almost-maximized app or the
other one, without trouble (focus follows mouse policy, click-to-raise,
additionally, window transparency allows me to focus the "underneath" app
and work in it "thru" the on-top app, when necessary -- this is why I find
transparency almost indispensable now).
> After login, I
> have kontact running, many chromium windows/tabs, tvbrowser (java) which
> uses an awful lot of memory, amarok and kmymoney. Some plasmoids, some
> other tools, like gkrellm and such. When I work with the system, I
> occasionally start things like oowriter, gimp or gwenview, and don't
> quit immediately when I am done. This needs some memory, but I think
> when I do not touch the application, most of it should get swapped out
> when RAM gets low, and should be no trouble. Of course I get a delay
> when I start using it again as the application needs to get swapped in,
> that's okay.
>
> My setup is so slow, for nearly a year I am thinking about dumping KDE4
> altogether - if it weren't so cool. And if I hadn't already put much
> time into tuning and configuration. With 4G of RAM is becomes unusable
> pretty soon, and even with 6G I get 2G of swap after a while. Well, at
> least part of this comes from a memory problem in plasma-desktop I
> think. Since I moved from 4.5.1 to 4.5.2, plasma-desktop started acting
> weirder. When I log in, or when I restart plasma-desktop manually, it
> takes minutes until the plasma stuff appears. During this phase, memory
> usage of the process climbs upwards until it reaches agout 1G, according
> to the RES column in top. And for some days now it crashes very often
> when I am using the comic plasmoid, which is not of much use anyway,
> because moreand more of the comics just do not work any more. When I
> close the plasmoid, memory usage is the same, so this is not the
> problem.
>
> When I started with KDE 4.2, my setup was quite similar. I had only 3.5G
> of RAM and an i686 system instead of amd64 now (that hardware is
> identical), and there was no memory problem. I even added a 2G tmpfs
> sometimes in order to do compiles in memory. Things became a little slow
> when I used an application that needed 1.5G of memory, but performance
> was still better than now.
>
> I'm using Gentoo Linux, so there is much compiling being done. I no
> longer do larger updates while I am working with the system, because of
> the slowdown. And it becomes especially annoying when watching movies or
> listening to music with amarok, and the sound stutters. All this was no
> problem at all one year ago.
>
> I installed KDE 3.5 just to compare, and it seems to be much faster. But
> I got used to KDE 4, and would not want to switch back. Maybe I will, if
> things will not become better soon. First I will add another 2G of
> memory, and let's see if 8G will be enough then to make KDE4 run fast.
It's interesting that your experience is so different than mine, when
we're both running KDE 4.5.2 on Gentoo.
Now while my system is somewhat old now (2004 era), it was well beyond the
desktop system of the time, with dual socket Opteron (originally single-
core 1.6 GHz Opteron 242s, now dual-core 2.8 GHz Operon 290s, the top of
the line as far as socket 940 goes). If you're only running a single
single-core, that's no doubt part of it, but it doesn't explain the memory
issues you mention.
Originally, I had 8 gig (4 sticks @ 2 gig each) RAM, but one stick died
and I've not replaced it, so I'm at 6 gig now. But even with all the
stuff I run, I wouldn't expect to have a problem even if I lost a second
stick bringing it down to four gig, and in fact I'm on record as saying if
I had it to do over, I'd get 4 1-gig sticks instead (the four sticks
allows more efficient multi-channel memory access), since I'm seldom using
more than 4 gig, INCLUDING CACHE. While I do put the extra memory to work
when I'm doing upgrades (using portage's parallel building,
MAKEOPTS="-j13 -l10" and defaulting to emerge --jobs=4 --load-average=7,
with PORTAGE_TMPDIR in a 5 gig tmpfs), even that seldom pushes memory
above 6 gigs usage into swap (it'll typically go a a few MB in, 10-20)
-- and that's even with kernel swappiness=100, so it's going to swap
instead of dumping cache.
But there's three differences that I'd guess make up a majority of the
difference:
1) With a few noted exceptions, my general work pattern closes apps when
not in use. While I may run days to weeks without a reboot (and then it's
usually to test a new kernel, I run direct linus mainline git and do
regular pre-release kernel testing and bug reporting, among other things),
and may run kde for days between kde restarts, typically, I don't keep
/that/ many apps running. In particular, firefox is said to be a big
memory hog if left running for days at a time with a lot of tabs, and my
default browser is konqueror and I don't often open more than a handful of
tabs or keep them open for more than a few hours, max, so while I use
firefox some, I just don't have the issues with it that many report, as I
just don't use it that way. Even with konqueror, tho, I tend to open a
window, only open links in that window as new tabs, and only keep the
window open a few hours, tho I often have three or more independent
konqueror instances running at once.
I also don't run servantware (in the context of the sig) apps, so no flash
or the like to bug out on me. =:^)
I'm not sure how multiple-desktops vs activities vs multiple-monitors
affects plasma memory usage, but using the same single/dual (depending on
how it's counted) activity on all three desktops and only having three
desktops, can't /hurt/ memory usage, that's for sure.
It's worth noting that while your reported plasma-desktop memory usage,
resident, according to top, reaches a gig, here, top does report it as the
biggest resident memory user, but only by fractions of a MB, with both it
and pan (ranked second) reported by top to have 93 MB resident.
FWIW, here's some other plasma mem numbers according to top:
VIRT 930 MB (virtual memory is the amount the app has asked the kernel to
allocate, but traditionally, most apps use very little of it, such that
the kernel over-commits by a rather big ratio, 50:1, by default, see
/proc/sys/vm/overcommit_ratio).
SWAP 838 MB (swappable, not necessarily swapped, as it isn't here since
I'm running 0 MB swap ATM).
SHR 36 MB (shared, this memory is potentially shared between a number of
apps using the same libs).
93 MB resident here vs a gig there? Something tells me you've a problem,
and one of the differences is your 8 desktops with an activity per
desktop, vs my three desktops, same activity (or set of two activities
back on kde 4.4, one per monitor) on each.
Also possibly of note while still on #1, you mention running chromium,
which (like firefox but worse) bundles its own copies of many system
libraries, so memory that's normally shared between apps using the same
library is exclusive to chromium, with its bundled library copy. As I
said, firefox does some of the same thing, but at least on Gentoo, they've
force-unbundled more of the libraries with firefox than with chromium, so
it uses more of the shared system libs. Another factor would be the
separate VMs chromium uses for each tab, much stabler and more secure, but
not exactly memory miserly. If you're running the 50 tabs for days on end
that I've seen some folks talking about running on firefox, that /might/
be part of it.
But so far, we definitely know something's up with your plasma, as a gig
of resident really does seem abnormal. Why? Well, see #2 and #3.
2) I'm running gcc 4.5.1 here, with --as-needed in my LDFLAGS (it's there
on Gentoo by default now, but that's a rather new change so if you've not
done a full emerge --emptytree @world in awhile...).
Newer gccs might be a bit more efficient in that regard, and having the
whole system built with the same compiler is likely to make system library
memory sharing work better, I'd guess, as well. The --as-needed in LDFLAGS
might be a bigger factor, however, as otherwise the linker will link in
libraries that really aren't needed, and if those are then loaded at
runtime... Note that I also have -z,now in my LDFLAGS. That causes the
loader to resolve all symbols at app init time, which will pull in more
code then, but it then won't have to be pulled in later. Normally that'd
cause apps to use MORE memory, not less, but it's possible the effect of
forcing initial symbol resolution allows more efficient library sharing,
reversing the effect system-wide, I'm not sure. But the effect will in
any case be less with --as-needed as well, since less actually unneeded
code will be linked and therefore force-loaded by the on-init loading.
It's also somewhat possible that an earlier version of gcc had a bug that
I didn't run into with gcc 4.5.1. Again, it's possible that having parts
of the system compiled with different compilers could magnify the issue.
It's not for nothing that Gentoo's gcc upgrade guide recommends doing an
emerge --emptytree @world after a gcc upgrade, tho I normally only do it
after feature version bumps (4.4 to 4.5, not the bugfix 4.5.0 to 4.5.1
that I recently did, but I did an --emptytree recently for other reasons).
3) I know from personal experience that graphics hardware and drivers make
a **HUGE** difference in how well kde4 runs. "Drivers" includes not only
the xorg driver, but the kernel dri/drm module as well, plus mesa, libdrm,
and xorg. I tend to run ahead of ~arch, as I'm running the xorg overlay,
and I already mentioned I run mainline linus git kernels. Also, I don't
do servantware, so no nvidia/frglx here!
My graphics card is a Radeon hd4650 (r7xx series, my old one was an old
Radeon 9200, r2xx series, thus the personal experience of the difference
it makes!), and here's the graphics stack I'm running:
xf86-video-ati-6.13.2
xorg-server-1.9.1
mesa-7.9
libdrm-2.4.22
kernel (linus mainline) 2.6.36 (actually still a few git commits back from
that, 2.6.36-rc8 plus a few commits, I've not upgraded since the proper
release).
Again, those are recently recompiled along with the entire system using gcc
4.5.1.
kde 4.5 does have known issues with certain graphics cards and drivers,
including radeons, but it's said to be better if you're running the
latest, which I am. If you're running something older, or if you're
running servantware drivers, or if it's not all compiled with the same gcc/
binutils, that could be part of it. Actually, I'd not be surprised at all
to find this was the biggest issue, right here, given the known issues in
the area, and the abnormal gig resident for plasma-desktop you're
reporting.
***BTW***
I'm seeing the comic-strip-plasmoid related crashes here as well.
After chasing down a different (non-kde) graphics bug I was seeing, I have
a suspicion that I've not had time to verify.
What version of cairo are you running? Here:
cairo-1.10.0-r3
Apparently cairo 1.10 "changed ownership semantics" in some way vs.
previous versions. That's in quotes because it's very close to the words
used by the dev that traced down the non-kde bug I mentioned, and I don't
know enough about cairo to have a clue. But I do know that when he
adapted his code to work with the new semantics, it did away with the
problem.
Now, if I'm not mistaken, cairo originated as a gtk/gnome vector graphics
rendering library, but it's used more widely now, including, it would seem
according to equery depends, qt-gui and thus kde.
What I suspect but haven't yet verified is whether masking ~cairo-1.10.0,
thus forcing a downgrade to cairo-1.8.10, suddenly resolves this bad comic-
strip-plasmoid crashing issue!
Perhaps you could try it and see?
***/BTW***
>> So I used the bisect method to track it down to a specific file, then
>> dove into that file with a text editor...
>
> I've done this a couple of this, too. Very tedious, but better than
> starting from scratch.
When one has customized to the degree both of us have, it's DEFINITELY
better than starting from scratch!
>> $KDEHOME/share/config/plasma-desktop-appletsrc
> I also found this file when analyzing why my activities were on the
> wrong desktops. I was able to fix this manually for some times by
> exchanging some of the numbers. When it happened again, I simply
> restored a backup copy of this file.
>
> Oh, speaking of backups: I make lots of them. I never save the session
> without making one of my ~/.kde4 directory, because it often does not
> work and all applications open on the first desktop, for example. Or the
> plasmoids are all mixed up again.
Ugh! FWIW, activity application tracking should be much improved with
4.6, I've seen that blogged already, even tho I'm not following it as
closely as I once did.
The mixed-up plasmoids... probably part of the same bug this whole thread
is about, and hopefully fixed with 4.6 if not before. But I don't know
that for sure via blog of the dev.
> BTW, what I am missing is a possibility to move plasmoids around to
> other desktops/activities. Or is there already another method than
> deleting and re-creating a plasmoid? I'd also like the option to make
> them sticky on all activities, similar to windows being visible on all
> desktops. Even better would be the possibility to select multiple
> desktops/activities for plasmoids and windows.
Moving the plasmoids between activities... used to be possible using the
zooming interface, I think, but I don't know how to do it using the new
interface. Of course it should be possible by directly editing that file
mentioned above, changing the numbers appropriately, but that's definitely
"advanced users only" territory, given the hassle involved ans risk of
totally screwing the entire plasma config if one isn't careful.
The other stuff... there's STRONG hints in the blogs that this general
type of thing is already what they're planning, and I definitely expect to
see at least some of it for 4.6. But I doubt we'll see anything like
their full vision for activities before 4.8 or so (by which time they'll
have even more ideas, of course)... another full year plus, from now.
What the specific increments for 4.6, 4.7 and 4.8 might be, however, I
couldn't guess at this point.
> Oh, and plasma-desktop just crashed again, when I gave the comic
> plasmoid anopther try. After 4 1/2 minutes, des desktop is back, and
> plasma-desktop takes 1.3G of memory. And I suddenly have a minimized
> 'JavaEmbeddedFrame' in my panel which I cannot maximize. It disappeared
> after a while.
>
> Well, time to log out and in again, as I do every 1-2 days in order to
> make KDE4 fast again, at least for a while until the swapping starts
> again.
Hopefully something in the above is helpful, as a gig of resident for
plasma-desktop... OUCH!
--
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 mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
