DevHeads.net

Change icon for file type

Is it possible to apply changes without relogin?

In file context menu Properties -> File Type Options I click on icon. Icon
selection dialog opens. I select icon -- in Edit File type it changes to
new icon. Then I click OK and in Properties there is still old icon! What I
found useful is to delete /var/tmp/kdecache-$USER/icon-cache.kcache and
then relogin. Is it possible to see changes without these actions?

Comments

Re: Change icon for file type

By Duncan at 06/10/2014 - 17:45

Aleksey Midenkov posted on Tue, 10 Jun 2014 17:54:48 +0400 as excerpted:

Answer below, but first... Please turn off the HTML when posting to
mailing lists. It's controversial as a lot of folks consider it a
potential malware/spyware vector (webbugs, among other things) and spam
indicator and thus chose to use clients without HTML parsing enabled. On
many of these the HTML mail portion simply looks ugly. As it's often the
old-time regulars that know a lot about a subject that have this
viewpoint and they are often on enough lists that they are picking and
choosing what to reply to already, frustrating or offending the people
you want a good answer from isn't a particularly good idea, as they
killfile such messages or simply ignore them and move on to others
without the problem in the first place.

To answer the question, kde uses text-based configuration files (instead
of a binary-based registry) for ease of editing, but keeps a runtime
binary cache called the Kde SYstem COnfig CAche, aka ksycoca, for
responsiveness. There's two apps involved in its maintenance, kde
daemon, aka kded, that notifies running apps when ksycoca changes at
runtime, and kbuildsycoca, that normally runs at startup to collect the
current config and update the ksycoca binary cache to the latest config.

If for some reason a configuration change isn't detected properly at
runtime, usually running kbuildsycoca manually fixes it. Note that for
kde4, it's actually kbuildsycoca4, and that normally it does a fast but
not as thorough "incremental only" scan. To do the really thorough scan,
use the --noincremental option.

So try running...

kbuildsycoca4 --noincremental

... and see if that helps. Of course you can try it without
--noincremental first if you like and it'll probably work, but using that
option is normally recommended just in case. Note that if you run it in
a konsole, you may well get a bunch of complaints about minor errors in
*.desktop files, etc, but these are for developers and as a user you can
generally ignore them.

As you're dealing with icons you /may/ need to delete the icon cache AND
run kbuildsycoca4, but that should do it without a restart. If dolphin
(or plasma or konqueror or whatever, you didn't mention what app) doesn't
update at that point, consider filing a bug, as it should.

Re: Change icon for file type

By Aleksey Midenkov at 06/18/2014 - 08:00

On Wed, Jun 11, 2014 at 1:45 AM, Duncan <1i5t5. ... at cox dot net> wrote:
Should I mention what app? I guess it's the same library call because
dialog looks the same everywhere. My observations: kbuildsycoca4
doesn't rebuild icon-cache.kcache. Sometimes relogin helps, sometimes
doesn't. Sometimes it doesn't even change icon preview after Select
Icon dialog. Anyway, it is expected that it should work without any
relogins and cache rebuilds, hence it is a bug. Bug was already
submitted (335569).

Re: Change icon for file type

By Kevin Krammer at 06/10/2014 - 17:58

On Tuesday, 2014-06-10, 21:45:14, Duncan wrote:
The copy I received was a proper multi-part message. Your client should have
preferred the plain text version if that is your setup preference.
Mine did.

Cheers,
Kevin

Re: Change icon for file type

By Duncan at 06/10/2014 - 22:13

Kevin Krammer posted on Tue, 10 Jun 2014 23:58:48 +0200 as excerpted:

My client presented both the text/plain and the text/html parts, both as
raw text as it doesn't parse the HTML as such at all, treating it exactly
as it does text/plain (the safest policy for handling HTML, after all),
one below the other. That's why I said "the HTML portion".

But the HTML portion need not be sent at all, because that's simply an
invitation to malware and spyware probing, and if HTML is needed to make
the point, the point isn't worth making in the first place.

If HTML is appropriate, there's an appropriate place for it, a web page.
And an appropriate way to pass that in an email message, as a standard
URL, which can be loaded in the user's browser of choice or not, as they
choose.