Michael Dellisanti wrote:
I am writing a custom remote control interface for a
new remote that I am creating and I am not sure what
the best way is to go about getting the status of the
player (play, pause, rew, ffw, etc). My code is very
similar to the lirc remote implementation - a separate
process is spawned out of the MythMainWindow
constructor. I would like to know the state of the
player so I can handle events from the remote
differently. If anyone could give me a pointer it
would be appreciated. Thanks.
It's going to be messy, but if you are getting your hands dirty anyway heres what I would really like to see implemented:
- Abstracted status object with generic status fields like CurrentModule, Progress, State (playing, paused, etc).
- Module is subclassed with extra status fields depending on which module we are actually in and so classes with awareness of the module specific fields can delve more deeply to find out what the current status is. For example the music might currently be "Status:playing" and "Progress: 15%", but an LCD panel would find it useful to know that the user was browsing the playlist editor and what the items on the screen were so that it could replicate them on the LCD panel
Does this make sense? Otherwise we will need to write the same custom "status" code for each module, and probably repeat it for each kind of device (LCD panel, web remote control, etc).
I think there are probably more fields which would be useful in the top level status object, but I personally think that I could write a basic remote control app knowing just those basic fields, ie which module we were currently in, Status enum (like play, paused), and current progress. Perhaps a "current play item" field would be useful as well?
These seem to apply to nearly all modules although it's strained a little with some of them. Consider the weather module which basically feels like a slideshow - we can use play/paused state here, and either the "progress" or "current play item" ends up telling the remote app which particular page we are on right now.
I don't think such a change needs to be a big change, at least for phase one just to get a rough status object in place? I hope some folks like Isaac might pour scorn on the concept before I or others waste some time building this...
Ed W _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
