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

[Ilkka Ollakka]

On ti 18. elokuuta 2009 00.17.10, Jakob Leben wrote:
> >
> > 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.
> > ...
 
> 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...
 
 Actually for shoutcast listing, why shouldn't user be able to rename
 nodes? as it's basicly his view of shoutcast streams which just shows
 on category-tree on start (and is generated on fly on startup). I'm not
 sure if theres much use for user to rename those, and use can allways
 drag nodes from there to medialibrary or playlist and fiddle it in
 there.

> 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 was thinking more like grouping items under node by dragging them
 over eachother, so if item is dropped on other item, it would create
 node and places both of items under it on same place where item was
 dropped. I can see it wouldn't maybe be the clearest approach or first
 one you think of.

> 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.

 I'm maybe more lego-approach kinda guy, data is there in pieces and you
 can see what you can build from it and what fits where ;)

> 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)

I don't think in media-library should have strict representasion of
directories required, eg I would like to have node in medialibrary which
has all my dvb playlist-items, and one with url to my http-links and one
with music etc. Thou I would also like that normal playlist is flat and
medialibrary is tree. Or actually I would like to drag nodes to selector
and place it there as new rootItem.

-- 
Ilkka Ollakka
"If the King's English was good enough for Jesus, it's good enough for
me!"
		-- "Ma" Ferguson, Governor of Texas (circa 1920)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20090818/aacab471/attachment.sig>