[Martijn]

Reason for "remove movie from set (foo)" is that at least you know which set you're removing it from, which isn't obvious if you're starting from the movie point of view. So I prefer to leave that in.

Well the point is that you already know in which set you are because you had to browse to that set to find the movie you are editing now. Even in normal movie library unless you have disable the group movies in sets option. But in that case it might defy the use of sets at all
Perhaps others have some suggestions


Well it's not like you edit the moviesets on daily bases (more like a one time thing if you don't like current set) and since we only allow a single set for a movie it's nice to know that it will be removed from the other.

[Voyager]

Well the point is that you already know in which set you are because you had to browse to that set to find the movie you are editing now. Even in normal movie library unless you have disable the group movies in sets option. But in that case it might defy the use of sets at all
Perhaps others have some suggestions

Actually Martijn I'm using sets only in the "sets" view. In the movies view I don't (like to) group them. So I prefer to know which set a movie is in before I remove it.
Regarding the additional suggested warning, it's done. Updating PR and will provide more screenshots.

[Voyager]

PR updated. New screenshots. What you see below is me trying to change the Skyfall movie to be in another set. At the time it's the only one in the set "James Bond collection". This triggers a double warning: first warning that the movie will be removed from its current set, second one to say that if you do that the current set will become invisible (because it's the last movie remaining in that set).

[Martijn]

Proceed? -> Continue? for consistency

[Voyager]

Proceed? -> Continue? for consistency

fair point... will do.

[jmarshall]

I must agree with you, but it has been requested by Montellese and Martijn. As I'm trying to be neutral and accomodate different use cases and preferences I can see the benefit of having the "manage set" function to add/remove member movies.

Martijn and Montellese: What is the rationale for complicating the UI to accommodate this behaviour? I can't really see how it adds to the user experience? Is there really a decent use-case for this?

Cheers,
Jonathan

[da-anda]

Cancel really doesn't make sense within the list. And we can't rely on "back" or "esc" as not every remote might have those. So if we can't change the label of the "OK" button to something like "Close" and have no other dialog we could reuse we have to live with it. I'm not happy from a usability POV though as we don't have anything to confirm with "OK" here. Also being it a item list with all the list info is sorta misleading / give the wrong impression. But I don't have a better idea now that wouldn't require a custom dialog/window.

[Ned Scott]

So I don't really know the limitations or whatnot of the different window types, so bare with me if my suggestion isn't possible or is stupid. Could this window just say "Currently a part of set: X" and the options be "change set" and "cancel", or if not apart of a set "add to set" ("currently a part of" would say "none" in that case). The window after you say "change set" would have a list of sets, and next to the list would be two buttons "New set" and "none". Not even "new" and "none" in the list, but as buttons, to the right of the list.

Currently it just feels clunky.

Just to throw it out there.

Still not digging it as an option in the context menu, but meh, whatever.

[Voyager]

@da-anda: we can certainly change the label of the OK button as part of the standard select dialog. For example below, I changed OK to "Select" (could also do "Close"), which works better together with the "Cancel" option. I could also change the heading to "Please make a selection:"


@NedScott - my goal was to make the feature available without extra custom dialogs/windows. What you suggest does require that. Also your proposal makes things more clunky in terms of "clicks". To change a set, nothing changes, but to add to a new set or to remove from a set you add one unnecessary step.

I think some of your concern can be addressed by changing the wording slightly in what's there now:
menu in case of part of set: "remove", "change set to a new set", "change set to an existing set";
menu in case of not yet part of set: "add to a new set", "add to an existing set";

The context menu rationalization is part of a future effort.

[Ned Scott]

Well, in my mind the "change set" button would actually be in the movie info window. The extra click would really only be needed if you wanted to see a window that displayed the current set, and also did not get there from the movie info window (which would show the set).

But yeah, saying "change" I think fixes what was bothering me. It looks weird to see more than one "add" option, which also slightly implies multiple sets per movie. "Change" clarifies that greatly.

The button thing I figured required extra work. Using buttons was more of a hope, as we have this weird... Not sure how to say it.. We use lists too much, kind of, or in places I think the user would expect to see a button. That's just a minor tick for me, and was hoping this was one place we could snip it :) . It's probably just me, anyways.

Awesome work, in any case. There will be much rejoicing with users.

[Voyager]

But yeah, saying "change" I think fixes what was bothering me. It looks weird to see more than one "add" option, which also slightly implies multiple sets per movie. "Change" clarifies that greatly.

Thanks for the quick feedback. I've applied this change and pushed code (to the PR branch).

[da-anda]

Voyager - if you rename "OK" to "Cancel" and remove cancel from the list above it should be fine I think. The "OK" is just wrong as you don't confirm anything but only close the dialog/cancel.

[Martijn]

Voyager - if you rename "OK" to "Cancel" and remove cancel from the list above it should be fine I think. The "OK" is just wrong as you don't confirm anything but only close the dialog/cancel.

Good point yes

[Montellese]

Voyager - if you rename "OK" to "Cancel" and remove cancel from the list above it should be fine I think. The "OK" is just wrong as you don't confirm anything but only close the dialog/cancel.

Depends on how it is implemented. You could implement it in a way that any changes only apply if you hit the "OK" button. If you press Back/Escape any changes are lost. That's how a lot of the dialogs in XBMC work. IMO we should be consistent about this.

[Voyager]

Voyager - if you rename "OK" to "Cancel" and remove cancel from the list above it should be fine I think. The "OK" is just wrong as you don't confirm anything but only close the dialog/cancel.

Good point yes

No, this wouldn't work!

I'm using the standard select dialog, in which the button triggers closing the dialog.
If you clicked the button, the dialog is considered to be "confirmed", if you escaped out using back/escape, then it's "not confirmed". Anyhow, what this means is that you can't call the button cancel, because it still will act as confirmation of the selection. Take the example of selecting "remove from set", then moving the focus to the button which you call "Cancel". It will still confirm the selection of "remove from set" and proceed with that action. So the button has to be either "OK", or "Select".

Now there is ONE thing I can do: and that is completely remove (ie disable) the select dialog button. The resulting dialog looks like the one in the last screenshot but without a button. Would this be a good compromise?