[mythtv] Re: [mythtv-commits] mythtv commits

[Isaac Richards]

On Thursday 21 April 2005 10:06 pm, Neil Whelchel wrote:
> Hello,
> I disagree..
> As I said in one of my previous messages, there are a few of out here that
> do not use lirc. Some of us use a remote like the Firefly or the X10, or
> something that directly sends key press events, so this makes it a bit
> tough to use irxevent or something similar.

So write another program that listens for events.  It's not hard.

> Also, I am running mythtv completely embedded from ROM (the front end), so
> there is really not much room for a window manager, not to mention that on
> a dedicated unit (not embedded), I have always had better success by
> ditching the wm, so this route is not for everyone either.

A window manager is required for full operation of myth.  If you're not using 
one, you've got bugs.  irxevent's tiny - there's no reason to believe that a 
similar app for whatever input device you wanted would be any larger.

> So, where is the project going anyway.. Is this aiming to be an app
> that runs on a desktop machine along with other programs, or is it heading
> for the ability to be used as a stand alone media system (possibly
> embedded), as well as a desktop application.

A standalone media system doesn't need to reimplement every single app under 
the sun inside of it.  And if it _were_ completely stanalone, you'd not need 
to run external applications from a keypress, hmm?

> If the answer is the latter, Mythtv needs to have everything within the
> gui to configure a machine from zero, and I might point out that I have
> patched it to do as much at the moment. (All it needed was a way to
> configure where it mounts the shared media directory and the Ethernet
> configuration, and I can do every bit of front end configuration that I
> will ever need to do to make an embedded frontend.)

Or within a separate UI that's part of the OS install.

This patch isn't going in to Myth.  Neither is a shell, or gcc, or the kernel.  
Stuff that's better implemented elsewhere, is, well, better implemented 
elsewhere.

Isaac