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 :
Steps to reproduce :
1. Click on Kickoff or launcher menu and go to graphics category
Steps to Reproduce:
This is all very temporary, the artwork final design isn't integrated yet.
still on beta 1
also a bug in LXDE launcher
this is not a bug, this is because we need to redo all icons but that need "time"
*** Bug 1545 has been marked as a duplicate of this bug. ***
It's also affecting Gnome menu (bug 1545)
The "Graphics" category of KDE launcher has a wrong icon =>
The "Graphics" category has the wrong icon in the MenuSource RPM:
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?
(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.
Any news on this issue?
No news on this yet.
Will try to motivate a team mate, to take care of it.
@BicycleRepairMan: If it's so easy to create such an icon for you, why don't you join artwork?
I think this bug was assigned correctly, but please confirm by putting "OK" on the whiteboard or by confirming in a comment
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.
so please people in CC can you tell in what desktop it works. (cauldron)
In fact maybe it's more something bogus in the icon set
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.
RPM Packages =>
Release (media or process)Target Milestone:
Mageia 2Source RPM:
user, user's password and root's password can not been created or setSeverity:
Why didn't you just write a comment if you wanted to say something about this bug. What you now did was trolling.
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
Release (media or process) =>
RPM PackagesSource RPM:
user, user's password and root's password can not been created or set =>
(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
> Of course, in case the bug isn't in a package you maintain, please assing back
General ping for Alpha 3
Should I fix it? Should be straight-forward. But it's not my package.
@Oliver: yes, I think you can go with it.
Fixed on cauldron
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.
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.
(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).
Oliver, although this is a trivial update could I please remind you of the updates policy about writing an advisory for QA:
Testing i586 this appears to be fixed in Gnome but not in KDE.
rpmdrake does display correctly but KDE menu is still a video icon
The volume icon in the notification area has also changed in KDE
(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.
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.
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?
(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
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
Good find Dave!
Oliver, are you still working on this or happy for it to be validated as it is?
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.
$ find -L .kde4 -iname "icon-cache*"
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.
$ echo $HOSTNAME
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?
(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?
Assigning Oliver until this is ready for QA. Please reassign when you're done :)
Mageia 2 =>
(sorry for the noise don't know what happen :/)
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
Did you add something to remove the icon-cache.kcache file after installation?
If not then this won't be fixed for KDE.
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...
(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
should also be enough to trigger reindexing of the cache for KDE as a workaround, but that's untested.
So if I understand correctly the thing to do would be to add
to /var/lib/rpm/filetriggers/gtk-icon-cache-oxygen.script ?
(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
(resolved in cauldron)
Is there an update for the file triggers coming to Mageia 1, that
this bug should depend on?
Reassigning to bugsquad, since it's not in my scope to do anything here.
(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
(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
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
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 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.