Posts: 17,859
Joined: Jul 2011
Reputation:
371
Well I think we need more opinions on this.
I still think current PR is a valid implementation and like it as it is for handling sets.
Let's put up a build for the users to try it out and get their response.
Posts: 6,252
Joined: Jun 2009
Reputation:
115
da-anda
Team-Kodi Member
Posts: 6,252
B IMO only makes sense in the "Sets" node for which we really need a "add set" list item. I'd actually prefer this over A, but see the need for both.
That B doesn't make much sense in a movie node I agree, but the mixed movie/set list is a special case anyways and grouping by set has to be enabled in first place. In case it's disabled (which IIRC is default), B makes perfect sense just like for tags.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
@Montellese: I agree with all three points. I think the first two show that trying to edit things really requires a listing of everything that you have, rather than some grouped list, or some vpanel/wrap/coverflow view don't really work for editing stuff.
And yes, it would be more code to allow lists to multi-select, primarily in controlling what to do when multiple items are selected and various context/actions are initiated. OT, but one thing that might make sense in the interim is to try and remember to code with this in mind for new context/actions - i.e. assume that there may be more than a single item involved.
My goal here isn't to ensure the feature is not added. Rather, it's to ensure that we add things in the best way possible, and if the only way to do it is a little bit clunky, then maybe the best thing is to just not provide the feature. In my opinion, mass editing of data is best done either with a touch device or with keyboard + mouse - a remote will always be a clunky way to do it. Sure, the odd change here and there can be done within the app as you stumble across things, but I don't think users expect to spend a lot of time inside XBMC fine-tuning metadata. Sometimes, then, it's best just to not bother with anything more than the basics, and instead let that mass editing be done in JSON-RPC clients and the like.
Cheers,
Jonathan
Posts: 414
Joined: Apr 2010
Reputation:
5
Voyager
Retired Team-Kodi Member
Posts: 414
So where does that leave us? We know the tags GUI is clunky so that needs a bit of work to support a more intuitive mass editing. Montellese said he had something in the works so I did want to wait for that to be available. In the mean time we could throw the multi-selection in the way it is, and subsequently take the opportunity to improve both GUIs for tags and sets.
I'm in agreement with Martijn, da-anda, and Montellese that you need both A and B. Not all users are the same.
Posts: 31,445
Joined: Jan 2011
I like da-anda's idea of having the context menu item only enabled when you are in the sets node. Seems like the best of both worlds.
Posts: 6,252
Joined: Jun 2009
Reputation:
115
da-anda
Team-Kodi Member
Posts: 6,252
@jm - well, I've often been in the situation where the movie set didn't get imported correctly or where I forgot to add it to the nfo and I wished that I could simply fix it inside XBMC. In those cases I would have used A to fix it. But I have to say that managing sets via nfos just sucks and I'd rather prefer doing this in XBMC, so I'm also all for B.
I don't want to be forced to do this in a webbrowser or on a remote app. We can ofc provide those features there, but as a media center XBMC has to be useable in itself and out of the box, and not rely on other clients to be managed. Nor should it require a mouse or the context menu - it should work with the limited button set available via CEC or a limited remote (Cursors, ok, back and probably info).
Custom library nodes is another thing I'd like to be able to manage inside XBMC and not via XML hackery. This feature is also clunky to use, but it got injected (clunky because you have to duplicate default nodes and don't get updates on those + the location they have to be moved is odd IIRC).
I ofc agree that when we add a feature it should be done in best possible way from the beginning and not injected and hopefully be fixed later (which often won't happen at all). In this particular case otoh, we already have the clunky interface from the tags feature, so why not reuse this and fix both in one go then? IMO it's not part of this feature/PR to fix the tag interface/handling, but even with the a bit clunky interface it's better then missing completely.
Posts: 31,445
Joined: Jan 2011
Not to belittle the work done by anyone, but in my mind, nothing can beat how
Add-on:XWMM (wiki) handled sets and other things. Unfortunately, movie sets management isn't working in the current test version of XWMM.
Using a web interface to manage these kinds of "not every day" management tasks is a fantastic idea. I mean, this is cool too, but from the discussion here it's apparent that XBMC's UI needs major rethinking if we want to manage such stuff from within XBMC.
Posts: 414
Joined: Apr 2010
Reputation:
5
Voyager
Retired Team-Kodi Member
Posts: 414
2013-04-04, 18:03
(This post was last modified: 2013-04-04, 18:04 by Voyager.)
and I would like to add that while add-ons are nice for the geeks who can/want to use them, mainstream users have the right too to perform some basic set manipulation.
The point is that not everyone has a tablet on the side to use the web interface. The ordinary user just wants to get things done from within the xbmc gui itself.
Posts: 31,445
Joined: Jan 2011
2013-04-04, 19:06
(This post was last modified: 2013-04-04, 19:09 by Ned Scott.)
(2013-04-04, 18:03)Voyager Wrote: and I would like to add that while add-ons are nice for the geeks who can/want to use them, mainstream users have the right too to perform some basic set manipulation.
The point is that not everyone has a tablet on the side to use the web interface. The ordinary user just wants to get things done from within the xbmc gui itself.
Nice for geeks? XWMM is what I recommend for the ordinary user. Geeks can go edit their confusing NFO files.
Everyone has a web browser. Everyone. You don't have to have a tablet. At some point someone has to download or rip or somehow acquire a video file, put it on a hard drive, maybe rename it, etc. It's the same logic behind why we can't manually add videos to the library. XBMC (10-foot interface) isn't set up for that, but a computer (2-foot interface) is.
This Movie sets management is a great step in the right direction. I'm just pointing out that XBMC's UI needs a lot of work to be able to gracefully handle management tasks like this. I'm all for being able to do it within XBMC.
(2013-04-04, 17:19)jjd-uk Wrote: The problem with that is XBMC does not have a web interface database editor built in & maintained as part of the core app, XWMM does a great job but slash disappeared from scene for quite a length of time and there is still no official Frodo version available with the full feature set of the Eden version.
It's open source. Patches welcome :)
One person disappearing should never be a reason to dismiss an add-on like this when it is open source.
Posts: 31,445
Joined: Jan 2011
Just to emphasize, I really do think the movie sets management, and then general idea of being able to do these things in XBMC, is the right direction. Hopefully in the future we'll have hammered out some additional standard UI elements/windows/whatever to help ease some of the UI limitations we currently face, but even with those limitations, this is great work.
Re: context menu, I have no strong feelings on it, to be honest. On one hand, I see the point in moving more things out of it, but it's also a perfect spot for when you do want to do something like this. XBMC seems to have a love/hate relationship with the context menu :)