Bug 345100

*** Bug 350303 has been marked as a duplicate of this bug. ***

*** Bug 349176 has been marked as a duplicate of this bug. ***

*** Bug 348878 has been marked as a duplicate of this bug. ***

There seems to be a read/write path bug.

The kmenuedit is writing the submenu information to the ~/.local/share/kf5-<submenu>.directory but the plasma is trying to read the information from the  ~/.local/share/desktop-directories/kf5-<submenu>.directory.

A workaround is to copy/link the '.directory' files to the ~/.local/share/desktop-directories/ and refresh the icon cache: 'kbuildsycoca5 --noincremental'

Arch Linux forums: https://bbs.archlinux.org/viewtopic.php?id=202871

*** Bug 361234 has been marked as a duplicate of this bug. ***

I can confirm the path problem. I am using kmenuedit from kubuntu-ci (4:5.5.4+git20160308.1732+15.10-0) and it uses the package icon for new submenus. The <submenu>.directory files with that icon are stored in ~/.local/share/desktop-directories/ whereas the <submenu>.directory files with the correct (i.e. user given) icon are stored in  ~/.local/share/ ...

As 2 people have confirmed the bug, should someone change the status to "Confirmed" ?

Having this problem in Kubuntu 16.04

Additional confirmation for Kubuntu 16.04, with kmenuedit 4:5.5.5-0ubuntu1, plasma-desktop 4:5.5.5-0ubuntu1, and plasma-framework 5.18.0-0ubuntu1.

Also opensuse Tumbleweed (20160516) (x86_64)
KDE Plasma V 5.6.4
Frameworks V 5.22.0
QT V 5.5.1

kmenuedit version 5.5.5
KDE Frameworks 5.18.0
Qt 5.5.1 (built against 5.5.1)
The xcb windowing system

This behavior is still present in Kubuntu 16.04

I have the same issue, but on kubuntu 16.10

Hi,

I've the same issue 


KDE Frameworks 5.23.0
Qt 5.5.1 (built against 5.5.1)

Kubuntu 16.04.1 LTS

Thanks for your support

*** Bug 374303 has been marked as a duplicate of this bug. ***

The last update solved this problem on my PC.
T5hank for your support.

I confirm that its still an issue. i also created new submneu in the Internet menu and that did not get displayed either.

KDE Menu Editor 5.8.5
opensuse:tumbleweed:20161226
Qt: 5.7.1
KDE Frameworks: 5.29.0
KDE Plasma: 5.8.5
kwin5-5.8.5-172.1.x86_64
Kernel:  4.9.0-2-default
Nouveau:  1.0.13_2.1

I can also confirm this is an issue.

I'm using neon and plasma 5.9.0 as of today and bug is still present. 

No icon on the submenu after saving changes (although at first the icon does appear in the config window. Also plasma crashes when trying to read the menu just after I made the changes (created a submenu and put an icon)

Cheers

Gauthier

When I edit the menu entry for a sub-menu, it updates ~/.local/share/MyMenu.directory, but it does NOT update ~/.local/share/desktop-directories/MyMenu.directory.

(In reply to Elmo R from comment #18)
> When I edit the menu entry for a sub-menu, it updates
> ~/.local/share/MyMenu.directory, but it does NOT update
> ~/.local/share/desktop-directories/MyMenu.directory.

I copy ~/.local/share/MyMenu.directory to ~/.local/share/desktop-directories/MyMenu.directory and overwrite it, then I do something else in KMenuEdit so that it re-reads the directory, and everything shows up OK in Kicker.

I'm experiencing this issue, and have been for several versions. I'm not sure when it started. manually copying ~/.local/share/*.directory to ~/.local/share/desktop-directories/ saves my edits to submenu entries.

> kmenuedit --version                                                                                                                                                                                                     kmenuedit 5.8.6
> cat /etc/gentoo-release                                                                                                                                                                                                 Gentoo Base System release 2.3
> uname -a                                                                                                                                                                                                                Linux pahoran 4.9.16-gentoo #1 SMP Wed Mar 29 02:07:28 CDT 2017 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux

i'm using the following and its still a unresolved bug and they still haven't changed the status to "CONFIRMED" - not sure if anyone is actually looking at this bug.

opensuse:tumbleweed:20170331
Qt: 5.7.1
KDE Frameworks: 5.32.0
KDE Plasma: 5.9.4
kwin 5.9.4

Perhaps if we let our distros know with a bug there, they might have more pull to force upstream to take a look at this problem? Post the distro bugs here as x-ref.

I don't think anyone is paying attention to this bug... it's been a couple years now...

I don't think anyone is paying attention to this bug... it's been a couple years now...

I confirm that its still an issue. i also created new submneu in the Internet menu and that did not get displayed either.
I'm also investigating how to get opensuse to push this up the line

opensuse:tumbleweed:20170407
Qt: 5.7.1
KDE Frameworks: 5.32.0
KDE Plasma: 5.9.4
kwin 5.9.4
kmail2 5.4.3
akonadiserver 5.4.3
Kernel:  4.10.8-1-default
Nouveau:  1.0.14_1.1

I can confirm that this BUG is still here. I cannot create a sub-menu and assign an icon. 

My system:
Manjaro
Plasma 5.9.4
Frameworks 5.32.0
Qt Version 5.8.0
Kernel 4.10.10, 64-bit.

This is actually a bug in the kconfig framework, not in kmenuedit.

KDesktopFile::locateLocal() returns the wrong path (~/.local/share/ instead of ~/.local/share/desktop-directories/).
kmenuedit uses this function to get the save path, so the changes are saved to the wrong location (as has been pointed out here already) and are therefore ignored.
(kmenuedit cannot just change the original file because it may be located in a system-wide folder, normally /usr/share/desktop-directories/, where the user cannot write changes to)

Proposed fix:
https://phabricator.kde.org/D5502

Other than that, creating a new submenu does work fine here.
But please note that the application menu hides *empty* folders, so you need to create actual entries in the submenu first to make it show up.

(In reply to Wolfgang Bauer from comment #27)
> This is actually a bug in the kconfig framework, not in kmenuedit.
> 
> KDesktopFile::locateLocal() returns the wrong path (~/.local/share/ instead
> of ~/.local/share/desktop-directories/).
> kmenuedit uses this function to get the save path, so the changes are saved
> to the wrong location (as has been pointed out here already) and are
> therefore ignored.
> (kmenuedit cannot just change the original file because it may be located in
> a system-wide folder, normally /usr/share/desktop-directories/, where the
> user cannot write changes to)
> 
> Proposed fix:
> https://phabricator.kde.org/D5502
> 
> Other than that, creating a new submenu does work fine here.
> But please note that the application menu hides *empty* folders, so you need
> to create actual entries in the submenu first to make it show up.

Shouldn't someone change the status from "UNCONFIRMED" to something more correct?

(In reply to ianseeks from comment #28)
> Shouldn't someone change the status from "UNCONFIRMED" to something more
> correct?

It doesn't matter at all.

But ok, if you feel better, I'll change it.

(In reply to Wolfgang Bauer from comment #29)
> (In reply to ianseeks from comment #28)
> > Shouldn't someone change the status from "UNCONFIRMED" to something more
> > correct?
> 
> It doesn't matter at all.
> 
> But ok, if you feel better, I'll change it.

:) thanks.  it just means now that any new people who discover this problem in the mean time will be happy that its been, at a minimum, seen by the important ones and the trolls won't be able to add this one to their "list" of kde misdemeanours :)

Git commit 3ad00c4e56eb9fe6ea7386f8ca1db6e15c26ac11 by Wolfgang Bauer.
Committed on 25/04/2017 at 21:37.
Pushed by wbauer into branch 'master'.

Fix relativePath calculation in KDesktopFile::locateLocal()

The "dir" and "path" variables were obviously swapped here by mistake.
This resulted in the relativePath always being empty, and made the
function return "~/.local/share/" (or "~/.config/") instead of the
correct path.
FIXED-IN: 5.34.0
Differential Revision: https://phabricator.kde.org/D5502

M  +31   -0    autotests/kdesktopfiletest.cpp
M  +2    -0    autotests/kdesktopfiletest.h
M  +2    -2    src/core/kdesktopfile.cpp

https://commits.kde.org/kconfig/3ad00c4e56eb9fe6ea7386f8ca1db6e15c26ac11

Great work, thanks. another one off the list.

> it just means now that any new people who discover this problem in the mean time will be happy that its been, at a minimum, seen by the important ones and the trolls won't be able to add this one to their "list" of kde misdemeanours :)

Oh, so when I now change all bugs to CONFIRMED people will stop nagging us? Wonderful.

(In reply to Christoph Feck from comment #33)
> > it just means now that any new people who discover this problem in the mean time will be happy that its been, at a minimum, seen by the important ones and the trolls won't be able to add this one to their "list" of kde misdemeanours :)
> 
> Oh, so when I now change all bugs to CONFIRMED people will stop nagging us?
> Wonderful.

You're right bug status has probably little to do with this...people who like nagging will nag until status is changed to RESOLVED...and they might even find reasons to nag after that. 

Nevertheless I tend to believe the CONFIRMED status exist for a reason and so why having bug status if not to use them... For e.g. marking a bug as confirmed allows others who may experience similar issue and search on bug.kde.org to quickly see that the bug reported has been recognise as a KDE issue and so don't need to search elsewhere and explore other routes. At least I find it useful.

(In reply to Christoph Feck from comment #33)
> > it just means now that any new people who discover this problem in the mean time will be happy that its been, at a minimum, seen by the important ones and the trolls won't be able to add this one to their "list" of kde misdemeanours :)
> 
> Oh, so when I now change all bugs to CONFIRMED people will stop nagging us?
> Wonderful.

You're right bug status has probably little to do with this...people who like nagging will nag until status is changed to RESOLVED...and they might even find reasons to nag after that. 

Nevertheless I tend to believe the CONFIRMED status exist for a reason and so why having bug status if not to use them... For e.g. marking a bug as confirmed allows others who may experience similar issue and search on bug.kde.org to quickly see that the bug reported has been recognise as a KDE issue and so don't need to search elsewhere and explore other routes. At least I find it useful.

(In reply to Christoph Feck from comment #33)
> > it just means now that any new people who discover this problem in the mean time will be happy that its been, at a minimum, seen by the important ones and the trolls won't be able to add this one to their "list" of kde misdemeanours :)
> 
> Oh, so when I now change all bugs to CONFIRMED people will stop nagging us?
> Wonderful.

yes, if they are reasonable people and if they are not being reasonable, tell them to **** off. 
Otherwise what is the point of having a status field to track progress? When there is a problem but you have some idea of whats going on, people tend to be more reasonable e.g. tube getting stuck in the tunnel and there are no announcements and people get irritated, people get more patient when they know something is being done.

Bugzilla is not a tool for users, but for developers. Ticket fields are managed by the bug triaging team or the developers. They are to be read and interpreted by developers.

Regarding the status, think this way:

Unconfirmed: needs someone who understands the issue and find the code responsible
Confirmed: cause is known or even documented, needs someone to create a patch
Assigned: someone (or a team) adopted the ticket and creates a patch

If you understand the difference, then you will see that it will actually harm if we changed the status to "confirmed" just because a bug is known to occur.

(In reply to Christoph Feck from comment #37)
> Bugzilla is not a tool for users, but for developers. Ticket fields are
> managed by the bug triaging team or the developers. They are to be read and
> interpreted by developers.
> 
> Regarding the status, think this way:
> 
> Unconfirmed: needs someone who understands the issue and find the code
> responsible
> Confirmed: cause is known or even documented, needs someone to create a patch
> Assigned: someone (or a team) adopted the ticket and creates a patch
> 
> If you understand the difference, then you will see that it will actually
> harm if we changed the status to "confirmed" just because a bug is known to
> occur.

Does that mean users like me should no longer post bugs in here and just post bugs to the distro mailing lists or perhaps only to the distro's bug database? To a user like me, unless the status changes in some way, we have no idea if its even been seen let alone be investigated. Maybe create a status of "Noted". We users that post bugs do feel like a small part of the development process.

(In reply to ianseeks from comment #38)
> Does that mean users like me should no longer post bugs in here and just
> post bugs to the distro mailing lists or perhaps only to the distro's bug
> database? To a user like me, unless the status changes in some way, we have
> no idea if its even been seen let alone be investigated. Maybe create a
> status of "Noted". We users that post bugs do feel like a small part of the
> development process.

As a fellow bug-poster, I understand that it can be frustrating when it seems that a bug affecting you isn't getting the attention that you would like, but we need to respect the developers' process and realize that these guys aren't just sitting on their thumbs. There is an awful lot of bug data for them to sift through, and I would imagine it is easy for bugs like this one to slip under the radar, especially considering it is not major.

Nonetheless, this bug has been fixed, and all because somebody took the time to report it here on the KDE bugzilla. I don't see how reporting it to the distros would have helped anything.

(In reply to S. Christian Collins from comment #39)
> (In reply to ianseeks from comment #38)
> > Does that mean users like me should no longer post bugs in here and just
> > post bugs to the distro mailing lists or perhaps only to the distro's bug
> > database? To a user like me, unless the status changes in some way, we have
> > no idea if its even been seen let alone be investigated. Maybe create a
> > status of "Noted". We users that post bugs do feel like a small part of the
> > development process.
> 
> As a fellow bug-poster, I understand that it can be frustrating when it
> seems that a bug affecting you isn't getting the attention that you would
> like, but we need to respect the developers' process and realize that these
> guys aren't just sitting on their thumbs. There is an awful lot of bug data
> for them to sift through, and I would imagine it is easy for bugs like this
> one to slip under the radar, especially considering it is not major.
> 
> Nonetheless, this bug has been fixed, and all because somebody took the time
> to report it here on the KDE bugzilla. I don't see how reporting it to the
> distros would have helped anything.

All i was asking (generally and not this bug) is that if its been opened and looked at by a dev then make a note on the bug report, how else do you run accurate stats on a system if the data is incorrect. If you read some of the emails in the mailing lists, you'll see some people moaning that a bug has been sitting there for X months or years and assume its been ignored - i was hoping that suggesting changing a status or making a note to say its been seen would halt that moaning email.  I was no way getting at the devs, just trying to help remove some of the nonsense in the mailing lists that imply the devs aren't doing anything.

*** Bug 356422 has been marked as a duplicate of this bug. ***