I have configured the Task Manager widget in the KDE panel to show only
apps for the current desktop, but I've noticed that a flashing tile for an
app from another desktop will appear if KDE detects that that app has
performed some action such as a screen update. I suppose this can be a
useful feature, but in the case of GNU Emacs it's a bit annoying. If I
use a keyboard shortcut to jump to a desktop with a GNU Emacs window, it's
100% certain that I'll see a flashing tile for that window if I land in a
different desktop. In other words, I don't even need to _do_ anything in
Emacs to cause the flashing tile to appear--I just need to visit its
desktop via a keystroke. If I want to leave the Emacs desktop without
triggering the flashing tile, I have to use the mouse to select a
different desktop from the Virtual Desktops widget.
Note that this behavior began when I upgraded to KDE 4.4.x. I had no such
problem with 4.3.x.
1. Is there any way to configure Task Manager to exempt selected apps
from the "flashing tile" treatment? Are there any other workarounds that
might cut back on this nuisance?
2. If not, any suggestions on how I ought to put together a clear
upstream bug report or enhancement request?
I wish to create a shortcut, using a mouse gesture to emulate a key
the problem is, I can't figure out how to write the key combination, or find
the required key combination is: Ctrl+Alt+R (for klipper).
In my 4.5 RC-1 (F12) Akonadi is not starting under 'root'. As suggested by
Kevin sometimes back (during the days of F10), I have added:
Akonadi is fine under normal user. Has something changed in 4.5?
I have some problems running palapeli from kde-unstable repository.
When I try to open any puzzle (either by creating a new one, or
selecting some existing one), it simply segfaults. I'm not sure where
I should report bugs in kde-unstable. It does that in a very ugly way
-- producing stack trace with about 68 thousand frames. I don't have
full -debuginfo for every package, so the stack trace isn't complete,
there are some ??'s. The last frame is
#0 0xb718b710 in QCommonStyle::sizeFromContents(QStyle::ContentsType,
QStyleOption const*, QSize const&, QWidget const*) const () from
and the only palapeli part in those 68000 lines (except the very
beginning) is something like this: (it's moc-generated code,
#8 0x08084f10 in Palapeli::View::qt_metacall (this=0x84178a0,
_c=QMetaObject::InvokeMetaMethod, _id=35, _a=0xbf800678)
87 _id = QGraphicsView::qt_metacall(_c, _id, _a);
I hope that this is reproducible under any conditions with any similar
system, so I post only this tiny fraction to make sure that you've
reproduced exactly this bug. I can, of course, make full stack trace
with all required -debuginfo packages, if that was not the case.
It's Fedora 13, qt-4.7.0-0.24.beta1.fc13.i686 (and everything else
from kde-unstable, right now).
I'm not sure if this is the right place and if this report is of any
use. I'm sorry if it is not.
Pod svícnem bývá největší krize.
I've got an ongoing problem that I've posted about before. I've recently
done some research as to what, *exactly* the problem is. I've narrowed it
down somewhat. It appears that Akonadi keeps running because there's some
socket/file still active even after shutting down KMail.
Quick summary of the problem--- I access my linux box at home from my
Windows workstation at the office via SSH and VNC. When I leave for the day,
if I close everything down, including the VNC server, KMail hangs when I
get back to the local console and attempt to send an email.
I checked recently just before leaving the office and found the following
file/process still running:
john 12234 0.0 0.1 271880 6384 ? S 06:21 0:00 kdeinit4:
kio_file [kdeinit] file local:/tmp/ksocket-john/klauncherMT3445.slave-socket
Now, I'm no programmer, so I don't know exactly what it means. All I know
is that this file/process is still running so Akonadi hangs, or Akonadi
hangs so this file/process is still running. Either way, Akonadi is still
running when I get home and trying to send an email (everything works fine
until I go to send) results in KMail hanging, and I have to manually kill
all the KMail related processes from the command line.
I would appreciate it if someone could take a look at that. Any suggestions
on how to avoid this problem? Perhaps I should switch to Evolution or
Thunderbird? I don't really *want* to switch as I have several years' worth
of messages tied up in KMail, not to mention I'd have to configure another
email client and all the filters, etc.
If I could just get this one glitch resolved, it would solve 99.9% of my