Version: (using KDE KDE 3.1.2) Installed from: Unlisted Binary Package You can configure toolbars, why not context menus ? You can add new items using the service menus. But it is impossible to remove anything that bother's you. For exemple, when managing files, i NEVER use from the context menu: Up/Back, Find file, Open New Window... And they are still on my way to the items I need. At the beginning the context menus where simple. But with new versions, more and more items have been added to Konqueror's menu. They bring new features, but also more clutter. Lot of people complain that the menu is cluttered, or that the feature they want is not there: http://bugs.kde.org/show_bug.cgi?id=53772 http://bugs.kde.org/show_bug.cgi?id=63205 It is time to allow the user to take control on that: *we need configurable context menus !* I propose a simple solution: Implement a hidding mecanism, like the one in the KDE menu. You just select the items and submenus you don't want to see, and they don't disturb you anymore. For a start, user may have to edit some text file, like /usr/share/apps/konqueror/konqueror.rc A gui needs only to come in a second time, although I guess it could be very similar to the one used for KDE menu. A longer term, and more powerful approach would be to have some kind of profile, for different uses. For example, I don't need "Add to Bookmarks" when doing file management, but use it when browsing. The context menu would be build on the fly, according to the context, and to the users preferences.
dup of #50019 ?
They both claim for being able to customize the context menu. - this bug is about disabling the static items, may it be with or without a GUI. - bug #50019 is more specific about a GUI to edit/add/remove/disable the context menus items.
I find good the profile suggestion, but perhaps it has to bé quite diferent. I don't need Cervisia features, and don't need too two copy / move options. And I really hate these full-featured menues where you need to seek 3 times to find what you want. Perhaps a menu-profile option will be really useful : A simple menu profile, a extended menu profile, a developer menu profile, and a customized menu profile. I guess it will bé a good idea. Althoug, go ahead with this great desktop ! best wishes !
*** Bug 77450 has been marked as a duplicate of this bug. ***
Read the bug #77450 http://bugs.kde.org/show_bug.cgi?id=77450 . I have given some suggestion in how to implement it. The most important point to remember is that people NEED NOT DO IT MANUALLY. it should be done easily by right click **right at the place**.
You can delete the "share/apps/konqueror/servicemenus" and "share/services" files that you dislike. KDE should have less service menuentries by default. KDE is not the only GUI with this problem, look at MS Windows. Every app (cd-burning, packaging) adds entries to this menus. They can be disabled by removing entries in the registry.
> Every app (cd-burning, packaging) adds entries to this menus On Windiws, I like WinRar cause it creates one submenue and places all items to it
I don't know why people are behind a very specific type of configuration of context menus. Why not to make it much more broader. The configurable cotext menu should go into KDELIBS instead of konqueror. There are many application where we don't want many options in context menus. The generic approach of #77450 would finish the trouble of configuring the context menu. In fact this can be done in QMenudata(or KDE equivalent). So that even menu options from menubars are customizable. Make it generic and dependent upon developers thinking if they want specific menus to be configurable or not. And yes how about dynamic menus dependent upon how much it is used ala windows. And yes don't replicate the feature of windows which are bad.
*** Bug 78705 has been marked as a duplicate of this bug. ***
i agree with the suggestion that configurable context-menus should be added to the kdelibs rather than any specific application. this would maintain the consistent interface which is one of KDE's great strengths. it may not be easy to make a change to the core libraries, but if this feature were added, i really think it would be the single greatest possible improvement in KDE's overall usability - without removing any of the features people want - and adding the power for users to set things up the way they want. it would also open up new ways of using profiles at the level of user-logged-in, virtual desktop or application, to make the GUI more tuned to the user. one reason i choose to KDE because it doesn't rob me of features, but i have to admit that the interface is so full of features that they get in my way sometimes. i would rather not see all of the features all of the time. obviously not all features users want can be included at once, so currently, developers have to make hard choices about what gets left out. i have updated my system to be disappointed by the choices that have been made. but i accept the choice had to be made to avoid bloat. configurable menus would be a way to avoid bloat without disappointment. getting to specifics: a simple way for the user to edit the menu would be: right click to bring the menu up, then depress CTRL before left-clicking anywhere on the menu to bring up a dialog exactly like the "Configure Toolbars" dialog. this lets you to move the possible menu items between the <Available> and <Current> columns or higher and lower in the menu with the arrow-labelled buttons. other people will have other ideas as to how to do it ... one last thing: i also agree that ms-windows style menus that reorganize themselves to suit your "preferences" are a no-no. i found them very annoying because (although i am not a big fan of ideas like the "spatial nautilus") i tend to remember menu and toolbars spatially, and waste time looking for menu items when they move around.
Yes, we should be able to edit all menu, even main menu files. I think that KDE Menus are "overcrowded" ; maybe some preferences that are in menu files should be in dialogs ?
when using Konqueror, it would be nice if a user's choices about which menu items to display were specific to each "View Profile" ... WebBrowsing, FileManagement, etc ... in other words: were saved when using "Save View Profile" under the "Settings" menu ... it would also be nice if a "View Profile" feature was part of the kdelibs, so it could be made available in applications like text-editors or word-processors ... different toolbars or menu-items are required for editing program code than for writing a letter ... ... the same would be true in an image/photo editing program ... ... or any application where a different selection of the availble tools are needed for different tasks ... i guess that's pretty much any application ...
I want to fix this wishlist, as it is also my wishlist. I would like to have comment of experienced KDE developers on the approach. The patch would certainly be not specific to konqueror, but a generic kdelibs patch. Not all KPopupMenu should be made configurable, because they are used everywhere. this would be a nuisance. So I want to leave it to application developers,if they want configurable context menu. For this there will a API. 1. This, I think, will be the most ugly hack. Have a makeConfigurable() method in KPopupMenu. This would make possible for all types of kpopupmenu configurable. The main problem with this approach is that, there is no way to uniquely identify any entry, as insertItem() can have same texts associated with it. Identifiers are already optional. 2. This one, IMHO, is the best solution. Make a new class KContextPopupMenu derived from KPopupMenu(with protected attribute). By default this would be configurable. Ony KActions could be plugged to this class, no direct insertitems(). and configuration would be like configure toolbar, which is at present(with all actions present). Right now, KDE encourages developers to use XMLGUI framework for even context popupmenus. XMLGUI framework can use KContext PopupMenu. any comments??
After study of KXMLGUIClient, I have settled for this. The configuration for context popupmenu would be described by an XML file(just like right now done in KHTML). KContextPopupMenu would be "public" derived from KXMLGUIClient and KPopupMenu. I will make this an option in API to setXML file by either programmer, or auto-create.
Vinary: I am not sure how well this would work, but I feel that the manner of interacting with the system should remain consistent. With that in mind, either the .desktop method (from konq) or an XML style (from KXMLGUI) should be chosen and stuck to. In either case, however, the decision should be made by the core dev team if this is a feature requested for kdelibs. I recommend talking to them before implementing anything.