[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 150527] Select non contiguous texts...
From:       Christoph Feck <christoph () maxiom ! de>
Date:       2010-08-31 22:35:24
Message-ID: 20100831223524.E045363A71 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=150527


Christoph Feck <christoph@maxiom.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |christoph@maxiom.de,
                   |                            |kde@mosehansen.dk,
                   |                            |l.lunak@kde.org
         Resolution|                            |UPSTREAM
         AssignedTo|kde@mosehansen.dk           |kdelibs-bugs@kde.org




--- Comment #12 from Christoph Feck <christoph maxiom de>  2010-09-01 00:35:22 ---
First, from how I understand the original request, KDE should support
multiple/split selection. Support for that depends on the selectable data
types. It is not possible to add magic code to KDE or kdelibs that makes other
applications that support (single) selections now suddenly support split
selections. So it has to be added in each widget/program that wants to support
this.

For KTextEdit based classes: Selection is handled by QTextCursor class, and
this one currently only supports split selections when they span over multiple
table cells, see QTextCursor::hasComplexSelection(). For this class, it would
be an upstream request.

For KTextEditor based classes (Kate etc.) please file the request to Kate
developers. For KHTML, this would be a wish that you should report to Konqueror
developers.

For KOffice based applications, please file the request to KOffice developers.
At least KWord also uses QTextDocument internally, so the enhancement to
QTextCursor should apply to KWord as well.

Second, from how I understand the alternative request, we want some "Append
selection to clipboard" operation (instead of replacing clipboard with
selection contents). QClipboard does not support that operation, as such it
would (again) be an upstream enhancement needed. KDE applications operate on
QClipboard directly, so if that class supports appending, the programs could
utilize it.

The third option would be to collect copied selections into Klipper. Some hot
keys could be assigned (or menu entries used) to "start" and "end" collecting.
In this case, it would be an enhancement request for Klipper.

Since I see nothing here that can be added to kdelibs, I am closing this bug as
upstream until someone clarifies what needs to be added in kdelibs.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]