[xine-devel] [PATCH] Adding number inputs to xine-ui

[R. B. <ro...@pa...>]

There was a recent change to xine-lib to add events for numeric
input. However a corresponding change needs to be done to xine-ui
(kbinding.{h,c} and events.c) to allow the keys to get mapped to the
xine-lib events.  

If I've done things correctly via the sourceforge bug submission
mechanism, I've submitted a patch for this and wrote a little bit
about the changes. I took the opportunity to make a change which
I think cleans up handling input events up a tad.

It appears that in order to bind keys to the new events you need to
have definitions of the keys (in kbindings.c). And since the numbers
were already bound to events, to be upward compatible, I used unused
values. Basically added the "mod3" modifier to the number.

However here, I'd like to argue that the existing assignments to the
numbers should be moved and the number be used for inserting
numbers. Why:

1. Well, they are numbers. So there is a sort of a natural logic to
   bind them to that.

2. But you say, what about the existing bindings: SetPosition10%,
   SetPosition20%, ... SetPosition90%?

   Uh, first of all these aren't that general. I wonder how much they
   are used?  If the input plugin doesn't support seeking, then these
   probably can't do anything.  Second, there are many other buttons
   that handle positioning like slider bar on the gui -- okay so you
   say you don't have/use the gui.  Then there is the SeekRelativexxx
   actions. Hey if we had numeric input, maybe all of these (and many
   others like WindowXXX, could be reduced to fewer bindings. For
   example: "Numeric 5" followed by "SeekRelativeForward." Numeric
   input allows not only for fewer defined actions but for more
   generality of them as well.

3. The implementation of SetPosition is bogus. Here's what is in
   event.c

  case ACTID_SET_CURPOS_10:
    gui_set_current_position (6553);
    break;

  case ACTID_SET_CURPOS_20:
    gui_set_current_position (13107);
    break;

  case ACTID_SET_CURPOS_30:
    gui_set_current_position (19660);
    break;

  case ACTID_SET_CURPOS_40:
    gui_set_current_position (26214);
    break;

  case ACTID_SET_CURPOS_50:
    gui_set_current_position (32767);
    break;
    
  case ACTID_SET_CURPOS_60:
    gui_set_current_position (39321);
    break;

  case ACTID_SET_CURPOS_70:
    gui_set_current_position (45874);
    break;
    
  case ACTID_SET_CURPOS_80:
    gui_set_current_position (52428);
    break;
    
  case ACTID_SET_CURPOS_90:
    gui_set_current_position (58981);
    break;

  where the parameter number (e.g. 6553) is a seek offset. So can anyone
  explain how it is that 6553 is 10% of the input one happens to be
  using?

4. But no one uses the numeric input right now! Yep, it's been
   non-existent so of course no one uses it. :-) The key bindings
   probably grew by accretion. Given that xine hasn't gotten to
   version 1.0 yet, it might not be to late and not a bad idea to
   occasionally rethink things.

5. But I really need SetPosition60%! Well you can rebind it to any key
   you want, for example 6, in your ~/.xine/keymap file. (That's what
   I currently do with the number entries right now.) 

I've been working on this input plugin for VCD's. Current thought
right now is to make it a bit modal. Right now, if the MRL you select
is based on a "track" then next/previous go to the next track. However
on VCD's each track (or segment) can have various offsets within that
it. Sort of like a Title/Chapter in DVD-land. If you start with a MRL
that specifies an "entry" then next/previous mean to the next entry,
not next track. And of course if you have playback control (PBC) on,
then next/previous mean what has been specified there. The numeric
selections become real useful here for navigation. My take is that
moving around by Title, Chapter (or track, entry, selection) has got
to be more popular than by 10%, 20%, 30% (which can be done by the
gui, when it is available). But even if there is ground swell for this,
my or any other plugin could just map the number keys on a particular
mode to do that. And I promise if I do that I'll probably get that
SetPosition90% 100% accurate.

- - - - -
Siggi once asked...

  Are you sure that the "+10" key can be considered standard?

The one answer I got from: 
  http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=009DnP

suggests it is.