Description of problem: With kde 4.7 it is not possible to add launcher items that are sub-menus ("Pullup menus") to the kde panel: - creating a launcher item from a top-level menu item (such as "Tools") does not totally fail, but gives a wrong result: the icon that is created in the panel will, when hit, open a dolphin window on the corresponding desktop item hierarchy - not, as it should, a pull-up menu. - creating a launcher item for pulling up some sub-menu further down in the menu item tree ( such as "System Tools" below "Tools") does not even do that: it creates an icon that, when hit, creates an error popup: "Unknown application folder". This feature worked in kde3, became available in kde4.5 (?) again. Please note that adding simple desktop items to the panel does work. Version-Release number of selected component (if applicable): Kde 4.7.1 How reproducible: always Steps to Reproduce: 1. Unlock the widgets 2. Pop up the kde menu 3. Right-click a folder menu-item (top-level like "Tools", or sub-menu like "System Tools") 4. Hit the "Add to Panel" item 5. Check the functionality of the panel item thus created (Creating the panel item by dragging the sub-menu to the panel - an alternative to selecting "Add to Panel" - gives the same result)
Sorry, the version-release is not 4.7.1, but 4.7.3-2
You should report this bug upstream.
Assignee: bugsquad => balcaen.john
KDE Bug 287902 - and Whow, what a long list! amazing that kde still holds together
thanks
Keywords: (none) => UPSTREAMSee Also: (none) => https://bugs.kde.org/show_bug.cgi?id=287902
The reply is not very helpful, probably no follow-up upstream Taking the "works here" reply and the reference to the "Folder view" item (which I do not get) literally: is it possible that there is a question of customisation for Mageia 2? Wait for 4.7.4 (not very promising given "works here")?, wait for other users to report the problem?
I just upgraded to 4.8.1 - the problem is still there. Given the upstream reaction, here are some more details (assuming that the sequence described in the initial report has been done); - the sequence of steps does in fact add an item to the panel - but hitting the icon produces a small error widget: "Unknown application folder" the same sequence of operations works in kde 4.6.5 (Mageia 1) - the image of the icon created is the one the is configured in the desktop menu for the corresponding sub-menu (in kde 4.8 this image is the standard blue folder) - hitting the icon pulls up the desired menu. One thing, however, needs to be clarified: did kde4.8 somewhere introduce a new configuration item that needs to be correctly defined in order to get pull-up menus working? (i.e. is there a similar effect as in bugzilla #3493 ?)
CC: (none) => djmarian4uSummary: Adding menu-items as a launcher in the KDE panel does not work any more => adding menu-items as a launcher in the KDE panel does not work any more
I recently did an upgrade install of Mageia 2 from a customize Mageia 1 system where I have pull-up launcher panel items. Surprise: the pullup-menus were correctly imported into Mageia 2 and work. Conclusion: the bug is not pullup-menu launcher items that don't work in kde 4.8 - they do work -, but a dys-function of the mechanism that interactively creates such launcher items (item #3 and #4 in the sequence of how to reproduce the bug. Looking at .kde4/share/config/plasma-desktop-appletsrc, there is an important difference: - the panel items imported via the system upgrade are of the type [Containments][<mm>][Applets][<nn>] geometry=... immutability=... plugin=simplelauncher zvalue=... [Containments][<mm>][Applets][<nn>][Configuration] icon=... relativePath=J... - while the panel items created interactively from the desktop menu look like [Containments][>mm>][Applets][<nn>] geometry=... immutability=... plugin=icon zvalue=... [Containments][<mm>][Applets][<nn>][Configuration] Url=applications://... Manually editing the plasma-desktop-appletsrc, I can obtain the panel I want - but that is not a solution for the naive user. This is, in a short period of time, the second regression that makes pullup-menu panel items fail - can it be fixed before the official release of Mageia 2?. I will copy this comment to KDE bug 287902
Keywords: UPSTREAM => (none)CC: (none) => lmenut
Just installed kde 4.8.2 - there is some progress: it is now "less wrong": - the "add to panel" operations now create an icon in the panel that effectively pulls up a menu, but this menu is wrong: + this menu does not correspond to the sub-menu item select when the "add-to-panel" was done, but simply is a copy of the "applications" part of the desktop menu + however, the icon appearing in the panel bar is right, it corresponds to the desired sub-menu. Looking at plasma-desktop-appletrc, "add-to-panel" creates an simplelauncher item with the contents [Containments][1][Applets][24][Configuration] icon=/usr/local/share/icons/question.png relativePath=applications://jhmenus/InfoHelp/ The item I had manually created (now done by a script) is [Containments][1][Applets][10][Configuration] icon=/usr/local/share/icons/question.png relativePath=JHmenus/InfoHelp/ the corresponding specification in .config/menus/applications-kmenuedit.menu is at the very beginning of that file, the beginning is <Menu> <Menu> <Name>JHmenus</Name> <Directory>JHmenus.directory</Directory> <Menu> <Name>InfoHelp</Name> <Directory>InfoHelp.directory</Directory> <Layout> <Merge type="menus"/> <Menuname>Micro-ControllerProgramming</Menuname> and there is an empty result if I do find $HOME -name "jhmenus*" - looks like a simple problem of a wrong conversion to lower case.
Correction: I did not watch thoroughly enough, the difference is between relativePath=JHmenus/InfoHelp/ and relativePath=applications://jhmenus/InfoHelp/ More than a bad lc conversion, sorry for this mistake
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
The bug is still present. Recently confirmed by other users in the forum
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
CC: (none) => marja11Whiteboard: (none) => MGA2TOO
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
I just corrected the "version" field from Cauldron to Mageia 2 (see comments 10 and 11) - I am the reporter, not the assignee, and the bug is still valid.
(In reply to comment #13) > I just corrected the "version" field from Cauldron to Mageia 2 (see comments 10 > and 11) - I am the reporter, not the assignee, and the bug is still valid. Somehow correcting didn't work, and that is good, because I wrote a confusing comment 10 Sorry :-[ At that point in time, cauldron and Mageia 2 were the same, so it was a nice moment to check whether the bug was still valid. Of course, valid in Mageia 2 at that point would mean valid in cauldron, too. So version is "cauldron" and we have "MGA2TOO" on the whiteboard to indicate it needs to be solved for Mageia 2 as well.
That is better, thanks (I wondered whether I should feel guilty) This has become a stupid bug. With the work already done upstream (in their last slightly failed tentative to correct the problem) it should be extremely easy to fix - tempting for doit-yourself. But I will not dive into kde packages -> find the right place -> mess around with building a patch, I would very likely break more than I fix: this is for "the professionals".
Still valid with KDE 4.9.97 (Mageia3 Beta2). A second - quite "popular" - bug has now been filed upstream: https://bugs.kde.org/show_bug.cgi?id=297848
Still valid with kde4-config --version Qt: 4.8.6 KDE Development Platform: 4.14.3 kde4-config: 1.0 https://bugs.kde.org/show_bug.cgi?id=297848
CC: (none) => nic
Keywords: (none) => UPSTREAM
Source RPM: kdebase4-runtime-4.7.3-2.mga2 => kdebase4-runtime-4.14.3-5.mga5Whiteboard: MGA2TOO => MGA4TOO
Mikala went MIA, re-assigning
Assignee: balcaen.john => mageia
Specific to plasma4, so Mageia 5 only.
Version: Cauldron => 5
Assignee: mageia => kde
CC: lmenut => (none)
Hi Juergen, Thank you for having taken the needed time to report this issue. We regret if this issue didn't get fixed! Closing as OLD, because Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed. Marja
Status: NEW => RESOLVEDResolution: (none) => OLD