On Tue, 2014-01-21 at 14:08 +0100, Juan A. Suarez Romero wrote: > On Tue, 2014-01-21 at 11:23 +0100, Bastien Nocera wrote: > > Although, that won't work with added though, as either you'll pass the > > GrlMediaBox that contained the added item (meaning, "you need to browse > > this again") or pass the new GrlMedia which is fine if you know that you > > don't have any children items in the source but is useless otherwise. > > > > Should I file a bug about this? I'd fix this by adding a new > > grl_source_notify_change()-like call, deprecate the old one, and still > > send out the compat "content-changed" signal. > > > > Not sure if I'm understanding completely. Could you elaborate it more? > > One of the problems in "added" with sending the GrlMedia is that > application doesn't know if the element is of interest for the > application or not. And that's because application is showing content > from a search or from a container, and the it doesn't know if the new > added element is for that container (so it should show it) or is from a > different container irrelevant at that moment. Dunno if this is related > with above.
Completely. For example, the filesystem plugin knows the parent folder for the newly added item, so it would pass the parent container to the notify function. > One solution could be sending also the container where the element > belongs. So application knows if the element is of interest or not. And > on top of this, for those very lazy applications, they could choose to > just re-launch a browse of the container instead of adding the added > element. Lazy applications, not really. With the current signals we wouldn't know where to add newly added items even if we wanted to. Sending 2 change notifications saying "this is the item we added, this is the container that changed" is really impossible to implement because you'd be sending 2 separate signals (the change type is different). So the way to fix this properly is adding a new notification function, and adding a new signal. > > > I think if you want to do lookups only using one source, you would need > > > to do it by hand, calling resolve(). > > > > grl_source_resolve() needs to be called by hand in all cases, doesn't > > > Yes, grl_source_resolve() needs to be called, unless you want to allow > to do it in the browse itself. If I use that as the browse flags: GRL_RESOLVE_FAST_ONLY | GRL_RESOLVE_IDLE_RELAY | GRL_RESOLVE_FULL tmdb still looks up metadata about the media even though it is slow. That doesn't sound like the right behaviour to me. > My point is that if you want to call only local-metadata, you need to > invoke resolve() over local-metadata. But if you want to use all the > plugins, you could use directly the same source you used to browse, and > let Grilo to choose which plugins should invoke to satisfy the > requirement. You could set up priorities in the sources so, for > instance, local-metadata is used before TMDBb. Right, but that means doing a lookup on tmdb for a thumbnail if the local file doesn't have a generated one. > > it? Maybe an explanation of what GrlSource needs to be passed to > > grl_source_notify_change() would be useful. > > > > I don't fully understand what you mean: the source passed in the > notify-change is the source that creates the content. Sources > complementing information (like TMDb or local-metadata) doesn't send > notifications. Sorry, I meant an explanation of the source to be passed to grl_source_resolve(). It's clearer now though. _______________________________________________ grilo-list mailing list grilo-list@gnome.org https://mail.gnome.org/mailman/listinfo/grilo-list
