[mythtv] Re:mythDVD module v0.0 released

Michael Kedl kedlm at knology.net
Wed Jul 16 22:37:08 EDT 2003

I have another version of the mythdialog/mythripdvdstat I'll send along
shortly. (later 2nite I hope)

I just thought I'd mention that I resurrected mythdialog from the grave
on my end and have it re-integrated into the .10 libraries.

The reason I want/need it is so I can asyncronously display these status
dialogs if desired by the user.

I had to change libmyth to get it to work, but now it reads the updated
data and redisplays without me having to respawn it.  Much smoother :-)

No longer a need for Xdialog if we were to check back in mythdialog so
the menu and code cleans up a little.

I envision using mythdialog to display my caller ID and such shortly
too.  It will popup when a notice comes in over the network from the
machine with the modem in it.

Should be useful for "new email", "new aim", "reminders from your
calendar", "weather warning", etc. notifications too.  It will update as
needed as long as up, and the user can dismiss it, or it can remove
itself after a timeout.  Probably need to add an option to display as a
history list so your notifications will scroll; didn't want that with
the dvd updating version... 

I "hope" I get it ready 2nite; but this time I will have to do diffs on
the library as well as package up the mythdvd changes.


On Wed, 2003-07-16 at 19:57, Dwight Hubbard (dhubbard) wrote:
> I agree that a bunch of shell scripts currently wouldn't be a good idea as
> an offical module.  However, I think that being able to develop mythtv
> plugins using a scripting language has enormous potential.
> I'm envisioning something along the lines of perl and python bindings for
> the various mythtv modules.  Although, an Xdialog work-alike that uses
> mythtv widgets would also have potential.
> The three reasons I can see this as an advantage are:
>   1. Lowers the level of programming skill needed to implement modules.
>   2. Would make prototyping ideas easier.
>   3. Would make mythtv more flexible (I'm thinking advanced theming like
> Karamba does, where themes could combine functionality from different
> modules and implement new functionality).  I.E. a theme becomes a perl
> or python script that can change the logic in how the mythtv interface
> works instead of the current static xml file.  (Yes I realize this is a
> pipe dream that would take quite a bit of work)
> > On Wednesday 16 July 2003 05:28 pm, Michael Kedl wrote:
> >> I believe the idea is to stick these choices in the settings screen when
> >> the idea itself is well tested and accepted.
> >
> > A couple of shell scripts aren't going to be accepted as an official
> > plugin/module.
> >
> > Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-dev
Michael Kedl <kedlm at knology.net>

More information about the mythtv-dev mailing list