[mythtv-users] Re: Two Bugs in Mythtv v0.11 & Two UsabilityRequests

[Joseph A. Caputo]

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org
> [mailto:mythtv-users-bounces at mythtv.org]On Behalf Of Keith C
> Sent: Wednesday, August 27, 2003 11:06 AM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Re: Two Bugs in Mythtv v0.11 & Two
> UsabilityRequests
>
>
> I also think usability requests are fine in this forum, as it is being
> used by both programmers and users. If I was to mention a function I
> thought would be useful, maybe someone with good experience with the
> MythTV source would be inspired to add it.  I'd love to add it myself
> and might be able to, but I'd probably just break stuff.
>
> That said, here's a feature I would love to see : Global keys. For
> instance, a key that would take you to live TV regardless of where you
> were in MythTV, and another one to the Watch Recordings list.  This
> sounds easy, but I think with modular layout of MythTV, it might
> actually be a little painful.  Anyways, I'll start looking at the code
> myself, but if any of the normal geniuses are inspired, go for it.
>
> Keith C

I've given a lot of thought to global keys (and also run-time configurable
keybindings).  One of the main problems in implementing global keys is the
serial nature of Myth GUI traversal.  By that I mean that most windows are
arranged in a hierarchical, parent-child manner.  Only the parent knows how
to bring up the child, and the only way to get from the child to an ancestor
is to pop (destroy) child windows until the ancestor is reached.  In order
for global keys to work well, most windows should be able to instantiate
themselves.  There's also the issue of different classes of windows.  For
instance, it would probably nice for certain screens to be persistent (a
single instance that just gets popped to the front when it's requested).
However, we don't want too many of these because we could end up hogging a
lot of resources.  So another class of windows is needed, one which can be
globally requested but destroys itself when it detects that a 'global'
(rather than a child) window has obscured it.  The third class would be
'child' windows, including pop-ups and screens such as the Advanced
Recording Options screen, which are context-specific in relation to the
parent.  Such windows would probably want to ignore global keys.

Another feature that would be desirable in a 'global keys' situation would
be for the bulk of Myth windows to have a 'hole' for the currently playing
video (whether a recording or livetv), simliar to the EPG does now.

I'm not suggesting that the approach I've outlined is the most correct way
to address global keys; I merely wanted to illustrate the magnitude of the
effort.  I decided that it would require more time than I have available,
and would likely require a serious overhaul of the Myth user interface
infrastructure.

All that being said, a very simple 'global keys' implementation that merely
allowed one to launch a plugin (and possibly a limited number of other
functions) from anywhere would probably be much easier to implement.

Anyway, that's just me shootin' off my mouth again.  I'm probably
over-complicating things... I'd be interested to hear what your assessment
is.

-JAC