/qubes-issues

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

appmenus color in menu sometimes doesn't match the current VM label #751

Closed
marmarek opened this Issue Mar 8, 2015 · 15 comments

Comments

Assignees

@marmarek marmarek

Labels
Projects
None yet
Milestone
  Release 3.1 updates
3 participants
@marmarek @unman @andrewdavidwong
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by marmarek on 18 Oct 2013 23:14 UTC
Simple to reproduce: just change VM label, menu will still use the old one.
Even Xorg restart doesn't fix it. Recreating appmenus for this VM also doesn't fix it. Looks like KDE somewhere caches icon and didn't notice symlink change.

In Xfce4 it is much better: application icons are updated instantly, VM directory icon - after regenerating appmenus (any change in selected apps).

Migrated-From: https://wiki.qubes-os.org/ticket/751
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 17 Nov 2013 15:34 UTC
In order to reload KDE cache one needs to do the following:

rm -fr ~/.kde/cache-dom0/*
killall plasma-desktop
plasma-desktop &

Then the icons will refresh their colors in the Start Menu :) I launch the plasma-desktop (the 3rd command above) from Alt-F2 KDE menu, to make sure that it stays persistently (which would not be the case if I started it from Konsole, as the plasma would quite if I closed the Konsole window). Perhaps it is possible to send some signal to the running plasma-desktop (ala USR1) to force it to flush the cache.
Member

marmarek commented Mar 8, 2015

Comment by joanna on 17 Nov 2013 15:34 UTC
In order to reload KDE cache one needs to do the following:

rm -fr ~/.kde/cache-dom0/*
killall plasma-desktop
plasma-desktop &

Then the icons will refresh their colors in the Start Menu :) I launch the plasma-desktop (the 3rd command above) from Alt-F2 KDE menu, to make sure that it stays persistently (which would not be the case if I started it from Konsole, as the plasma would quite if I closed the Konsole window). Perhaps it is possible to send some signal to the running plasma-desktop (ala USR1) to force it to flush the cache.

@marmarek marmarek added this to the Release 2 rc1 milestone Mar 8, 2015

@marmarek marmarek added bug C: desktop-linux P: minor labels Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 22 Jan 2014 00:25 UTC
Axon:

Related to the issue below, I've noticed that in the KDE "start menu,"
there are often "phantom" leftover directories from deleted VMs. You can
only see them if you right click on the "start button" and click "Edit
Applications..."

Even after I delete them, they sometimes come back. They don't seem to
harm anything, but I thought you should know.
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 22 Jan 2014 00:25 UTC
Axon:

Related to the issue below, I've noticed that in the KDE "start menu,"
there are often "phantom" leftover directories from deleted VMs. You can
only see them if you right click on the "start button" and click "Edit
Applications..."

Even after I delete them, they sometimes come back. They don't seem to
harm anything, but I thought you should know.
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 23 Jan 2014 05:20 UTC
Some unverified idea:

VM icon is a symlink the real icon - that one matching VM label color.
I suspect that KDE check modify time of that destination icon, but cache it
under symlink name - so doesn't notice the change as real icon file is
unchanged. This is what #751 is about.

You can check this hypothesis with changing time of the icon files:
sudo touch /usr/share/qubes/icons/*png
Then observe if KDE have updated icons.
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 23 Jan 2014 05:20 UTC
Some unverified idea:

VM icon is a symlink the real icon - that one matching VM label color.
I suspect that KDE check modify time of that destination icon, but cache it
under symlink name - so doesn't notice the change as real icon file is
unchanged. This is what #751 is about.

You can check this hypothesis with changing time of the icon files:
sudo touch /usr/share/qubes/icons/*png
Then observe if KDE have updated icons.
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 13 Apr 2014 10:59 UTC
Sadly in KDE 4.10 (dom0 based on fc18) this doesn't work. I will check in the fc20 based KDE soon.
Member

marmarek commented Mar 8, 2015

Comment by joanna on 13 Apr 2014 10:59 UTC
Sadly in KDE 4.10 (dom0 based on fc18) this doesn't work. I will check in the fc20 based KDE soon.
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 13 Apr 2014 11:11 UTC
Also KDE 4.10 - I've checked above idea about modify time - it doesn't work. Even if icon is recreated (so modify time changed), KDE icon cache still keeps old icon. kbuildsycoca4 doesn't help.
Even if I remove appmenus for given VM completely, verify that that VM disappears from the menu, then add it back, with updated icon (''copy'' of /usr/share/qubes/icons/COLOR.png in /var/lib/qubes/appvms/VMNAME/icon.png, then touch the file) - KDE menu still shows old icon color. KDE icon cache is screwed up :(
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 13 Apr 2014 11:11 UTC
Also KDE 4.10 - I've checked above idea about modify time - it doesn't work. Even if icon is recreated (so modify time changed), KDE icon cache still keeps old icon. kbuildsycoca4 doesn't help.
Even if I remove appmenus for given VM completely, verify that that VM disappears from the menu, then add it back, with updated icon (''copy'' of /usr/share/qubes/icons/COLOR.png in /var/lib/qubes/appvms/VMNAME/icon.png, then touch the file) - KDE menu still shows old icon color. KDE icon cache is screwed up :(
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 13 Apr 2014 11:14 UTC
So, I think we need a workaround described in the first comment. It works, although killing the plasmadesktop is far from being elegant :/
Member

marmarek commented Mar 8, 2015

Comment by joanna on 13 Apr 2014 11:14 UTC
So, I think we need a workaround described in the first comment. It works, although killing the plasmadesktop is far from being elegant :/
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 13 Apr 2014 11:18 UTC
Regarding the workaround: removing icon-cache.kcache is enough. Lets check fc20 KDE first...
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 13 Apr 2014 11:18 UTC
Regarding the workaround: removing icon-cache.kcache is enough. Lets check fc20 KDE first...
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 13 Apr 2014 11:19 UTC
The biggest problem is plasma-desktop killing -- it causes the user to "loose" desktop for a few secs :/
Member

marmarek commented Mar 8, 2015

Comment by joanna on 13 Apr 2014 11:19 UTC
The biggest problem is plasma-desktop killing -- it causes the user to "loose" desktop for a few secs :/
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 15 Apr 2014 02:06 UTC
Sadly KDE 4.12 doesn't make it any better.
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 15 Apr 2014 02:06 UTC
Sadly KDE 4.12 doesn't make it any better.
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 15 Apr 2014 11:44 UTC
So, lets just do the following:

  1. Remove the icon cache file
  2. Display a message to the user:
    "You will need to log off and log in again for the VM icons to update in the KDE launcher menu".

Do we need to do that only for KDE?
Member

marmarek commented Mar 8, 2015

Comment by joanna on 15 Apr 2014 11:44 UTC
So, lets just do the following:

  1. Remove the icon cache file
  2. Display a message to the user:
    "You will need to log off and log in again for the VM icons to update in the KDE launcher menu".

Do we need to do that only for KDE?
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 16 Apr 2014 14:59 UTC
Not only for KDE... But on xfce the only not refreshed icon is VM directory (applications icons refreshes correctly). And recreating appmenus solves the problem there.
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 16 Apr 2014 14:59 UTC
Not only for KDE... But on xfce the only not refreshed icon is VM directory (applications icons refreshes correctly). And recreating appmenus solves the problem there.

@marmarek marmarek self-assigned this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 16 Apr 2014 15:06 UTC
http://git.qubes-os.org/?p=marmarek/core-admin-linux.git;a=commit;h=7afc15dcf08fabcaecc0315a0e6a80c3e48effdc
Member

marmarek commented Mar 8, 2015

Comment by marmarek on 16 Apr 2014 15:06 UTC
http://git.qubes-os.org/?p=marmarek/core-admin-linux.git;a=commit;h=7afc15dcf08fabcaecc0315a0e6a80c3e48effdc

@marmarek marmarek closed this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 22 Nov 2014 13:29 UTC
The above workaround(s) don't actually work, at least for KDE. What works, however (after changing VM color) is to open "Add more shortcut", modify the appmenus list, then click OK. And this works without the need to remove any chaches, log out, log in, etc.
Member

marmarek commented Mar 8, 2015

Comment by joanna on 22 Nov 2014 13:29 UTC
The above workaround(s) don't actually work, at least for KDE. What works, however (after changing VM color) is to open "Add more shortcut", modify the appmenus list, then click OK. And this works without the need to remove any chaches, log out, log in, etc.

@marmarek marmarek modified the milestones: Release 2.1 (post R2), Release 2 rc1 Mar 8, 2015

@marmarek marmarek reopened this Mar 8, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 27 Nov 2014 13:43 UTC
Correction: the appmenu refresh works for changing of the .directory icon (the VM name), but it does not refresh the .desktop icons (the actual appmenus). For the latter to occur, it seems like we need to kill the plasma desktop (aka log out/log in to KDE).
Member

marmarek commented Mar 8, 2015

Comment by joanna on 27 Nov 2014 13:43 UTC
Correction: the appmenu refresh works for changing of the .directory icon (the VM name), but it does not refresh the .desktop icons (the actual appmenus). For the latter to occur, it seems like we need to kill the plasma desktop (aka log out/log in to KDE).

@marmarek marmarek referenced this issue Jan 15, 2016

Closed

No appmenus for restored VMs until reboot (Xorg restart) #1628

@andrewdavidwong andrewdavidwong referenced this issue Mar 13, 2016

Closed

color of icons in apps.icons/ isn't updated when changing vm label #1606

@rootkovska rootkovska referenced this issue Jun 27, 2016

Closed

Get rid of KDE, use Xfce as the default Dom0 WM/DE #2119

@marmarek marmarek modified the milestones: Release 3.1 updates, Release 2.0 updates Nov 19, 2016

@unman

This comment has been minimized.

Show comment
Hide comment
@unman

unman Apr 14, 2017

Member

@andrewdavidwong I believe this issue is resolved in 3.2, and can be closed
Member

unman commented Apr 14, 2017

@andrewdavidwong I believe this issue is resolved in 3.2, and can be closed

@andrewdavidwong andrewdavidwong closed this Apr 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment