An alternative baloo-kcmadv with more features and closer to the nepomuk
kcm is under development, and has been packaged in f20/kde-unstable repo.
disable indexing button
Once installed, you'll see a new item "Desktop Search Advanced" in
I did the switch to KDE 4.13 and I seem to lost the tags that I've added to my
files. This is most likely due to Nepomuk - > Baloo migration.
Could not find anything useful on the list or in the web, so :
Are the tags lost , or I need to dig deeper into how to attempt to retrieve
them from some data store that Nepomuk had ?
If so, any hints or links on how to do it ?
Before any comments, found and tried some info, but nepomukbaloomigrator
crashes on me, and I can't start nepomuk from my user, only from root (where
tags aren't existing, obviously)
Systems Administrator (LPIC 3, Novell CLA certified)
T: 0845 421 0444
I originally sent this message to the Fedora users list, but the only
response I got was a note from Patrick O'Callaghan suggesting it might be
better directed to the KDE on Fedora list. (I had previously posted on the
digikam users list, but got no response.) So here it is:
On a fully updated Fedora 20, I've had the following problems importing
images from a Canon EOS SL1 since the update from digikam 3.5 to 4.0
(which I got July 26):
- The digikam camera window doesn't show thumbnails or previews, just icons
for RAW and/or JPEG. I can't seem to preview the images to select the
ones to import. Digikam does recognize the camera, it just won't show
thumbnails or previews of the images on the camera.
- Digikam gets the date from JPEGs to do renaming as I have specified, but
it seems to think that all of the RAW files were created on 1969-12-31
at 19:00:00, at least from the filenames it's generating. Once the files
are imported (I just import all of them without doing any selection), the
"File properties" in digikam shows the correct date for each image. (Well,
up to time zone issues: my camera is set to Eastern Daylight Time, and
Digikam seems to be interpreting that as Universal Time and then correcting
for my computer's time zone, so things are off by 4 hours--but this was true
before the update, too. Is this a configuration problem on my part?)
- I have digikam set to create a new sub-album with the date; so I have
<root album>/<year>/<month>/<date>. I'm importing into the <month>.
JPEGs are correctly put in a sub-album with the date, but RAW images are
put into the <month>, not into a sub-album. I assume this is connected
to not being able to correctly get the date for the RAW images during the
All of this (except for the time zone stuff) worked fine with 3.5. I
tried downloading the bodhi builds of digikam 4.2 for Fedora 20, but I'm
seeing the same issues as with 4.0. I looked through the digikam mailing
list archives and saw that some other people had problems with previewing
images from the camera with Canon cameras on 4.0, but the only response
was a claim that digikam was using gphoto2, with no details or follow-up.
(I can download the images from the gphoto2 command line, too. The
problem is not seeing thumbnails in the camera window to decide
what to download, or getting the dates on RAW images.) Shotwell seems to
be able to generate thumbnails of images in the camera before downloading
and gets the correct dates on RAW images.
I only started using digikam in early July, so it may well be that this is
pilot error, but I haven't been able to figure it out from the
documentation. I don't think I changed any digikam settings with the
upgrade from 3.5 to 4.0, and nothing about the camera changed at that
Thanks for any help. If nobody's got a solution, should I file it on the
Fedora bugzilla, or upstream?
whats wrong with "plasma-desktop-appletsrc"?
the bkp-file is how it should be
some crap is adding "[Containments]" repeatly
until today it was enough to copy "activityId" to
"[Containments]", remove the rest and hard restart
X so KDE has no chance to write his crap back
well, now after doing that 3 times i still sit in
front of a empty desktop witout any widgets
I looked at the plasma-5 copr, and I have several questions :
- Is it still planned to make co-installable packages (in /opt) ?
- How can the user adjust settings, as systemsettings isn't officially
Settings which should ideally be common are saved in different files :
for example mouse settings (SingleClick, WheelScrollLines,
DoubleClickInterval, ...) are in ~/.kde/share/config/kdeglobals for KDE4
and in ~/.config/kdeglobals for KF5.
So currently you can only configure the applications which are using the
same Qt version as the workspace, for the other you have to edit the
configuration files manually.
Even with only one workspace (Plasma 5 or KDE4), the available widget
styles could be different for Qt4 and Qt5 applications.
- I wanted to install plasma-oxygen for the Qt5 widget style, but it
fails since it depends on kwin, which has file conflicts with kde-workspace.
file /usr/share/config.kcfg/kwin.kcfg from install of
kwin-5.0.0-2.fc20.x86_64 conflicts with file from package
Perhaps the decoration and widget style should be split in two different
On 08/19/2014 12:36 AM, John Mallett wrote:
> On Tue, 19 Aug 2014 14:57:15 John Mallett wrote:
>> I just downloaded fedora-live-kde-x86_64-21-alpha-t2.iso and burned it to a
>> usb. It booted and got through the login screen. Then needed a password.
>> Any one know what it is
live image passwords are blank/empty.
And it's supposed to autologin. My guess: your initial autologin
session is crashing or ending unexpectedly for some reason, so it
bounces you back to the login window.
yesterday I decided to upgrade to Fedora 21, soon to be in Alpha. It all works smoothly and my only problem was with akonadi and thus with kmail.
Where I got
[ERROR] mysqld got signal 11 ;
The full error log is available as attachment.
Since despair is not an option I searched for help and I got to this page about Arch and the same problem:
After reading I decided to remove the ~/.local/share/akonadi/mysql.conf
log out and log in and voilá I am again an happy camper. :-)
FWIW, as reported in the link above, there is not any difference between the file that I had removed (moved actually, not that it matters) and the new file placed there. I suspected that the absence of that file triggers the right procedure.
I hope this helps others.