[barberio]

As a follow up to the action currently going on to consolidate the back, parentdir and previousmenu actions; are there any other actions that could be consolidated/obsoleted?

Here's some I think appear to be redundant, and offer no apparent benefit to being offered as something that can be mapped to a key.

Code:

{"osdleft" , ACTION_OSD_SHOW_LEFT},
        {"osdright" , ACTION_OSD_SHOW_RIGHT},
        {"osdup" , ACTION_OSD_SHOW_UP},
        {"osddown" , ACTION_OSD_SHOW_DOWN},
        {"osdselect" , ACTION_OSD_SHOW_SELECT},
        {"osdvalueplus" , ACTION_OSD_SHOW_VALUE_PLUS},
        {"osdvalueminus" , ACTION_OSD_SHOW_VALUE_MIN},

Is there a real reason to keep special actions for controlling just the OSD menu, when would these even be used?

Code:

{"cursorleft" , ACTION_CURSOR_LEFT},
        {"cursorright" , ACTION_CURSOR_RIGHT},

Seems to be another special case for arrow controls?

Code:

{"hidesubmenu" , ACTION_OSD_HIDESUBMENU},

Might be another candidate for consolidation into Back?

Code:

{"scrollup" , ACTION_SCROLL_UP},
        {"scrolldown" , ACTION_SCROLL_DOWN},

Could be consolidated into the skip actions, since the contextual action of skipping forward and back would be that of scrolling a page up and down in lists.

Code:

{"firstpage" , ACTION_FIRST_PAGE},
        {"lastpage" , ACTION_LAST_PAGE},

Could be consolidated into the large-skip actions, for the same reasons.

[spiff]

No reason to keep those. They were useful some six years ago when osd actually referred to the mplayer osd...

[pieh]

Code:

{"scrollup" , ACTION_SCROLL_UP},
        {"scrolldown" , ACTION_SCROLL_DOWN},

Could be consolidated into the skip actions, since the contextual action of skipping forward and back would be that of scrolling a page up and down in lists.

Code:

{"firstpage" , ACTION_FIRST_PAGE},
        {"lastpage" , ACTION_LAST_PAGE},

Could be consolidated into the large-skip actions, for the same reasons.

If video would be playing in background and user would be in item listing then these calls what be a ambiguous (what should it do - scroll listing or skip video?).

[topfs2]

first/last page are still useful. Its the home/end equivivalent of a list afaik?

Not sure if scroll up/down should be same as skip?

cursor left/right, still useful I think for touch skins in virtual keyboard.

Other than that the others seems quite deprecate-valid.

[barberio]

If video would be playing in background and user would be in item listing then these calls what be a ambiguous (what should it do - scroll listing or skip video?).

I'd say they would apply to what was in focus, ie the item listing.

[topfs2]

I'd say they would apply to what was in focus, ie the item listing.

problem is say you have a small OSD (as with confluence) when navigating, even if we can deduce the skip in the list its harder to do on the button in the OSD. I personally don't see the value of merging them, or what we gain by doing so.

[barberio]

problem is say you have a small OSD (as with confluence) when navigating, even if we can deduce the skip in the list its harder to do on the button in the OSD. I personally don't see the value of merging them, or what we gain by doing so.

Having an pop-up OSD with list elements in it is a usability flaw in the first place.

[topfs2]

Having an pop-up OSD with list elements in it is a usability flaw in the first place.

why? I'll give you a usecase.
Alice listens to some music, she wants to find some new music to enqueue she press home, go into music then while she is pondering about what to add the next song which got started in the background she hate. Thus she navigate left to the OSD and press next song.

This use case cannot easily be done if you merge skip.

EDIT: I never said pop-up btw. I said OSD display, that does not imply pop-up or dialog.

I can give you a case when a list in a popup osd would be useful also, now playing dialog (i.e. with the items of the current playlist) which can have touch buttons for next, previous (just for completeness) track also.

Point I'm trying to make is that I don't see what we gain by merging, except harder to write code handling the event (i.e. we need to deduce the context, which is not trivial). AFAICT the actions are not really needed to be shared, one is GUI and one is Playback control, seems fitting they are seperate IMO.

EDIT2: If the scroll up/down are necessery function however I don't know, I guess it might be useful for skinners for the little down/up button beside the scrollbar.

[barberio]

why? I'll give you a usecase.
Alice listens to some music, she wants to find some new music to enqueue she press home, go into music then while she is pondering about what to add the next song which got started in the background she hate. Thus she navigate left to the OSD and press next song.

This use case cannot easily be done if you merge skip.

Yes it can... Because there shouldn't be anything to scroll around with in the OSD. User focus moves to the OSD while it is up, so context switches back to skip.

[topfs2]

Yes it can... Because there shouldn't be anything to scroll around with in the OSD. User focus moves to the OSD while it is up, so context switches back to skip.

Well I have never said its not possible Reread my posts, I said "not easily" and "not trivial" for a reason

Personally my standpoint is a) I don't see how GUI actions and Playback control are same, GUI is GUI and Players is Players b) Its hard to deduce the context (with current code), so you are making a simple problem with seperate methods into a hard problem with a single method. c) We don't gain anything by merging? We need to update all keymaps and all skins for what reason?

EDIT:
Another use case which is impossible to do:
Alice listens to some music, she wants to find some new music to enqueue she press home, go into music then while she is pondering about what to add the next song which got started in the background she hate. Thus she press SKIP NEXT on her remote (while still highlighting the media list).

You need to consider that a remote may very well have skip back/next buttons AND scroll up/down buttons

[jmarshall]

All the ACTION_OSD_* can go as they're not used anywhere to my knowledge (grep to check first).

The rest are all used, and all have valid use cases at resolving contextual issues, and allows the user to control what should be done when context is non-obvious.

That doesn't mean they need mapping in any way - in most cases all of those wouldn't be mapped to anything.

Cheers,
Jonathan