Summary: | Option to return copy behaviour to pre 1.2 | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | chris-kde |
Component: | general | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | krustev |
Priority: | NOR | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
chris-kde
2003-02-03 05:33:54 UTC
I suspect it'll take a lot of convincing to break a standard. :-) http://www.freedesktop.org/standards/clipboards.txt PS! I would also like to see selection copy. Yeah... 1.2 is completely unusable for me because of this new 'standard' copy behavior. There should be an option to get the old style back for those who want it. It's even worse because the 'other' standard ctrl-c/ctrl-v of course doesn't work either. OK, here's a patch to get the old behavior back. It just enforces the old-style auto-copy to clipboard. Of course it would be nicer to have an option for turning this on and off somewhere in the preferences menu... TEWidget.cpp, somewhere around line 1065, looks like this: 1065 if ( actSel > 1 ) 1066 emit endSelectionSignal(preserve_line_breaks); Change it into this: 1065 if ( actSel > 1 ) 1066 { 1067 emit endSelectionSignal(preserve_line_breaks); 1068 emit copySelectionSignal(); /* PATCH */ 1069 } Recompile and enjoy! Yes. I also cosider change of behaviour of konsole in autmaticlally coping selected text to clipboard as one of pains of 3.0.x -> 3.1.x switch :/ There should be option to enable previous behaviour. TIA Use Klipper's "Synchronize contents of clipboard and selection" option if you want the old behavior back. Setting Klipper's "Synchronize contents of clipboard and selection" affects any text component and therefore is not solution. I would like selection to copy _only_ from konsole, but _not_ copy when I'm using for example Kate editor. I rereported wish again as http://bugs.kde.org/show_bug.cgi?id=56668. Why do you think an obtrusive duplicate wish entry helps you to argument against the decision made and standards? 1. Wish entries ware not duplicate, as second one complied Yours response (which did _not_ resolved problem) and I posted it becouse You changed state of first wish entry to RESOLVED. 2. I'm unable to argument against 'decisions made' ;) 3. IMHO option set by default to standard conforming value does not break any standard. Now ( when Yours solution is clear: "apply patch' ) EOT. 3) leads to option bloat. I would also like to see this as a config option. And don't see why You're against it when the work seems trivial. Here's a thread that shows we're not the only ones used to the old behaviour: http://dot.kde.org/1013076354/1013106565/ |