(*** This bug was imported into bugs.kde.org ***) Package: kicker Version: 0.1 (KDE 1.90 Beta >= 20000517) Severity: wishlist What would be very nice is if you could right-click on a menu entry in the K-menu and get a popup that let you edit the menuitem add it to your panel etc - it's very disconcerting to right-click on a menu item and have it launch.
The popup is already there. But think you should be able to rename the items. This would make some things much easier
> The popup is already there. I can't see such a thing in KDE 3.0.2 (SuSE). At least I would like to see the path of the application to which the menu entry points (maybe as a "tooltip" that appears on mouse-over as in Win98), because often I'm really interested in the name and path of the program that will be launched by the menu entry. E.g., I had the situation where I had two versions of OpenOffice installed, but in the menu I never knew which one was which. A context menu appearing on right click on a menu entry would of course be better. It should show the same context menu entries as right-clicking on .desktop-symbols on the desktop.
Basic features like this help newbies to change over to Linux from Windows, no matter how stupid it may look. I am hoping to see this in KDE 3.2
It is not implemented in CVS 2003-07-10 yet...
*** Bug 53048 has been marked as a duplicate of this bug. ***
*** Bug 62776 has been marked as a duplicate of this bug. ***
yes and i really hope if editting (i.e. changing the order of) an entry in k menu can be done by click and move insted of *only* by the editting programe supplied by kde also adding an entry to k menu (e.g. an icone in the desktop get clicked on "just highlighted" and draged to k menu to be added where the click would be released. i hope i was clear....
Sorry for the repeated entry up there.... One more thing would be great.......the auto hide feature of no used links in the k menu.....similar to what happens in win2k and winxp......
Please no. The "autohiding" feature is one of the most annoyning in all of windows ideas (at least personal opinion). If this hiding is implemented, please do not make it default.
I would like to participate in the redesign of Kmenuedit or any menu editing programs.
since kde is about the power of choice I would say an option in k control center to either enable the autohide feature or disable it ....so every body is happy
*** Bug 67822 has been marked as a duplicate of this bug. ***
The bookmark menus in Konqueror now do that.
I agree that this woould be a great change to make. KDE is remarkably powerful and flexible. But this 'feature' is what I miss from Windows; the abiilty to copy an item from the menu and copy it to desktop or panel. It is time consuming and frustrating to have to create a shortcut froom scratch and the menu editor is long winded. I am currently using 3.15 Roll on 3.2 Thanks Richard
I am changing this to bug status. It is NOT correct behaviour to start an application if the user expects to get a right click menu (like in Windows+Gnome). Also right clicks NEVER start anything according to the KDE style guide, see http://developer.kde.org/documentation/standards/kde/style/mouse/index.html This is a bug at least until the starting of applications via RMB is removed. Ideally, one should be able to edit an entry using a RMB menu.
Doesn't start anymore with RMB.
Much better! But is it that hard to enable drag&drop in menus? I mean, isn't that already or do you need to subclass and implement?
There should also be a properties entry in the RMB context menu for the K-menu that allows us to change the icon (and other properties similar to all the other buttons on the kicker). For example, I can click on an application button and get a properties dialog that lets me change the icon, etc., but there is no equivalent ability for the K-menu (also does not exist, as far as I've been able to find, in configure taskbar, configure panel, or configure menu dialogs).
> There should also be a properties entry in the RMB context menu for the K-menu that allows us to change the icon (and other properties similar to all the other buttons on the kicker). For example, I can click on an application button and get a properties dialog that lets me change the icon, etc., but there is no equivalent ability for the K-menu (also does not exist, as far as I've been able to find, in configure taskbar, configure panel, or configure menu dialogs). That is a seperate bug and should be reported to another bug report.
*** Bug 78436 has been marked as a duplicate of this bug. ***
Because Bug 78436 even though I think it is only related here is my wish again: Version: (using KDE KDE 3.2.1) Installed from: Gentoo Packages i'd like to have not only rightclick but free configurable mouse-actions for k-menu. thes actions could be: * run app * edit entry * hide menu ( i really like to see that - fluxbox style... ) * make sticky * run app but don't hide menu
*** Bug 81886 has been marked as a duplicate of this bug. ***
Are there technical or political reasons for the fact that this bug is around for 4 years and 1329 votes now and still has the status "New"...? I think many many people would like to see this useful feature in KDE.
*LOL* Fuck...who the hell knows? Maybe the developers are high on acid...and they are hallucinating a supposed group of users that *actually use* the menu editor voluntarily. ;)
I really agree with you guys. Could some devel tell us why this is not implemented? Tech impossibility? Too difficult? ???
Maybe it's because *gasp* it'll make that damned menu editor worthless? Maybe I'll go perusing through some source code.
> Could some devel tell us why this is not implemented? The devels are being underpaid. Feel free to contract one to implement it. Or have a look into the KDE 3.3 feature plan what a future KDE version will contain.
> Or have a look into the KDE 3.3 feature plan what a future KDE version will contain. right Sam.. http://developer.kde.org/development-versions/kde-3.3-features.html ..K Menu: Context menus to edit entries, drag&drop to arrange entries (wishlist #4229) Sandro Giessl <sandro@giessl.com>..
Honestly guys...I hate to laugh, but this has got to be one of the coolest KDE bug reports I've ever participated in!!!! You're all wonderful!
Bug 82164 depends on this bug.
Am Sunday, 23. May 2004 10:31 schrieb Jozef Riha: > > Or have a look into the KDE 3.3 feature plan what a future KDE > > version will contain. > > right Sam.. > > http://developer.kde.org/development-versions/kde-3.3-features.html > > ..K Menu: Context menus to edit entries, drag&drop to arrange entries > (wishlist #4229) Sandro Giessl <sandro giessl com> I would love to implement this feature, but as it's more difficult to implement than I expected, I'm about to give it up. I'm sorry...
Quoting Sandro Giessl <sandro@giessl.com>: > ------- You are receiving this mail because: ------- > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=4229 > > > > > ------- Additional Comments From sandro giessl com 2004-06-03 21:19 ------- > Am Sunday, 23. May 2004 10:31 schrieb Jozef Riha: > > > Or have a look into the KDE 3.3 feature plan what a future KDE > > > version will contain. > > > > right Sam.. > > > > http://developer.kde.org/development-versions/kde-3.3-features.html > > > > ..K Menu: Context menus to edit entries, drag&drop to arrange entries > > (wishlist #4229) Sandro Giessl <sandro giessl com> > I would love to implement this feature, but as it's more difficult to > implement than I expected, I'm about to give it up. I'm sorry... > Borrow the code from Konqueror bookmark management.
On Friday 04 June 2004 10:37 pm, Thomas wrote: > Borrow the code from Konqueror bookmark management. Why don't you just impliment a "kmenu view" in konqueror, and just use that as the kmenu? Andrew
For that matter, why not just use konqueror to edit the menu all together, design the menu to be editable as files are. (like in windows.) Then all you would have to do (for now) is implement properties, and delete in the right click, and allow the user to reorder them.
I agree dnd of menu entries by mistake could be confusing for beginner users. But at least the right menu for entries is safe and useful. Perhapse you even can add a "Move <<MyApp>>" as we have under kicker handle menus. As we *not often* move entries (and to be honest the KMenu is very well organized (not as the comercial oriented Start menu of MS Windows) I find this solution very convenient and users cannot move/remove entries by mistake (and as a bonus they Know how to move entries because it's said directly in the RMBmenu). To summarize : - Left click an entry : launch app - Right click : a popup menu for the item as it would appears in Konqueror for the associated .desktop file - PLUS an entry "Move <<The app name/description>>" that enable/start drag and drop over KMenus. - Dnd an entry from KMenu works as before : it drag a COPY of the entry that can easily be droped to desktop/kicker - But as it is a copy users never move/remove items by mistake. What about this solution ?
Yes. DnD of menu entries is a really bad idea, at least just by dragging them. I've seen so many people (esp. older people) accidentally drag something off the windows menu or drag one application onto another when they meant to click on it. I think the most important feature is to add a right click menu to the entries so you can delete them. Implementing Dnd of the menus (via a RMB option) is not as critical I think.
One comment to add to Sebastien, when you mean "[...] it drag a COPY of the entry [...]", please take in consideration that moving to Trash is different and should be understood as move, otherwise you'll NOT delete the file. This miss behaviour (copy to trash instead of move) is present in other places, like the kicker. They must be fixed. (see bug:80247)
Right click: Popup menu Copy: put menu entry into buffer Cut: put menu entry into buffer and delete original ( also functions as remove ) Paste: put the menu entry that is in buffer here Import: get a good copy of single application or entire menu from another user Export: save a copy of a single application or entire menu These are the functions needed to make the feature complete and safe.
Implementing the proposals made in this BR, especially those in #34 and #35, is indeed "difficult" or doesn't seem to be feasible to me. Unlike the windows start menu the K menu is _not_ implemented as a directory structure. Instead it is implemented with so-called "virtual folders" which could be compared to (try googling for) "database views". Database views are predefined queries that can be accessed like tables, except that they are normally readonly. Any modifications are normally done in the underlying tables. The virtual folders are now prepared as follows * There is a store (table) of all menu entries' .desktop files (rows) situated under KDE-PREFIX/share/applications. * Each of those files has a number of key-value pairs (columns) in it - defining, for example, the name or icon path of the menu entry. See the "Desktop Entry Standard" at http://freedesktop.org/Standards/desktop-entry-spec, section "Recognized desktop entry keys" for a list of other keys. * A (sub)menu, as you see it in K menu is the selection of menu entries (rows) by the basis of the key (column) values. * The (all applications part of the) K menu is a collection of such selections. These selections are specified in KDE-PREFIX/etc/xdg/menus/applications.menu. Their results, the (sub)menus, aren't stored. Instead when KDE is started those selections are performed among all menu entries and the result is displayed by K menu. There may be a cache in the process to speed things up however. Now we can see that hand-editting the K menu is like editting the results of a database query. This is possible to simulate, which is hard to do properly (as the menu editor shows ;-). The better thing to do would be to guess why users would drag menu items around and provide means to automatically satisfy the needs they want to satisfy by hand. In other words adjust the selections for the menus. Example: I want items I often use appear first in a menu. Solution: Count application invocations and sort descending by number of them. Following the database analogy this would be easy. I don't say this is already possible with the K menu, but the "virtual folders" concept would be good for it. And so on. The assumption is that nobody drags around menu items just for fun but that a general rule can be stated. Otherwise "virtual folders" are not suitable.
*** Bug 82181 has been marked as a duplicate of this bug. ***
It would be best if every user could have his own copy of KDE-PREFIX/etc/xdg/menus/applications.menu that would if it existed override the standard one. That way the menu editer could just edit their local applications.menu instead of trying to create a file to post process the standard applications menu. If a user destroyed his applications.menu, then the system administrator could just remove the user's application.menu.
*** Bug 57618 has been marked as a duplicate of this bug. ***
*** Bug 79622 has been marked as a duplicate of this bug. ***
CVS commit by binner: Add menu context menus with "Edit Group" respectively "Edit Item" entry which launch the KDE menu editor and preselect the selected group/item. CCMAIL: 4229@bugs.kde.org, bastian@kde.org M +58 -4 service_mnu.cpp 1.77 M +5 -0 service_mnu.h 1.29 --- kdebase/kicker/ui/service_mnu.cpp #1.76:1.77 @@ -35,4 +35,5 @@ CONNECTION WITH THE SOFTWARE OR THE USE #include <klocale.h> #include <kmimetype.h> +#include <kprocess.h> #include <krun.h> #include <kservicegroup.h> @@ -58,5 +59,5 @@ static RecentlyLaunchedApps s_RecentApps PanelServiceMenu::PanelServiceMenu(const QString & label, const QString & relPath, QWidget * parent, const char * name, bool addmenumode) - : KPanelMenu(label, parent, name), relPath_(relPath), clearOnClose_(false),addmenumode_(addmenumode) + : KPanelMenu(label, parent, name), relPath_(relPath), clearOnClose_(false),addmenumode_(addmenumode), popupMenu_(0) { readConfig(); @@ -503,10 +504,65 @@ void PanelServiceMenu::mousePressEvent(Q void PanelServiceMenu::mouseReleaseEvent(QMouseEvent * ev) { - if (ev->button()==RightButton) + if (ev->button()==RightButton && kapp->authorizeKAction("menuedit")) { + int id = idAt( ev->pos() ); + + if (id < idStart) + return; + + if (!entryMap_.contains(id)) { + kdDebug(1210) << "Cannot find service with menu id " << id << endl; + return; + } + + contextKSycocaEntry_ = entryMap_[id]; + + delete popupMenu_; + popupMenu_ = new KPopupMenu(this); + connect(popupMenu_, SIGNAL(activated(int)), SLOT(slotContextMenu(int))); + + switch (contextKSycocaEntry_->sycocaType()) { + case KST_KService: + popupMenu_->insertItem( SmallIconSet("kmenuedit"), i18n("Edit Item") ); + break; + + case KST_KServiceGroup: + popupMenu_->insertItem( SmallIconSet("kmenuedit"), i18n("Edit Menu") ); + break; + + default: return; + break; + } + + popupMenu_->popup( this->mapToGlobal( ev->pos() ) ); + + return; + } KPanelMenu::mouseReleaseEvent(ev); } +void PanelServiceMenu::slotContextMenu(int) +{ + KProcess *proc = new KProcess; + *proc << KStandardDirs::findExe(QString::fromLatin1("kmenuedit")); + + switch (contextKSycocaEntry_->sycocaType()) { + case KST_KService: + *proc << "/"+relPath_ << static_cast<KService *>(contextKSycocaEntry_)->menuId(); + break; + + case KST_KServiceGroup: + *proc << "/"+static_cast<KServiceGroup *>(contextKSycocaEntry_)->relPath(); + break; + + default: + return; + break; + } + + proc->start(); +} + void PanelServiceMenu::mouseMoveEvent(QMouseEvent * ev) { @@ -533,6 +589,4 @@ void PanelServiceMenu::mouseMoveEvent(QM KSycocaEntry * e = entryMap_[id]; - KService::Ptr service = static_cast<KService *>(e); - QString filePath; --- kdebase/kicker/ui/service_mnu.h #1.28:1.29 @@ -106,5 +106,10 @@ protected: PopupMenuList subMenus; +private slots: + void slotContextMenu(int); + private: + KPopupMenu* popupMenu_; + KSycocaEntry* contextKSycocaEntry_; void readConfig(); };
Also added menu entries to add menu/item to the main panel. This fulfills the reporter's wish. :-)
Hi agree with the Author of this Bug. I know you will feel this "windows-ish", but it is not, it is simply a usability question. When you want to move or edit a KMenu entry, you are likely to be selecting it currently. This is "counter-productive" to have to open KMenuEdit by right clicking on the KMenu, select KMenuEdit, browse again to reach the item, make the change, click File > Save, click File > Exit. Moreover a good integration with the KMenu applet (through contextual menu) would permit to change the default sort order which is boring... Go on with your good work ! :-)
Hi agree with the Author of this Bug. I know you will feel this "windows-ish", but it is not, it is simply a usability question. When you want to move or edit a KMenu entry, you are likely to be selecting it currently. This is "counter-productive" to have to open KMenuEdit by right clicking on the KMenu, select KMenuEdit, browse again to reach the item, make the change, click File > Save, click File > Exit. Moreover a good integration with the KMenu applet (through contextual menu) would permit to change the default sort order which is boring... Go on with your good work ! :-) At KDE 3.3.1 i cant find any changes for this.... is it impossible to integrate it like in the Windows Startmenu ? So i think this Wish has to be reopened..
You don't have to select it yourself in the menu editor, it gets selected. > At KDE 3.3.1 i cant find any changes for this KDE 3.3.x is feature frozen. It will be in KDE 3.4.
So, this is obvious that you won't see any reason not to reopen this wish. Thank you :)
Does this include to drag and drop entrys in it by holding the left Mousebutton ?
Within the menu editor yes. It has been decided against to duplicate its functionality in the panel menu.
Why ?? That´s the most needed Feature at this Wish !! *shocked*
Simply stated : if the menu editor is abstracted correctly - which is a typical computer scientist/hacker skill - this would become easily feasible to have a single component being both the K menu representation and the menu editor at the same time. Moreover, this can easily become a fully configurable item which would have its own style support, providing means to put custom "K" menus everywhere, depending on the context, ... Its current integration in Kicker is just a "Kicker integration", not a "Desktop integration The menu editor suffers many (tons of) usability issues, glitches. Its design is exactly what one would do when PROTOTYPING a TEMPORARY menu editor. This is simply unacceptable in an integrated desktop environment as targeted by the KDE Project. Thank you for your attention and the wise comments I am sure you will write. Created an attachment (id=8304) public_key.asc
Drag and drop? Reading the wish title and the original poster you must be talking about another report.
> Simply stated : if the menu editor is abstracted correctly - which is a typical computer scientist/hacker skill - this would become easily feasible Simply read you want to state that those doing the work are just incapable? > The menu editor suffers many (tons of) usability issues, glitches. You have done against this what? Report number? Which thread on kde-usability? > Its design is exactly what one would do when PROTOTYPING a TEMPORARY menu editor. Feel free to show your design/implementation. :-) PS: I haven't designed neither.
@Binner: Is it just me or didn't he try to support your argument? I understood his post as an answer to redlabour's question. I really do not understand why you are attacking him nor does such a reaction help anybody here anyway. But, well, perhaps you've just had a bad day...
Thx 'rgpublic' that is exactly what i want to say. @all - (quote) ------- Additional Comment #56 From Stephan Binner 2004-11-16 22:51 ------- Drag and drop? Reading the wish title and the original poster you must be talking about another report. (quote) Yes, Binner i tried to - but it was marked as a duplicate of this one ... ;O) So here is my new one. http://bugs.kde.org/show_bug.cgi?id=93425
Le mardi 16 Novembre 2004 23:02, Stephan Binner a écrit : > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=4229 > > > > > ------- Additional Comments From binner kde org 2004-11-16 23:02 ------- > > > Simply stated : if the menu editor is abstracted correctly - which is a > > typical computer scientist/hacker skill - this would become easily > > feasible > > Simply read you want to state that those doing the work are just incapable? It is too easy to tell that if someone made a mistake then (s)he is just incapable, don't you think ? Maybe, a better way is to tell the developers their mistakes so they can correct them... and I think that this is just the purpose of this mailing list system. > > The menu editor suffers many (tons of) usability issues, glitches. > > You have done against this what? Report number? Which thread on > kde-usability? I am reporting lots of things, voting for bug repots and so on. I don't need to deserve it to be allowed to tell what's wrong. This is simply the application of the freedom principle in "Free Software". Don't you agree ? > > Its design is exactly what one would do when PROTOTYPING a TEMPORARY menu > > editor. > > Feel free to show your design/implementation. :-) I am currently designing a mockup, but my skills at drawing are poor and I don't have a lot of free time (master thesis prototype to do) but don't cry, I will finish it. As I told it, such a thing - I mean a KDE feature which is used so often - needs a lot of wise thoughts. > PS: I haven't designed neither. Perhaps, you could make constructive things while destructing people's comments. Regards,
I think Stephan Binner's fix in comment 45 is perfect. There is no point in duplicating the menu editor's functionality or reworking the entire menu just to support a step backwards in useability like DnD in the menu. Thank you Stephan!
Are you guys really that supid? Do you think all the intrest in this bug is because it would be a "Step Backward"? What kind of anti-depressants does it take to make a good idea into "too much work" and somehow magically evolve into "a step backwards"? Common guys. I mean, I know that I'm useless, but I wouldn't expect this from professional coders, and especially not from brinner and kulow. If you want to fuck this bug off, then lets hear your arguments. I can't just take your word for this, when I was one of the ones who saw the virtue of this idea as soon as it was posted. Thanks.
> > ------- Additional Comments From landrews nbnet nb ca 2004-11-28 20:53 > ------- Are you guys really that supid? > > brinner and kulow. If you > want to fXck this bug off Please do not call people stupid or use the F word. If you treat Brinner and Kulow in a civilized manner, then someday they may get their act together and correctly fix this bug. To Brinner and Kulow, I wish to apologize for the use of improper language by another person following this bug.
Re comment #62, if you really want the feature, I am sure that someone would be willing to implement it if you paid them to do so. Not willing to pay for it? Then you have no right to complain and swear at a large number of people who work on KDE for their enjoyment as a _volunteer_.
Especially as the first hit of my name _is_ in #62
Go on http://www.mega-tokyo.com/osfaq2/index.php/MartinBaute/Scratchbook and seek at the end "The 1.0 Warranty"... read it and rework your point of view. I think that if someone can't implement/resolve a bug report, it has to stay opened until someone implements/resolves it. Democracy is when a programmer creates a patch for something and everyone say if (s)he finds it good or not ; dictatorship is when one or two people say "stop wanting to do that !". Where is the freedom here ?