<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">On Mon, Aug 17, 2009 at 11:33 PM, Ilkka Ollakka <span dir="ltr"><<a href="mailto:ilkka.ollakka%2Bvlc@oamk.fi">ilkka.ollakka+vlc@oamk.fi</a>></span> wrote:<br>
 But why wouldn't you be<br>
 allowed to drop items on normal leaf making it node?<br></blockquote><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<br>
 I didn't check current playlist-code if it allows thatkinda random<br>
 adding childrens on any nodes. And I have no idea how users use<br>
 tree-mode currently.<br><div class="im">...<br>
</div> I don't actually see any reason why you couldn't crete those nodes even<br>
 now (only menu-selection is missing on context-menu and few lines of<br>
 code, maybe).<font color="#888888"><br></font></blockquote></div><br>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.<br>
<br>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...<br>
<br>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.<br><br>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).<br>
<br>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.<br><br>So....... the first things I see as a must to implement is:<br>
1. revert PLModel::flags() behavior to how it was before and strictly distinguish nodes from non-nodes (check playlist_item_t->i_children > -1).<br>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)<br>
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)<br>