Bug 107 - The "Graphics" category has the wrong icon in the Menu
Summary: The "Graphics" category has the wrong icon in the Menu
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 1
Hardware: All Linux
Priority: Normal minor
Target Milestone: Mageia 1
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: Triaged, UPSTREAM
: 1545 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-19 12:48 CET by Lucien XU
Modified: 2012-12-02 14:31 CET (History)
16 users (show)

See Also:
Source RPM: desktop-common-data
CVE:
Status comment:


Attachments

Description Lucien XU 2011-02-19 12:48:53 CET
Description of problem:

The "Graphics" category of KDE laucher (kickoff or menu) has the icon of "Multimedia" category. 

Version-Release number of selected component (if applicable):
KDE SC 4.6.0
Mageia package version 4.6.0-2.mga1

How reproductible : 
Every time

Steps to reproduce : 
1. Click on Kickoff or launcher menu and go to graphics category

Reproducible: 

Steps to Reproduce:
Comment 1 Ahmad Samir 2011-02-22 19:11:01 CET
This is all very temporary, the artwork final design isn't integrated yet.

Keywords: (none) => Triaged
Assignee: bugsquad => ennael1

Comment 2 Magnus Rasche 2011-04-06 08:04:21 CEST
still on beta 1

CC: (none) => magnus.mud

Comment 3 Magnus Rasche 2011-04-22 20:10:53 CEST
also a bug in LXDE launcher
Comment 4 D Morgan 2011-04-22 20:27:00 CEST
this is not a bug, this is because we need to redo all icons but that need "time"

CC: (none) => dmorganec

Anne Nicolas 2011-04-28 12:23:23 CEST

Assignee: ennael1 => dmorganec

Comment 5 Thorsten vanLil 2011-06-03 13:13:35 CEST
*** Bug 1545 has been marked as a duplicate of this bug. ***

CC: (none) => le.berred

Comment 6 John Balcaen 2011-06-03 14:08:08 CEST
It's also affecting Gnome menu (bug 1545)

CC: (none) => balcaen.john

Ahmad Samir 2011-06-04 00:38:06 CEST

Summary: The "Graphics" category of KDE launcher has a wrong icon => The "Graphics" category has the wrong icon in the Menu
Source RPM: (none) => desktop-common-data

Comment 7 Bicycle RepairMan 2011-07-16 21:40:24 CEST
Why is there no movement on this? Surely it can't be too hard to simply switch out the icon at such a prominent place?

CC: (none) => eagle150

Remco Rijnders 2011-08-24 13:44:08 CEST

Assignee: dmorganec => mageia-artwork

Comment 8 Marja Van Waes 2011-10-10 20:01:45 CEST
(In reply to comment #7)
> Why is there no movement on this? Surely it can't be too hard to simply switch
> out the icon at such a prominent place?

@ Bicycle RepairMan:

Well, if you want to help you're very welcome :)

Even easy things need some time to work on them, and when more urgent things take all time there is, the easy things might never get done.

@ mageia-artwork:

Any news on this issue?

CC: (none) => marja11

Comment 9 Thorsten vanLil 2011-10-10 20:24:43 CEST
No news on this yet.
Will try to motivate a team mate, to take care of it.

Thorsten

CC: (none) => tvl83

Comment 10 Oliver Burger 2011-10-10 20:31:49 CEST
@BicycleRepairMan: If it's so easy to create such an icon for you, why don't you join artwork?

CC: (none) => oliver.bgr

Comment 11 Marja Van Waes 2011-12-11 21:31:54 CET
@ Assignee
I think this bug was assigned correctly, but please confirm by putting "OK" on the whiteboard or by confirming in a comment
Manuel Hiebel 2011-12-12 11:11:49 CET

Priority: Normal => release_blocker

Comment 12 Max 2011-12-14 20:14:31 CET
It looks like this is not an Artwork bug.
In the KDE settings there is an appropriate icon called "applications-graphics" under System icons>Categories.
I was easily able to set that as the icon on my own computer.
Furthermore, the fact that this bug appears in GNOME as well leads to the conclusion that it is a configurations issue, not an artwork one.
I'm adding the dev mailing list to the cc of this bug.
Screencaps: imgur.com/fRFpz,gz3sD

CC: (none) => bogusman222
Assignee: mageia-artwork => bugsquad

Comment 13 Manuel Hiebel 2011-12-14 20:36:53 CET
so please people in CC can you tell in what desktop it works. (cauldron)
Comment 14 Manuel Hiebel 2011-12-14 20:39:39 CET
In fact maybe it's more something bogus in the icon set
Comment 15 Oliver Burger 2011-12-14 20:51:40 CET
it seems, we have some strange icons in that package.
Most of them seem to be from the oxygen icon theme, but somehow we didn't take /usr/share/icons/oxygen/32x32/categories/applications-graphics.png but /usr/share/icons/oxygen/32x32/categories/applications-multimedia.png.
Sergio Esaú Arámbula Durán 2011-12-28 03:50:19 CET

CC: (none) => seadx6, sysadmin-bugs
Component: RPM Packages => Release (media or process)
Target Milestone: --- => Mageia 2
Source RPM: desktop-common-data => (none)
Whiteboard: (none) => user, user's password and root's password can not been created or set
Severity: minor => critical

Comment 16 Marja Van Waes 2011-12-28 11:34:12 CET
@ Esaú

Why didn't you just write a comment if you wanted to say something about this bug. What you now did was trolling.

@ dmorgan

assigning to you, because Ahmad set the RPM field to desktop-common-data and you maintain that package. 

Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

Of course, in case the bug isn't in a package you maintain, please assing back

CC: sysadmin-bugs => (none)
Component: Release (media or process) => RPM Packages
Source RPM: (none) => desktop-common-data
Whiteboard: user, user's password and root's password can not been created or set => (none)
Severity: critical => minor

Comment 17 Marja Van Waes 2011-12-28 13:24:27 CET
(In reply to comment #16)

> 
> @ dmorgan
> 
> assigning to you, because Ahmad set the RPM field to desktop-common-data and
> you maintain that package. 
> 
> Please set status to ASSIGNED if you think this bug was assigned correctly. If
> for work flow reasons you can't do that, then please put OK on the whiteboard
> instead.
> 
> Of course, in case the bug isn't in a package you maintain, please assing back

again assigning

Assignee: bugsquad => dmorganec

Comment 18 Manuel Hiebel 2012-01-05 19:08:28 CET
General ping for Alpha 3

Whiteboard: (none) => QA

Comment 19 Oliver Burger 2012-01-05 19:17:38 CET
Should I fix it? Should be straight-forward. But it's not my package.
Comment 20 Damien Lallement 2012-01-05 19:53:49 CET
@Oliver: yes, I think you can go with it.

CC: (none) => mageia

Oliver Burger 2012-01-16 18:04:40 CET

Status: NEW => ASSIGNED
Assignee: dmorganec => oliver.bgr

Comment 21 Oliver Burger 2012-01-18 10:37:08 CET
Fixed on cauldron
Comment 22 Florian Hubold 2012-01-18 10:57:37 CET
This is also a problem for the categories icons in rpmdrake. The following categories have the same icons:

archiving, public keys, sound, system, terminals ("gear" icon)
communications, networking ("globe" icon)
databases, development, editors, emulators, file tools, shells, text tools ("hammer and banner icon")

Also most of the sub-categories share the same icon. Just take a look with a file manager which supports image preview in /usr/share/icons and you will see the problem easily. For example, the blue "globe" icon is duplicated there 20 times, always with a different name. If we do such stuff, we could easily use symlinks to save a bit of space.

CC: (none) => doktor5000

Comment 23 Oliver Burger 2012-01-18 11:03:44 CET
The icons described in the original report are fixed on Cauldron and 1.

The rest has to wait a bit, but should not be forgotten.

Assignee: oliver.bgr => qa-bugs

Comment 24 Manuel Hiebel 2012-01-18 11:46:46 CET
(In reply to comment #22)
> This is also a problem for the categories icons in rpmdrake. The following
> categories have the same icons:

In rpmdrake ? :D
And you should open a separate bug iirc


The fix works for me (x86_64) with Gnome and after an killall of gnome-panel (so there is no need to logout).
Comment 25 claire robinson 2012-01-18 16:10:38 CET
Oliver, although this is a trivial update could I please remind you of the updates policy about writing an advisory for QA:
https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29

Thankyou :)


Testing i586 this appears to be fixed in Gnome but not in KDE.
Comment 26 claire robinson 2012-01-18 16:14:48 CET
rpmdrake does display correctly but KDE menu is still a video icon
Comment 27 claire robinson 2012-01-18 16:20:03 CET
The volume icon in the notification area has also changed in KDE
Comment 28 Florian Hubold 2012-01-18 16:27:11 CET
(In reply to comment #24)
> (In reply to comment #22)
> > This is also a problem for the categories icons in rpmdrake. The following
> > categories have the same icons:
> 
> In rpmdrake ? :D
> And you should open a separate bug iirc

OK, will open a new one. Sorry for the noise.
Comment 29 claire robinson 2012-01-18 16:28:02 CET
I'm not sure if it is related but this was strange.

After logging out of KDE and into gnome to test then back into KDE the volume icon had changed, in fact I think the whole task bar was slightly different.

The process kded4 was taking 100% CPU.

After rebooting, those problems have returned to normal but the icon in the menu is still the video icon.
Comment 30 Oliver Burger 2012-01-18 16:47:17 CET
Since I did nothing but replace a few pngs all other side effects must be from something else.

@KDE: Same on Cauldron. I don't know, why, does KDE have some kind of icon cache?

Mikala?
Comment 31 Dave Hodgins 2012-01-18 22:26:30 CET
(In reply to comment #30)
> Since I did nothing but replace a few pngs all other side effects must be from
> something else.
>
> @KDE: Same on Cauldron. I don't know, why, does KDE have some kind of icon
> cache?

Yes.  Logging out to run level 3, deleting and recreating ~/tmp fixes
the kde icons.

As updates generally are not supposed to alter anything in
/home, I don't think this can be fixed in the update.

I consisder testing complete on i586 for the srpm
desktop-common-data-1-12.1.mga1.src.rpm

CC: (none) => davidwhodgins

Comment 32 claire robinson 2012-01-22 17:56:49 CET
Good find Dave!

Oliver, are you still working on this or happy for it to be validated as it is?
Comment 33 Oliver Burger 2012-01-23 08:59:13 CET
I'd like first to have a confirmed way for the user to fix the icons in KDE's menu. I tried Dave's solution after thoroghly looking at the contents of ~/tmp/.
It didn't work and after what I saw of the files in ~/tmp/ there is no reason it should work.
I assume it's some file in .kde4/cache-HOSTNAME.oli-home/, after deleting the "icon-cache.kcache" file in there it was working.
I just need someone to confirm that.

Oliver
Comment 34 claire robinson 2012-01-23 18:14:54 CET
$ find -L .kde4 -iname "icon-cache*"
.kde4/cache-linux.local/icon-cache.kcache
.kde4/cache-localhost/icon-cache.kcache
.kde4/cache-localhost.localdomain/icon-cache.kcache

The three folders are all symlinks to /var/tmp/kdecache-<username>/

Deleting icon-cache.kcache has no immediate affect but after logging out and back in the Graphics icon is showing correctly in KDE menu, also the 'More' submenu in the Graphics category is corrected.
Comment 35 claire robinson 2012-01-23 18:16:40 CET
$ echo $HOSTNAME
localhost
Comment 36 Florian Hubold 2012-01-23 20:17:06 CET
For reference, KDE should update the icon cache by itself, if it was invalidated correctly. Just have a look f.ex. at http://osdir.com/ml/kde-devel/2011-03/msg00045.html

@Oliver: Maybe this needs to be added to the SPEC? And in the future we should have an RPM filetrigger for that?
Comment 37 Florian Hubold 2012-01-23 20:28:52 CET
(In reply to comment #36)
> @Oliver: And in the future we should have an RPM filetrigger for that?

Replying to self: Seems our current filetrigger should be responsible for such updates, but as the icons are located directly below /usr/share/icons, the trigger does not fire.

Check output/content of relevant triggers (they are shared between GNOME/KDE)
ls -l /var/lib/rpm/filetriggers/gtk-icon-cache*

@Oliver: Don't know how to solve this properly, as it would be a bad idea to relocate some default icons in a released distro. Maybe drop a mail to -dev?
Comment 38 claire robinson 2012-01-24 13:31:22 CET
Assigning Oliver until this is ready for QA. Please reassign when you're done :)

Priority: release_blocker => Normal
CC: (none) => qa-bugs
Version: Cauldron => 1
Assignee: qa-bugs => oliver.bgr
Target Milestone: Mageia 2 => Mageia 1

claire robinson 2012-01-24 13:31:58 CET

Hardware: i586 => All

Manuel Hiebel 2012-01-27 16:55:23 CET

Blocks: (none) => 4300

Manuel Hiebel 2012-01-27 16:55:37 CET

Blocks: 4300 => (none)

Comment 39 Manuel Hiebel 2012-01-27 17:03:36 CET
(sorry for the noise don't know what happen :/)

Blocks: (none) => 4300

Comment 40 Oliver Burger 2012-02-12 15:22:00 CET
Ok, let's get this done.

The update does fix the issue for all dekstops but KDE. On KDE nothing breaks, but you won't just see any change due to KDE's icon cache.

I think we should push it unless the KDE guys (at least mikala is in cc) do tell us something new.

--
This update fixes the wrong icon being used for the graphics section in the menu and rpmdrake
See Bug #107
---
Comment 41 claire robinson 2012-02-12 18:09:02 CET
Did you add something to remove the icon-cache.kcache file after installation? 

If not then this won't be fixed for KDE.
Comment 42 Oliver Burger 2012-02-13 09:57:59 CET
No, since packages should not touch the users HOME. That's why I'm still hoping for mikala or some other KDE guy to respond...
Comment 43 Florian Hubold 2012-02-13 10:48:53 CET
(In reply to comment #42)
> No, since packages should not touch the users HOME. That's why I'm still hoping
> for mikala or some other KDE guy to respond...

Please look again at comment#37, our filetriggers should be updated to handle this, you should either mail to-dev how to handle this or directly ask dmorgan and mikala for this, the relevant filetrigger comes from oxygen-icon-theme package.

If i understood upstream documentation correctly
touch /usr/share/icons/
should also be enough to trigger reindexing of the cache for KDE as a workaround, but that's untested.
Comment 44 Florian Hubold 2012-02-29 13:58:08 CET
Ping?
Comment 45 Juan Luis Baptiste 2012-03-02 06:43:19 CET
So if I understand correctly the thing to do would be to add 

touch /usr/share/icons/

to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ?

CC: (none) => juan.baptiste

Comment 46 Luc Menut 2012-03-02 09:14:38 CET
(In reply to comment #45)
> So if I understand correctly the thing to do would be to add 
> 
> touch /usr/share/icons/
> 
> to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ?

I don't think so.

IIUC, we probably suffer from this upstream bug
http://bugs.kde.org/show_bug.cgi?id=251288

CC: (none) => lmenut

Comment 47 Manuel Hiebel 2012-04-25 22:34:51 CEST
(resolved in cauldron)

Blocks: 4300 => (none)
Whiteboard: QA => (none)

Comment 48 Dave Hodgins 2012-05-10 23:45:41 CEST
Is there an update for the file triggers coming to Mageia 1, that
this bug should depend on?
Comment 49 Oliver Burger 2012-06-14 12:42:14 CEST
Reassigning to bugsquad, since it's not in my scope to do anything here.

Assignee: oliver.bgr => bugsquad

Comment 50 Marja Van Waes 2012-06-14 18:10:12 CEST
(In reply to comment #46)
> (In reply to comment #45)
> > So if I understand correctly the thing to do would be to add 
> > 
> > touch /usr/share/icons/
> > 
> > to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ?
> 
> I don't think so.
> 
> IIUC, we probably suffer from this upstream bug
> http://bugs.kde.org/show_bug.cgi?id=251288



(In reply to comment #49)
> Reassigning to bugsquad, since it's not in my scope to do anything here.

I doubt upstream will solve this for an old version of KDE

Keywords: (none) => UPSTREAM
Status: ASSIGNED => NEW
See Also: (none) => http://bugs.kde.org/show_bug.cgi?id=251288

Comment 51 Manuel Hiebel 2012-11-05 16:52:03 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 52 Manuel Hiebel 2012-12-02 14:31:48 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX


Note You need to log in before you can comment on or make changes to this bug.