[vlc-devel] commit: qt4: remove b_is_node and use childCount() > 0 instead in playlist_model (Ilkka Ollakka )

[Jakob Leben]

>
> On Mon, Aug 17, 2009 at 11:33 PM, Ilkka Ollakka <ilkka.ollakka+vlc at oamk.fi<ilkka.ollakka%2Bvlc at oamk.fi>
> > wrote:
>  But why wouldn't you be
>  allowed to drop items on normal leaf making it node?
>
...
>  I didn't check current playlist-code if it allows thatkinda random
>  adding childrens on any nodes. And I have no idea how users use
>  tree-mode currently.
> ...
>  I don't actually see any reason why you couldn't crete those nodes even
>  now (only menu-selection is missing on context-menu and few lines of
>  code, maybe).
>

Yes, the vlc_playlist.h functions allow for turning a leaf into a node,
maybe even renaming nodes. I agree it would be easy to integrate this
options into qt4 UI.

It's just not that simple: the problem is that not every action always makes
sense. For example shoutcast listings should be simply read-only in my
opinion. In the end they only "list", don't they. And before it makes sense
to move items out of and into nodes which represent filesystem directories,
it would be necessary to enable renaming of those nodes so that such an
action makes sense. But then again, you don't want to enable renaming of
shoutcast nodes...

Things are very inter-related, so some options require others to be really
useful, and the more options we add, the more restrictions we also need so
that those options are valid only on relevant data.

For example, to make possible to turn any leaf into a node by just dropping
items on it is simply absurd to me. So you would have an mp3 song and drop
on it and it would become a node and "contain" another item? Why would this
make sense? Nodes should not be "playable" anyway (just as they are not
right now).

I am a strong proponent of GUI that conveys meaningful information and
behaves sensfully and according to type of data it represents. You can't
treat everything the same.

So....... the first things I see as a must to implement is:
1. revert PLModel::flags() behavior to how it was before and strictly
distinguish nodes from non-nodes (check playlist_item_t->i_children > -1).
2. enable spontaneous creation of nodes and node renaming through GUI (but
NOT turning a leaf into a node, only in case of demuxer discovering
sub-items does this make sense, I don't see a case when it would make sense
as an user's spontaneous action)
3. implement read-only property for nodes (no renaming of node, no
inserting, removing and moving children allowed, reordering only by
sorting). Apply this read-only property to all but Media Library and
Playlist. _Maybe_ impose some restrictions also to individual nodes inside
Media Library (so that nodes are strict representation of directories for
example)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090818/e6b6b9fe/attachment.html>