Hi Bastian,
> > There are multiple MENU keys I assume for clarity purposes and to
> > give
> > some kind of relation between the key definition and the action/event
> > that occurs when you use it. I would say it's more a matter of
> > convenience rather that need, similar to KEY_ROOT_MENU &
> > KEY_MEDIA_TOP_MENU; It's not a necessity that these two exist, but
> > they do out of convenience. You could still make things work if one
> > of
> > them vanished.
>
> Those 2 keys were added because they were present on DVD player remotes
> nearly 20 years ago ("Root menu" vs. "Top Menu"), and do different
> things.
That's true as it pertains to DVD players, but usage has changed over
time. These days it's common to have pc-based alternatives to
standalone players. Beyond that, pc-based setups that replace multiple
standalone devices. I personally use `root menu` to jump to the root
dir of my lan in file browsing mode and `top menu` to jump out to the
top-most menu of the playback menus. I mentioned neither of these _has
to_ exist but do for the sake of convenience. That's because the end
result in both cases could be achieved by pressing `back` X number of
times. But that's slow & inconvenient.
> > > > KEY_DISPLAY_FORMAT doesn't open any menus and is used to cycle
> > > > through
> > > > how video is displayed on-screen to the user; full, zoomed,
> > > > letterboxed, stretched, etc. KEY_CONTEXT_MENU would be for
> > > > something
> > > > like bringing up a playback menu where you'd set things like
> > > > upscaling, deinterlacing, audio mixdown/mixup, etc.
> > >
> > > KEY_ASPECT_RATIO (formerly KEY_SCREEN).
> >
> > Physical displays have a single set aspect ratio (W/H). Images have
> > their own aspect ratios. When the AR of the video to be display and
> > the display itself are mismatched, you have to do something
> > (letterbox, pillarbox, windowbox) to the video to maintain the
> > correct
> > video aspect ratio. You can't change the displays AR, and you aren't
> > changing the videos AR so using KEY_ASPECT_RATIO makes no sense. AR
> > isn't being touched/altered/manipulated, but how the video is being
> > displayed is. Stretching and filling to match the display AR alters
> > the video AR so there is makes sense, but then zooming may not. So,
> > since "aspect ratio" kind of makes sense in a couple cases, and makes
> > no sense in the rest, the more suitable KEY_DISPLAY_FORMAT is my
> > suggestion.
>
> The "Aspect Ratio" or "Ratio" key on loads of remotes have been doing
> this exact thing since the days of the first 16:9/cinema displays. I
> really don't think you need a new key here.
You can throw "Display" buttons and buttons with simply an icon
implying display manipulation in there as well. I've explained why
KEY_ASPECT_RATIO simply doesn't apply, and why KEY_DISPLAY_FORMAT
does. If people are against adding KEY_DISPLAY_FORMAT, then
KEY_ASPECT_RATIO should be renamed again & as such to properly reflect
the intended action. I suspect whomever started labeling this as
"aspect" or "aspect ratio" on remotes was some hardware designer that
didn't know how to accurately explain what the button does and took
his best (poor) guess.
Generally speaking, I think it's important to keep key definitions
close to what the intended action/result is. When it comes to pc-based
solutions, they are taking on more simultaneous roles and have to
cover a wider range of stuff. It's common these days to find people
using small boxes which perform local media functions & playback,
recording, streaming, interactive tv, web browsing access, etc. The
whole reason I made these suggestions was because I found I was
assigning keys which either didn't properly describe the event, or
were completely unrelated to it, and then having to change the
definition in software to match the actual use. Picture-In-Picture is
a great example of this. There's no defines that cover any of the PIP
stuff so you're forced to use something totally unrelated
(KEY_WHATEVER) and then alter software so when you press KEY_WHATEVER,
what you really mean is <some PIP function here>.
Best regards,
Derek
