[Qt-components] Ubuntu UI toolkit - Clipboard access

Alan Alpert 416365416c at gmail.com
Wed Jan 23 16:49:08 CET 2013


On Wed, Jan 23, 2013 at 3:15 AM, Zsombor Egri
<zsombor.egri at canonical.com> wrote:
> On 01/23/2013 12:09 PM, Aaron J. Seigo wrote:
>
> On Wednesday, January 23, 2013 10:06:59 Zsombor Egri wrote:
>
> Here's an API we are proposing for accessing the system clipboard from
> QML and to filter its content before being copied into a TextField/TextArea.
>
> proposing to be added to Qt's QML API? (that seems the best place for such a
> thing)
>
> This was proposed for the Ubuntu UI toolkit, just wanted to share with you
> because I see it makes sense to have such a component in Qt QML.
>
>
> The API consists of an object, a data transfer type and a filter element.
>
> The global object is based on (and uses) QClipboard functionality:
>
> *clipboard* {
>     function *clear*() - to clear the clipboard content
>     function *setData*(string mimeType, var data) - pushes data to the
> clipboard
>     function MimeData *data*() - retrieves the clipboard data
> }
>
> i'm not a fan of global objects in the least. much nicer to instantiate
> items
> that are actually needed. otherwise, we end up with a growing pile of
> objects
> of limited value in many use cases.
>
> Agree. The unicity of the Clipboard per application drove me to have the
> object instead of instantiating items per need.

Use the new Singleton Type API:
http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2

Only one instance per application, easier to use than a global object,
and still not created until the application needs it.

Also the setData/data and clear sure look like that should just be one
data property with a setter, getter and reset function.

>
> also, why functions instead of a data property? an object with mimeType and
> data properties could be assigned/retrieved from it. setting an invalid
> object
> would be a no-op.
>
> it also makes clear unnecessary: just set data to be an empty / invalid
> MimeData object.
>
> Makes sense.
>
>
> The MimeData type provides access to the clipboard data itself; all
> properties are read-only.
>
> *MimeData* {
>     readonly property list<string> *types* - contains the available
> types in the clipboard
>     readonly property string *text* - text data or undefined if no text
> data in clipboard
>     readonly property string *html* - HTML data or undefined
>     readonly property list<url> *urls* - list or URLs or undefined
>     readonly property color *color* - color data or undefined
>
>     function var *mimeData*(string type) - returns data corresponding to
> the MIME type
> }
>
> why not a single variant property?
> why a function to return the mimeData? this is going to be implemented in
> C++
> i imagine anyways, so a property that is retrieved via a C++ function seems
> normal. it can be set to read-only.

If we aren't exposing the full QMimeData functionality anyways, why
not just add these as convenience functions on the global clipboard
object?

> A single variant property may make sense if the clipboard could have only
> one mime type data inside. But you can have more of those at the same time,
> so the properties would retrieve the particular data types when the mimeData
> function would retrieve other types. A pair of (type, data) property would
> also do the job, where setting the type would automatically alter the data,
> but I find those kind of dependencies a bit cumbersome...
>
>
> And finally the clipboard filter element, which is meant to capture
> clipboard changes aswell as to grab clipboard key shortcuts from a
> TextField or TextArea so data can be filtered before pasting it into the
> text inputs.

I'd also have thought that you could handle key combinations before
the TextEdit already using Keys.onPressed. If you have that and a
global clipboard, why do you need the filter element?

Even if there is a need, I don't see why you need this to be a
separate filter instead of just having the signals on the
TextArea/TextInput (like how QTextEdit has a virtual you can use).

> this feels like something that would make sense as part of MimeData above,
> perhaps?
>
> Not really, the MimeData aint supposed to be instantiable within QML. It's
> just a data holder.
>
>
> also, what sort of filtering do you forsee being done?
>
> Typical example is when you want to filter the data to be copied from the
> clipboard into a text input element. You can control the content when using
> context menu so you can leave out all the unnecessary data, but when using
> key sequence, both TextInput and TextEdit will grab those so you are no
> longer in control of filtering the data pasted. The ClipboardFilter helps
> you on that.
>
> Yes, you could say that you push the data filtered, but at the source you
> never know who's gonna be the destination.
>

To sum up, since I suggested that this all belongs on one singleton
clipboard object, here's what that API might look like:

Clipboard { // Although you can't instantiate one yourself
    property string data - latest data (of a single mimetype which is
convertable to string) in the clipboard
    property string mimeType - the mimetype of data

    //Possible conveniences
    readonly property list<string> formats - contains the available
types in the clipboard
    readonly property string text - text data or undefined if no text
data in clipboard
    readonly property string html - HTML data or undefined
    readonly property list<url> urls - list or URLs or undefined
    readonly property color color - color data or undefined
}

Note that bytearray MIME data, which QML can't handle, is basically
ignored. You'll need C++ if you want to use that.
For the filter properties, we just need something like Keys.onPressed:
if (key.buttons == Qt::Copy_Shortcut), right? Other than the default
key handling, pastes would already be programmatic (thus
intercept-able by the application).

--
Alan Alpert



More information about the Qt-components mailing list