kinetic-declarative plasma integration

[aaron.kennedy at nokia.com]

Hi Marco,

On 15/05/09 11:34 PM, "ext Marco Martin" <notmart at gmail.com> wrote:
> tanks a lot for the input on qmodels, i assumed the qt docs were missing on
> that part, now i've generated them and i see..
> 
> what i'm looking about specifically is seeing how feasible is to use those
> list views in the gsoc i'm mentoring about a plasma based mediacenter (well,
> depends also when we want to release something, before or after 4.6)
> 
> so i'm looking on what we would need in that case:
> 
> doesn't seems to be any way to set the currentIndex of any of the views simply
> by clicking on an item (can implement a mouseRegion on the delegate, but
> doesn't seem to be a way for the item to know what is its index into the
> view?)

Now you *have* found some limitations in our documentation :)

You're correct in that the way to select an item on click is to have the
delegate contain a MouseRegion that does it.  By design we've tried to limit
codifying "behavior" (like click to select) into our elements; preferring
the flexibility of allowing the designer to define it as they see fit.  Of
course there is a balance to strike here - convenience vs flexibility - and
whether or not we've got it right is another question.

The index of an item is available magically to the delegate as the "index"
context property.  A delegate can check whether it is the current item by
comparing its index to the list's currentIndex, or by using an "attached
property".  Attached properties are a concept we borrowed from Windows
Presentation Foundation which allow one object to augment another with
addition properties - in this case the ListView class adds a
"ListView.isCurrentItem" property to the *root* element of the delegate.

I've attached a simple example that implements click to select, and also
changes the selected item's color.
 
> PathView doesn't seem to be controllable with the keyboard (even by
> implementing KeyActions into the delegate and changing the active index
> doesn't seem to work, but nothing automatic anyways)

Having default keyboard behavior for a PathView is tricky - depending on the
shape of the path you might want any one of the up/down/left/right keys to
move forwards and backwards in the items.  So we took the easy way out and
left it up to the user :)

I've attached an example showing how to use KeyActions to key left and right
through the PathView items.  This is one of the balancing acts I mentioned
above where we feel that its a little too far to the flexible/inconvenient
side - I expect that we'll probably eventually add a way of setting a
default key behavior for PathView so that you don't have to do this every
time.
 
> is there a way for an item to notice when it becomes active and changing its
> state as a consequence? i.e, having the active item maybe slightly bigger and
> with more info, like the recipes example (but here the item zooming is
> triggered by a mouse click)

This is also demonstrated in the listview example I mention above.

Cheers,

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pathview.qml
Type: application/octet-stream
Size: 879 bytes
Desc: pathview.qml
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090515/9748de01/attachment.dll 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listview.qml
Type: application/octet-stream
Size: 996 bytes
Desc: listview.qml
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090515/9748de01/attachment-0001.dll