Re: [xine-devel] DVD menu selection broken...

[Michael R. <mr...@us...>]

Hi Siggi,

> > I hope I got it fixed in cvs now once and for all. (This NAV packet
> > reading was really messy. Every plugin (input_dvd, libspudec,
> > dxr3_spu) had its own code for that. And with the new libdvdread
> > everything became incompatible. Now they should all use libdvdread
> > code.
> >
> > Could anyone who saw the problem try, if it is fixed now? Thanks.
>
> Yup, that fixed it for me. Big Thanks!
>
> Oh, and while we're at it, I have a little feature request regarding
> mouse navigation: On some DVDs, the buttons are unnecessarily small,
> eg I tested "Kentucky Fried Movie" (R1), which has a menu like this:
>
[snip ASCII art broken by KMail quoting - I am too lazy to hand-quote]
>
> The stupid thing is that you actually have to klick the text in order
> to select an option.
> Is it possible to just select the nearest button on mouse clicks, so
> it even works if you miss the authored buttons?
> (I know, this is working around badly authored DVDs, but it would
> help navigating quite some of them...)

Daniel once requested that we should not activate any buttons, when not 
clicking any buttons. (Earlier versions selected the currently highlit 
button, when clicking in a no-button region.) I generally agree to that 
approach.
I also made some thought on the problem of very little button areas and 
thought it would be nice to add some tolerance for small buttons, but 
after looking at a couple of DVD menus, I decided not to do this, 
because there are button layouts, where the nearest button is not the 
one your intuition would want. Example? Here we go:

    Menu Text 1 <
  > Menu Text 2
    Menu Text 3 <
  > Menu Text 4

The "Menu Text ?" are background image, only the ">" and "<" are actual 
button areas. When now pointing with the mouse on the "T" of the second 
entry, the closest button could be the first, second or third, 
depending on the exact position. I found this quite bad and thought it 
would be better to leave things as they are for two reasons:
* libdvdnav is just a library; when I implement heuristics like this,
  I make the (possibly wrong) assumption, that all frontends would want
  such behaviour
* for such computer-unfriendly menu layouts, we still have the numeric
  keypad to navigate in

If you have any idea on a nice heuristics that would work in critical 
menus like the example above, let me know.

Michael

-- 
"This vulnerability is completely theoretical!"
	-Microsoft