Summary: | Limit permissible size of paste data | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | altlst |
Component: | Clipboard | Assignee: | Martin Flöser <mgraesslin> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | wishlist | CC: | eng.mahs, groot, l.lunak, molostoff, nate, null |
Priority: | NOR | ||
Version: | 5.15.3 | ||
Target Milestone: | 1.0 | ||
Platform: | Compiled Sources | ||
OS: | Solaris | ||
Latest Commit: | Version Fixed In: |
Description
altlst
2001-10-16 00:24:51 UTC
Klipper now doesn't repeatedly transfer so much data as it used to, and it should be probably enough even for this specific problem. Limiting of the size still needs to be done, but that will require application support (http://www.freedesktop.org/standards/clipboard-extensions-spec/clipboard-extensions.txt). There is no way to fix this wish --- the clipboard data will be copied before the size can be determine, unless I'm missing something. If someone wants to avoid having large clipboard items in the clipboard for other reasons, please open a new bug. As said in my comment, this is possible at least for applications that provide support for it. There's a proposal for such a spec at freedesktop.org, but I can't find it currently because of the site reorganization after the hack. Well, google provides. I'll look into it, but I think that the originals poster request for support for this in XEmacs is unrealistic :) Here's the link, I think: http://freedesktop.org/wiki/Standards_2fclipboards_2dextension_2dspec Ok, it seems everybody pretty much ignores that proposal from me. However I managed to sneak a similar mechanism to http://freedesktop.org/wiki/ClipboardManager (TARGET_SIZES). A quick grep on Gtk shows everybody ignores that part too :-/. Oh well. Well, so does Qt after all. *** Bug 288030 has been marked as a duplicate of this bug. *** *** Bug 237308 has been marked as a duplicate of this bug. *** *** Bug 238031 has been marked as a duplicate of this bug. *** (If there's a not-KDE2-era version of this, it would be relevant. The dups linked to this one are KDE4-era, which is also over) |