Hi Marco, On 15/05/09 11:34 PM, "ext Marco Martin" <notm...@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
pathview.qml
Description: pathview.qml
listview.qml
Description: listview.qml
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
