[Kaffeine-user] A first cut of a new full screen interface for Kaffeine.

[John M. <jw...@es...>]

The interface consists of a tool bar for the standard media play controls,
and a menu bar to access any controls not on the tool bar, various
interactive configuration items that can't be shoehorned into the tool bar,
and various in-stream options like particular video and audio sub-streams
(DVD camera angles, audio commentaries and languages) and subtitles. 

The tool bar and menu bar will be placed at the edges of the screen, which
places them as far out of the way of the action as possible (exploiting
the black bands of one aspect ratio displayed on another), and allows the
access to the buttons and menus to be accelerated due to the pinning
effect of the edges of the screen on the pointer. 

The specific edges used should be user configurable to some extent. The 
menu bar can only readily be placed at the top or bottom of the screen, 
while the tool bar can be placed against any side. When placed against the
left or right side, the menu bar's first or last menu should be displaced
along so they don't overlap the tool bar. The obvious standard setup would
be to put the menu bar at the top and the tool bar at the bottom, but for
16:9 displays, it may make more sense to place the tool bar on the
left or right hand side to exploit the black band created by 4:3 material. 

The tool bar and menu should be hidden during playback and made visible by
either clicking the left mouse button, or action key for cursor based
navigation, or by pinning the mouse pointer to any corner. (We use the
mouse click/action button option mainly so cursor input can pop the
controls up, but, if the pause/resume button is on one corner of the tool
bar, move-pointer-to-corner, click is faster than click,
move-pointer-to-corner, click. And making the right mouse button the
pause/resume hot key is fastest of all. We also avoid activating the
controls on moving to any side, as this leaves users with no edge that
they can just chuck the pointer to when finished.)

The controls should use the same visibility mechanic as the pointer to
decide when to hide again, subject to two additional rules - if the
pointer is overing over the menu or tool bar, increase the timeout to
something like 30 seconds (configurable?), and when the pointer is
hovering over an open menu, stop the timer until the menu is closed again.

Fonts used for all elements - the menu bar, the tool bar with text switched
on, tool tips, etc - should be increased in size by some full screen
specific font adjustment. A factor of about 150% to 200% would make a good
default, but this should be configurable.

The tool bar should contain the standard control buttons; pause/resume/play,
stop, back one play-list  item, forward one play-list item, fast forward and
rewind. It should be configurable so that the order and contents can be 
changed by the user, and certain media specific options can go there. For
example, save stream, a full screen/windowed toggle, cycling through DVD
camera angles,  cycling through subtitles and audio streams (commentary,
languages) could all be tool bar buttons. 

The size of the bar should be the length of the side it's on, and a height
(width) based on the size of the blacked out strips of the display when
displaying the opposite kind of aspect ratio - ie if using a
4:3 monitor, the height of the bar ought to be about 95% of the black bar
displayed when displaying 16:9 content.

Buttons should expand to evenly fill the length of the bar. They should
have the out of focus buffer around the edge adjacent to the edge of the
screen removed so that they can be clicked on when the pointer is pinned
to the edge. They'll need to have some visual indication of being in focus
for both the cursor and pointer inputs.

The menu bar is just a straightforward top of the window affair, except
the text is set to the full screen scale factor size, and the tops (or
bottoms) of the menu buttons should extend to the edge of the screen.

As the menu buttons are larger, due to the increased font size, the amount
of menus that can hang off the menu bar is decreased, and due to the
titles of the buttons varying by locale, it's wise to have one or two less
menus that might otherwise fill the bar. 

The contents of the menus should be limited to things that are
of use during playback, and ought to avoid sub-menus if possible, as they
tend to be hard access and they complicate the cursor base navigation
model (more below). 

Candidates for menus might include: 

 - the contents of the play-list, to enable fast access to specific songs,
 chapters, whatever. 

 - 'Camera angles', or whatever you might call alternative video
 sub-streams. Greyed out if their are none.

 - 'Audio channels', like audio commentaries or alternative languages.

 - Subtitles and subtitles for the deaf.

 - Interactive configuration options, like toggling audio profiles,
 filtering options, aspect ratios, etc

 - Bookmarks. Just like the play-list, really.

Most of the settings related to putting things into and generally
manipulating the play-list should happen in the play-list, rather than via
menus accessed in full screen mode. 

Cursor navigation should work as follows. The initial action button will
bring up the controls. Initial focus should go to the left/top most tool
bar item, which will probably be the pause/resume/play button, but it
could be configured to start on the left most menu item, or a particular
tool bar button, regardless of where it appears. Use left and right, or up
and down, depending on the orientation of the tool bar to move to
different buttons, and the action key activates them, as you'd
expect. Traversal of the bar shouldn't wrap around; you should be able to
hold a cursor key down to zip to the end of the bar and be pinned there.

Moving along the axis perpendicular to the tool bar, and away from the
edge of the screen should move you to the menu bar, and vice versa. If the
menu bar and tool bar are at opposite ends of the screen (ie top and
bottom), then moving from the nth from the left item on one should place
the focus on the nth from left of the other. The case where the menu is at
the top or bottom but the tool bar is left or right is a bit trickier; I
think moving left(right) from any point on the tool bar should take you to
the left(right) most menu item, while moving back from the menu should
return you to the focus point you left. But this case needs usability
testing.

For the menu bar itself, you should hit the action key to pop up a given
menu, at which point the menu stays open until you move left or right to
another menu button, or you move down(up) the menu and back up to the
button. Moving down(up) from the last menu item shouldn't send you to the
tool bar!. 

Which leaves hot keys. For the mouse, pause/resume on right click,
and full screen on the middle are good, but the mouse wheel ought to do
something less disruptive than fast forward/reverse, such as control the
volume (using a gradient that will require a few turns to take it from
silent to ear splitting). The rest of the desktop oriented hot keys should
require a modifier, like shift, to avoid having them triggered by an
accidental brush of the keyboard in the dark. This will also make cursor
navigation work at all.




Ok. I'd like to implement this, but I have to get to grips with the
mysteries of C++ and KDE/Qt from a C/perl/python background, with a little
tinkering in X and with tk and wxWindows. And I expect some of the things
I've specified fall off the beaten path of standard widgets, so I expect
someone who knows their way around some KDE programming will be able to
get something up and running months before I could. I'd probably try to
build the interface in this order:

 - drop the pop up menu and create a top menu and bottom tool bar with
 standard widgets (ktoolbar, etc). Populate the menu with the things I've
 discussed and drop the rest for the play-list or desktop to handle.
 Have it unhide on left click and hide when the mouse does.

 - Add a configuration dialog to control the positioning and populating
 of the menu and tool bars.

 - Figure out how to make tool bar buttons expand to full the
 bar. Calculate the bar height(width) based on the screen size and aspect
 ratio, so it's a bit smaller than the black band you get playing 16:9 on
 4:3 or vice versa. 
 
 - Figure out how to apply a scale factor to the fonts of all the relevant
 widgets and place it in the configuration dialog.

 - Figure out how to pop up on pinning to the corners.

 - Figure out how to extend the focus areas around menu and tool buttons
 so you can click on them while pinned to a corner or edge.

 - Set up the cursor based focus navigation. Allow the menu or a button
 on the tool bar to take first focus.

 - Everything else

 - Test, test, test - various input devices, usability.

Comments?

John