[vlc-devel] commit: Qt4: store input_item_t* in plitem and handle metadata in model ( Ilkka Ollakka )

[Jakob Leben]

On Thu, Aug 13, 2009 at 5:44 PM, Ilkka Ollakka
<ilkka.ollakka+vlc at oamk.fi<ilkka.ollakka%2Bvlc at oamk.fi>
> wrote:

> I'm not sure if we need to store playlist_item_t* in playlist_model, as
> we can get it from playlist in playlist_ItemGetByInput( playlist,
> input_item_t ). But yes, it could be easier if we could do littlebit
> finer locking on playlist items also.
>
> Ofcourse it would help to retain node-order if we could store
> playlist_item_t* in model, and I tried it myself (not with great success
> ;)
>
> But maybe it could be done just storing input_item_t* pointers in
> hierarchy inside model, as currently PLitem basicly holds info if it's
> current item, showflags (which are same on every-item usually), and what
> item is it's parent.
>

My idea was to not have another hierarchy for the Qt4 model at all, to
really just use p_playlist_t and p_playlist_item_t.
We would use

QModelIndex index = createIndex (row, 0, *(playlist_item_t *)* item);
>

Then for example:

int rowCount( QModelIndex index)
> {
>     return static_cast<playlist_item_t*>( index.internalPointer()
> )->i_children;
> }
>

In this case we couldn't just use input_item_t* instead of playlist_item_t*
because the former doesn't hold information about children and parent. And
if using playlist_ItemGetByInput() we can never know if we are in the
category or onelevel storage space, because it will return always one of
them and you can't choose. I must comment that this category/onelevel thing
complicates stuff quite a lot, probably everybody that dealt with playlist
code realized that.

On Thu, Aug 13, 2009 at 5:44 PM, Ilkka Ollakka
<ilkka.ollakka+vlc at oamk.fi<ilkka.ollakka%2Bvlc at oamk.fi>
> wrote:

> Actually not sure if this helps that much, but we can notify views
>  inside qt4 gui, as most of the deletions are triggered from gui and
>  user-actions (exluding playlist-demuxers). If I don't remember that all
>  wrong.


Hmm, demuxer callbacks could be a problem, but since the callback is for
"input item got subitem" it actually doesn't mess with playlist items, so
there we could notify views in advance.
But i'm guessing: there was this recent furious debate about multiple
interfaces at the same time, and imagine that another interface could remove
playlist items and only then notify the system... mess. I think inside the
core playlist code it should be like that:

> void example_core_remove_item(playlist_item_t* item)
> {
>    example_send_callback_item_will_be_removed (item);
>    example_do_the_removing(item);
>    example_send_callback_item_removed(item);
> }
>
And then :

> void PLModel::example_on_item_will_be_removed(item) { emit
> beginRemoveRows(...); }
> void PLModel::example_on_item_removed(item) { emit endRemoveRows(...); }

Of course then:

> void PLModel::example_remove_item ( QModelIndex qmIndex )
> {
>     example_core_remove_item ( static_cast<playlist_item_t*>(
> index.internalPointer() ) )
> }


And that's all the model should do upon removing. The nice way of not having
another hierarchy for the qt4 model is that you don't need to have double
tree management code, the core will do it all, the qt model only passes info
to the qt view.

Hmm, I only guess what happens if beginRemoveRows is called more than once
before endRemoveRows... and similar...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090813/a26f0873/attachment.html>