Version: 2.7.5 (using KDE KDE 3.5.5) Installed from: Compiled From Sources Compiler: Target: i686-pc-linux-gnu OS: Linux (i686) release 2.6.20-gentoo-r4-20070330 Yakuake needs to offer an option to paste a path when given a file:// URL via the clipboard. (because KDE apps copy URLs to the clipboard and it's a pain to back up to the file:// and delete it)
The terminal context menu is handled by the Konsole KPart, not Yakuake - reassigning.
There isn't any more room on the context menu. I think this would have to go in the main Edit menu.
That would make it useless to Yakuake. I never use Konsole as a standalone app.
> That would make it useless to Yakuake. I never use Konsole as a standalone app. I'm sure I can find a way to share the functionality. In the past Konsole used to do the URL -> path conversion automatically for local URLs, but there was a bug report complaining about the "file:///" part being stripped off and so it was removed. Personally I think the old behavior (converting local URLs to paths) made more sense most of the time.
Hmm. Maybe some kind of preferences toggle added to the set that Yakuake's "Use Konsole's Settings" toggle mirrors.
Note that Yakuake doesn't have a "Use Konsole's Settings" toggle anymore in the KDE 4 version. The KPart context menu is now composed differently, allowing to pick and edit a Konsole profile. The context menu of tabs on the tab bar exposes the same edit action, and the main menu brings access to Konsole's "Manage Profiles" dialog. Personally I'm much happier with those new semantics and the new UI; the over-boarding KPart context menu of yond (along with Konsole's similar "Settings" menu) felt rather ad-hoc and cluttered.
There are some related reports: http://bugs.kde.org/show_bug.cgi?id=128421 (RFE: "Copy and Paste" option) http://bugs.kde.org/show_bug.cgi?id=89299 (RFE: "Avoid pasting new line characters") One option would be to combine these in a "Paste Special" menu.
I like the sound of having Yakuake's configuration UI reworked, and I like the idea of a Paste Special menu, but I'd still want a configurable default action. I paste using the selection (middle click) 99% of the time because it's quicker and easier. (And I don't set Klipper to tie the clipboard and selection together because I like having two clipboards)
You may have misunderstood slightly, though: The context menu of the terminal in Yakuake is provided by Konsole code, not Yakuake. I.e. Yakuake's "configuration UI being reworked" is a consequence of changes to the Konsole KPart in KDE 4.0, and not a Yakuake initiative (in fact Yakuake's own config dialog is slightly different in the KDE 4 codebase as well, but that has no bearing on terminal settings). Also the KPart does offer a couple of new interfaces to bring up configuration dialogs belonging to Konsole these days, which Yakuake makes use of to expose them in menus it does own (tab context menu, main menu). As for pasting, in the KDE 3 version of Yakuake it used to have its own paste actions which worked by using the sendInput() method of the terminal interface to get the clipboard contents into the terminal. In the KDE 4 version I've decided not to shadow Copy/Paste in Yakuake, since the respective KPart shortcuts actually work now and dealing with shortcut clashes between Yakuake and the KPart is an unopened Pandora's box so far*. * = Reminds me of the time I tried to recreate the warning about defining CTRL-using shortcuts from Konsole in Yakuake with the option to ignore it and define it anyway (as in Konsole), which eventually failed because I couldn't stop the KPart from eating them, as it actually reimplemented the method that is responsible for executing event filters on QObjects to expressely remove all event filters, as part of the same scheme. The irony was bitter.
Looks like this is one of those cases where I'll just have to take your word for it until I get a chance to test it out myself. (History has shown that the alternative is for me to complain about things I don't fully understand, make a fool out of myself, and then end up liking over half of them anyway)
> * = Reminds me of the time I tried to recreate the > warning about defining CTRL-using shortcuts I'm pretty sure I took most of the event hacks out of the terminal widget. It should act more or less like a QTextEdit now in terms of exceptions to normal QWidget keyboard event handling.
closing this for now due to age/lack of interest