[Qt-components] Ubuntu UI toolkit - Clipboard access

Zsombor Egri zsombor.egri at canonical.com
Wed Jan 23 12:15:59 CET 2013


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.
>
> 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.
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.
> 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.

>
>
>
> _______________________________________________
> Qt-components mailing list
> Qt-components at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-components

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-components/attachments/20130123/2f88bee1/attachment.html 


More information about the Qt-components mailing list