[da-anda]

so it's not "click the list item to perform the action" but rather "highlight a list item and click the OK button to perform the action"? Or even a combination of both? If so, this is IMO a absolute no go because it's behavior is unpredictable for users. In that case the "OK" button for sure has to be dropped.
The only "nice" solution with this kind of dialog I see then is that we make the list items have a checkbox/radiobutton that indicates which function is selected and pressing "OK" will then perform this action. But I'd rather see a custom dialog for this now - maybe not just for this but ofc a bit more generic so that it also works nicely for tags or any other "manage foo" thing (like artwork, ...)

[Voyager]

so it's not "click the list item to perform the action" but rather "highlight a list item and click the OK button to perform the action"? Or even a combination of both? If so, this is IMO a absolute no go because it's behavior is unpredictable for users. In that case the "OK" button for sure has to be dropped.
The only "nice" solution with this kind of dialog I see then is that we make the list items have a checkbox/radiobutton that indicates which function is selected and pressing "OK" will then perform this action. But I'd rather see a custom dialog for this now - maybe not just for this but ofc a bit more generic so that it also works nicely for tags or any other "manage foo" thing (like artwork, ...)

It works like any regular single selection dialog box in xbmc. You highlight first, then press OK or Enter or you click or touch (whatever applicable). I think you know what that is.
Next to the countless lists in xbmc, it's also used e.g. when changing artwork (the popup that asks you which art type)...

First highlighting, then selecting the button works too, but I find it confusing as well. The way it's presented in my latest screenshot above is IMO totally predictable (the highlight shows the choice), since I got rid of that confusing button.

Agree with the long term dialog idea. Montellese has something in the works, that's why I wanted to keep this basic.

[Voyager]

just wanted to circle back here, regarding the button thing.

First of all I have to admit to @da-anda and @Martijn that I was wrong: you can indeed distinguish the button press from a selection in the list (for example, when refreshing a movie, there's a list coming back from the scraper + a "manual" button, that allows you to select something else manually).

Code:

int iSelectedLine = pDlgSelect->GetSelectedLabel();
          if (iSelectedLine >= 0)
          {
            // do stuff with  list[iSelectedLine ];
          }
          else if (!pDlgSelect->IsButtonPressed())
          {
            // do other stuff e.g. back out
          }

I have a few comments on the code that I need to fix and I'll make the proposed change to remove the "cancel" item from the selection list and reactivate the button again as a "cancel" buttton.

[Voyager]

@da-anda - @Martijn - movie set dialog got rid of the "cancel" list item and added "cancel" button down below as per your request in the forum. PR updated.

[da-anda]

sounds good to me now

[jmarshall]

So, can anyone explain why we need the "Manage sets" thing from the context menu for a set?

If not, I'd like that removed from the current PR. Otherwise, removing it later would be seen as removal of a feature which is far more difficult.

[Martijn]

you mean in the context menu on a single movie?
because that is to me the most obvious way to manage a movie in set.
or do you mean some other place?

i would rather see the context menu completely stripped like mentioned in this thread
http://forum.xbmc.org/showthread.php?tid=154474

[Voyager]

I guess jm means the movie set context allowing the addition/removal of movie set 'members'

[Martijn]

I guess jm means the movie set context allowing the addition/removal of movie set 'members'

Just read the git comment.

Well why should it be removed afterwards? It is a quick way of selecting all movies you want to have in a set instead of scrolling through your library. Context menu on that movie, manage set, add to existing set (or remove). rince and repeat for that set. Then move to the next set.

I definitely see the advantages even though this will not be done daily.

Edit:
It was also requested by Montellese if i read it correct
http://forum.xbmc.org/showthread.php?pid...pid1378206

[Voyager]

Right, i was going to point to that option a) vs option b) discussion where the conclusion was we need both.

[jmarshall]

My conclusion is you don't need B at all. It's not done every day, so the small amount of effort to do it isn't a problem.

And indeed, it's approximately the same amount of work for the user either way. In option A you must context on the first movie and choose "new set" and type it in. Then for each other movie, context on the movie and select the new set.

In option B you must context on the first movie and choose "new set" and type it in, then you can context on the set (which requires navigating away from your movie listing) and then select the other movies to add to the set. You still need to scroll through your entire library in the select dialog anyway, so approximately the same amount of work is needed - just a few less clicks.

Thus, my contention is that having option B does not justify the added code over and above that already present due to option A.

Cheers,
Jonathan

[Martijn]

Well i disagree but it's not my call.
Doing it like b would make it behave the same as tags so why don't we drop a and make it consistent?

[jmarshall]

Isn't it clear that option A is better than option B if we have one and not the other?

Basically I don't see a good reason as to why option B is required. Consistency with tags isn't a good enough reason I don't think.

I'd never even think of bringing up the context menu on a set in order to add new things to it.

Cheers,
Jonathan

[Montellese]

I can just repeat what I said before: IMO it's much easier to setup your whole library with sets with option B than with option A. IMO the reasoning that it isn't needed because it's not a daily operation is invalid, because then we could drop A as well and with that the whole feature. If we'd add a "Add set..." list item (like for tags) users could setup their whole library with sets without leaving the Sets node. Furthermore you'd save approximately 2 of 3 clicks (not counting the clicks it takes to find the set you are looking for) per movie you add to a set.

I'm not against A (it's how most apps do it) but I can't really understand your firm stance against B. IMO B is much easier to use with e.g. a remote than A because it saves a lot of clicks.

[jmarshall]

Most apps can be wrong, but at least to me, they seem right in this case.

The intuitive way (to me) for option B is to multi-select all the movies and then edit the set details of the combined items. i.e. instead of thinking of starting at an empty set and then choosing items to put in it, I pick the items and then specify that they should be grouped together. The reason this makes sense to me is I need to view the items before I know that two or more of them should be grouped.

i.e. I'd start with "wait, these items are supposed to be grouped in a set" (select the items) then assign the set metadata for those items (ideally all at once, but for now one by one would do the trick).

Cheers,
Jonathan