[mythtv-users] What major features are planned for 0.27?
fatgerman at gmail.com
Mon Nov 26 18:54:42 UTC 2012
On Monday 26 Nov 2012 12:39:23 jedi wrote:
> On Sat, Nov 24, 2012 at 03:57:22PM +0000, Mark Greenwood wrote:
> > On Saturday 24 Nov 2012 10:19:01 Michael T. Dean wrote:
> > > On 11/24/2012 08:48 AM, Mark Greenwood wrote:
> > > > On Friday 23 Nov 2012 22:37:34 Michael T. Dean wrote:
> > > >> On 11/23/2012 10:02 PM, Preston Crow wrote:
> > > >>> On 11/23/12 21:58, Michael T. Dean wrote:
> > > >>>> On 11/21/2012 10:10 AM, Mark Greenwood wrote:
> > > >>>>> One thing that could be contributed though, and I don't know how
> > > >>>>> easy/hard this would be but with pointers I'd be prepared to look into
> > > >>>>> it, would be to make mythtv understand the multimedia keycodes sent by
> > > >>>>> IR remotes that are handled by the kernel's devinput interface (eg
> > > >>>>> KEY_PLAY, KEY_FASTFORWARD etc). Xbmc understands these natively and
> > > >>>>> means I didn't have to go through the trauma of setting up lirc.
> > > >>>> Pretty sure you just need to use mythfrontend's Edit Keys to set what
> > > >>>> you want each to do.
> > > >>> Yes, but the point is that this is something that should just work
> > > >>> without doing anything. There should be good default settings for all
> > > >>> those keycodes already. (This hasn't impacted me, but it sounds like
> > > >>> a simple and obvious improvement.)
> > > >> Of course, you do understand that there are both TV Playback|PLAY, and
> > > >> TV Playback|PAUSE (which is toggle play/pause).
> > > >>
> > > >> It's neither simple, nor obvious, to me which one the play button on
> > > >> Mark's remote should send... And the play button is the simplest of the
> > > >> multimedia ones... Does fast forward do a Global|RIGHT or TV
> > > >> Playback|SEEKFFWD or TV Playback|FFWDSTICKY or even TV Playback|JUMPFFWD?
> > > > Actually it's only complicated because mythtv makes things complicated by having too many choices. XBMC seems to take a much more pragmatic view. In a logical, simple world the Play key starts playback, the Pause key pauses and unpauses, and the Fast Forward button fast forwards - just like on any off-the-shelf PVR system made in the last 30 years, because people understand that. It's obvious what the default settings should be, and people can still customize if they want to.
> > > >
> > > > The keys on my remote are already mapped by the kernel's ir-keytable interface - no need for LIRC. The mapping means that whatever your remote, the kernel sends something sensible - KEY_PLAY when you press Play, KEY_FASTFORWARD for FF etc, so assigning them to functions the average PVR should have should be simple. Of course there will alays be some that need tweaking by the user, but a sensible set of defaults that would work with any remote of this type wouldn't be hard to come up with. LIRC is pretty old hat these days, the latest kernel has mappings for most of the common remotes already.
> > > >
> > >
> > > Yes, and anyone who uses the built-in-to-the-kernel key mappings for the
> > > remote buttons then ends up changing the key bindings in /every/ single
> > > application on their system so that the remote button that sends an A
> > > (or KEY_A) does the appropriate thing in that application*** (and has to
> > > learn their custom keymaps/can't discuss default bindings/...). And, to
> > > make it worse, for users with multiple frontends, using kernel key
> > > mappings for the remote means customizing every single mythfrontend on
> > > every single system (not to mention also customizing xine, mplayer, vlc,
> > > xmms, xmms2, audacious, ...
> > >
> > But that's exactly the point. The remote buttons don't send standard keyboard keys. The in-kernel mappings send KEY_PLAY, KEY_PAUSE, KEY_STOP, etc and not KEY_P, KEY_S, KEY_A etc. So there *is* a standard set of keys for a remote, just as there is for a keyboard. The point is that mythtv doesn't appear to recognise these 'multimedia' keys. If it did, most remotes would 'just work' without LIRC and without any special configuration. Plenty of applications now support these keys in addition to the old 'standard' keyboard shortcuts.
> Having conventions for what goes into /etc/lirc is sufficient. You don't
> have to implement a system that is LESS configurable and LESS in the control
> of the end user just to have something that is more manageable to a certain
> class of user.
Well that's really my issue. I DO want less configuration. Less configuration is good. Or rather, I like to be able to *customize*, but I don't want to *have* to configure *just* to get stuff working. That "certain class of user" is the majority of people (though I'll grant you probably not the majority of Myth users), it's one reason why Apple products are so popular and Linux is ignored even by many people who could manage it.
Here's what I mean. Setting up mythtv-frontend is still, after 4 years, something I do with fear. It takes hours. Setting up XBMC was as simple as 'sudo apt-get install XBMC'. I was watching videos *and* using my remote within 5 minutes. This is because it has sensible defaults for everything and responds sensibly to appropriate button codes.
I know it's two different poins of view, and both are equally valid. It's obvious which side of the fence I'm on and which side the Myth devs are on :) I shall take my pleas for ease of use elsewhere :)
(NB I worked as a UI usability tester for 10 years. I've spent half my working life listening to a "certain class of user" explaining to me why the UI doesn't make sense. I do think I know what I'm talking about).
> Having something like LIRC in the middle allows for a level of abstraction
> and the ability to easily support both standardization and legacy users.
> The latest *buntu can knarfle the button codes and I can unkarfle them to
> what I have been using for 6 years already. Apps don't need to care. Upstream
> developers for those apps don't need to care.
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users