Bug 253173

Summary:	"Description" and "Name" are interchanged
Product:	[Plasma] plasma4	Reporter:	naraesk <mail>
Component:	widget-kickoff	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED DUPLICATE
Severity:	minor	CC:	bjoern, cfeck
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:

Description naraesk 2010-10-04 00:39:28 UTC

Version:           unspecified (using KDE 4.5.1) 
OS:                Linux

I use the classic version of KMenu. When choosing "Show name" in the option dialog, the name of the application is shown in KMenu. If I choose "Show name" the discription is shown. 

Description and Name are set correctly in the menu editor. This is always reproducable and effects all menu entries.

Reproducible: Always




I can reproduce this in English and German. I just checked it with an other language to make sure it is not any translation mistake.

Comment 1 Björn Ruberg 2010-10-16 19:46:16 UTC

Cannot reproduce in KDE 4.4 and trunk. All settings are applied - although some names make the impression of being descriptions

Comment 2 Christoph Feck 2010-10-18 02:03:49 UTC

This bug is still present (in trunk). It was caused by a (wrong) fix to the bug that the special handling of "games" category introduced (instead of reverting that handling).

For example, when I select "show names only", I get funny long descriptions instead of names in Favorites and Logout menus.

Comment 3 Björn Ruberg 2010-10-18 11:33:56 UTC

I see the behaviour in trunk as correct. There is probably some misunderstanding in what exactly "name" is. It is (in kickoff) actually not the name of the binary, but the string that is entered under "name" in the corresponding .desktop file. I think that kickoff does it right.l

Comment 4 naraesk 2010-10-18 13:50:53 UTC

According to the menu editor:

Name: Kopete
Description: Instant Messenger

And "Instant Messenger" is shown, when only names should be displayed.
With description only "Kopete" is shown. Definetly not the expected behaviour.

Comment 5 Christoph Feck 2010-11-15 13:11:45 UTC


*** This bug has been marked as a duplicate of bug 254484 ***