Version: (using KDE 4.2.0) Installed from: Ubuntu Packages I reported bug 184890 just now. This one is related but not the same. Whenever a KPart is used inside Konqueror to open (preview) a file, I suggest that the menu and toolbars corresponding to the KPart alone (including entries in Settings like Configure Editor) are placed *inside* the tab which uses that KPart. Thereby it is very clear to users that those items are specific to the file previewed. Otherwise, when the KPart adds its menus and toolbars to the already existing ones, the structure of the menus change and thereby that uniformity of the menus which we rely on for quick usage. (My hand is trained to press up-arrow so many times to reach this menu item and press Enter, and things like that and I am sure I'm not the only one). Similarly, when icons are added to existing toolbars, to see them sometimes the toolbars need to be extended (i.e. you have to press a button to reveal the remaining unseen icons). Without knowing this we end up spending time looking for the icon (and in fact the popdown showing the extra icon disappears before I can move my laptop's touch pointer to that place). However if you put a separate toolbar within the relevant tab, it is also clear where to look for the icons and easier to access. Further, attention must be paid to avoiding conflicts between hotkeys and shortcuts used by Konqueror and the KParts used by it. If I need to report that as a separate bug, I am willing to do so.
Take a specific case in question. I list the silly things that happen if a text file is opened inside Konqueror using Katepart, * The File menu now has two Print items. * There are two Bookmarks menus as reported in bugs 184890 and 175275. * Hotkeys Ctrl+T and Ctrl+S, both very basic hotkeys, become ambiguous and therefore useless. (Ctrl + T inside Katepart apparently points to Transpose, and in Konqueror it is Open Tab. Ctrl + S means Save As in Katepart and Focus Searchbar in Konqueror.) * other such things IMHO such uncleanliness would be avoided if there were separate menus and toolbars. As regards hotkeys and shortcuts, I have the following suggestion to make: I take the analogy from virtual machines. When there is a guest OS running inside a host OS, we press Ctrl + Alt (or some other such hotkey) to "come back" or return control from the guest OS to the host OS. Without this, once the user has clicked inside the guest OS window, the guest OS captures all mouse movements and keystrokes. Similarly, I visualize the KPart as a "guest" sitting inside Konqueror which is the "host". We open a KPart with a purpose, to perform a certain activity. So logically that activity should take precedence. So any hotkey to open a certain menu item or shortcut to perform a certain action must default to whatever is applicable in the guest (KPart). To "return control" to the "host", press Ctrl + Alt (or even make this shortcut configurable in the host's Configure Shortcuts menu -- but how to ensure that such a shortcut will not exist in the KPart's shortcuts list?) and as a visual indication, you get the first menu item of the host focused. After that press whatever hotkey or shortcut related to the host, and it works as it would in the host without conflict. To ensure cleanliness and uniformity, even those hotkeys and shortcuts which are NOT used in the guest but are present in the host will NOT work until Ctrl + Alt is pressed, even though there is no conflict.
*** Bug 144213 has been marked as a duplicate of this bug. ***
Hello. The older bug 144213 whose newer version this is was reported over two years ago. Please look into this issue seriously and with high priority. Recently I switched fully from Kubuntu Hardy using KDE 3 to Kubuntu Jaunty using KDE 4 and every few minutes while using Konqueror I run into this problem. I am sure I am not the only person facing this problem. So please please please look into this. It seriously kills usability of Konqueror. O ye developer gods, I prithee, have mercy!