Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Just to put in my two cents on not highlighting or disabling...
I'm against it. I think if we give the user the status, either visually with color or the "mouseOver" status line
at the bottom and they still want to select a game that's not available that's their problem. It's just like mlb.tv
online. There's nothing stopping them from selecting the MLBTV logo next to a game that's not available.
As a test engineer by trade, I'm against developers trying to "fix" or prevent user stupidity. As long as user
stupidity doesn't crash the program, let them be as stupid as they want to be. By all means, put up a sign next to the
cliff (e.g. make the status available to the user in a format that makes sense to the user.) If the user still wants to
jump off the cliff, that's their prerogative.
I've seen way too many programs handicapped to try to prevent stupidity.
"The difference between genius and stupidity is that there are limits to genius"
-- Albert Einstein
Ok, you beat me to my patch, so I'll leave mine out.
Looks good, daftcat. My solution was to display all games with the status appended to the end (e.g. "Chicago White Sox and Boston Red Sox: 7:00 PM (Pregame)") so that you could see at a glance which games were available/archived/etc.
Regarding disabling execution of viewer for unavail games, I don't think it's really a matter of preventing stupidity, but rather offering appropriate actions when they are available. Perhaps it's appropriate to take other options contextually: if the user hits enter on a future game, the mlbviewer app could say "Waiting for game to begin..." and just sleep & refresh until the game is ready.
Anyway, not very important either way. I get the impression that 99% of us are simply happy to be able to see baseball.
Very cool. Just posted a new version online with the statusline part put in, and all games available for view.
Daftcat, let me know if you'd prefer to be credited in the change log with a proper name, web site, anything else.
The only change I made was to add the local blackout option. The games are still available, but the statusline shows the Mets and Yankees (for me) as being blacked out while the game is live.
So there's an "LB": "Status Local Blackout" line in the statusline dict, and getListings() returns
Code:
return [(elem[1]['text'],elem[1]['event_time'],\
elem[1][str(myspeed)],\
(elem[1]['status'], "LB")[
(elem[1]['home'] in blackout or
elem[1]['away'] in blackout)\
and elem[1]['status'] in ('I','W','P')
])\
for elem in listings]
The part with the blackouts is terse (boolean 0 or 1 returns the first or second element of the tuple) but it gets the job done.
There's no other clear way to get this information, short of a whole lot of nonsense with ifconfig, mlb's bizarre blackout map, and resolving ips.
Oh, one more thing. I might be out of the house for the majority of the weekend. If anyone's watching games, or at the computer, could they take a look and see how the schedule indicates national blackout? I remember it's in a different place than the status, but I don't quite remember where.
I'm just curious, is there's a long range plan to support audio only streams (GameDay Audio) support in your script? I think you mentioned it early on, but I haven't heard about it recently (understandably, as you've been working out the rough spots with the video support).
I think if we give the user the status, either visually with color or the "mouseOver" status line
at the bottom and they still want to select a game that's not available that's their problem. It's just like mlb.tv
online. There's nothing stopping them from selecting the MLBTV logo next to a game that's not available.
Fair enough. But if the status is P, PO, LB, I think there should just be an immediate "Nothing to see here" message if they do click? As opposed to logginh in to the server, finding nothing, throwing an exception, getting an error.
Why waste the time if we know that nothing will be there? And, until we get the cookie/logout thing worked out, why waste the login?
I'm just curious, is there's a long range plan to support audio only streams (GameDay Audio) support in your script? I think you mentioned it early on, but I haven't heard about it recently (understandably, as you've been working out the rough spots with the video support).
Sure. Theoretically, it's just waiting for someone with 45 minuts of free time to implement it. trimTVList() would have to be extended a bit (just add an 'elif['audio'] part after the if['mlbtv']). And then the construction of the list of games would need to include the audio id as well. I already named the configuration option "video_player" to allow for a different "audio_player" (xmms, or whatever) later on.
One very practical problem, though, is that I don't offhand know how the interface would look. Would you move side to side on a line? Have options in status line after you press enter? Or just different buttons (enter for video, "a" for audio? User configurable)? It seems like there's probably a good solution out there (daftcat, perhaps?).
As a test engineer by trade, I'm a big fan of exposing API's and supporting scripting such that if a certain feature or interface is limiting, an enterprising user can develop their own. That's a long range plan though.
Short term, I wonder about implementing cursor buttons for "A", "V" and eventually "RA" and "RV" (for recording.) The thing I wonder most about is the presentation. For example, if the Arizona Diamondbacks play the Los Angeles Angels Of Anaheim, that's a lot of text to try to fit in even without cluttering up the view with "buttons" Plus the logic of how the cursor moves through the buttons, might get hairy.
The other option I can think of which I alluded to awhile back is supporting multiple curses windows. We could block out a menu window, a listings window, and a status window. The menu window can have:
*Right now it's pretty easy because the season is barely two weeks old. But when Cueto is looking like a shoe-in for Rookie Of The Year in late August and September and I want to go back and watch his debut, it would be easier to reset my system clock back to April than use the arrow keys to go back several months.
Jkr, continue to refine the API and separate out the engine from the interface. I'll look at implementing some menu and keybindings. A lot of this would be very useful for mlbrecord anyway.
Fair enough. But if the status is P, PO, LB, I think there should just be an immediate "Nothing to see here" message if they do click? As opposed to logginh in to the server, finding nothing, throwing an exception, getting an error.
Why waste the time if we know that nothing will be there? And, until we get the cookie/logout thing worked out, why waste the login?
Because it's code I'll have to strip out for mlbrecord where I will be allowing users to select games in P status. ;-)
I honestly give users more credit than that. I say save your effort for more important nuts and bolts and if you start getting bug reports about folks wanting to play games in those statuses, then we can patch up those holes. Like I said, as long as a user selecting one of those doesn't crash the app, I think we shouldn't deny them the pleasure of banging their head against a wall if that's what turns them on. ;-)
One small caveat and fix suggestion. You should put in the top bar that all game times are in ET. If you're feeling really generous, you could convert the times to localtime but I'm not sure how easy that would be in Python. I still haven't looked much into timezone support but I know I'll have to for mlbrecord.
I added this to my copy which you may choose to incorporate into the official release.
if c in ('Help', ord('h')):
# help - print an about line for now
myscr.clear()
myscr.addstr(0,0,VERSION)
myscr.addstr(3,0,'Help Screen Coming Soon')
myscr.addstr(curses.LINES-1,0,'Press a key to continue...')
myscr.getch()
myscr.refresh()
The motivation for this so that I don't have to search this thread for the download link every time you update (or I botch my copy beyond functioning.)
Eventually, we can make this a proper help screen with key bindings.
I'll look into simple key toggles for video, audio, and speed. I'm also thinking that we should support different video_player lines for 400k and 800k since each would need a different -vf crop line to remove the black bars. video_player should remain supported for backwards compatibility and simplicity but if a video_player_800 or video_player_400 exists in the config, we should use that as an override. I will put the toggle statuses in the statusline.
So a statusline may look like:
Status: In Progress [VIDEO][400k]
If the user types 's' the speed toggles to 800k and the line updates to:
Status: In Progress [VIDEO][800k]
If the user types 'a' the line changes to:
Status: In Progress [AUDIO][N/A]
And if the user types 'v' the line changes back to:
Status: In Progress [VIDEO][800k]
[EDIT]
LQ is stripping whitespace. The toggle flags will be at the far right corner of the statusbar so as to not confuse the toggle flags with the game status as LQ is implying. I might be able to generate a screenshot by the end of the day. I have a lot of bic time today (bic=butt-in-chair, another way of saying nothing to do at work but keep the seat warm.)
I might have this patch done this weekend including the help screen with the key bindings.
What do people feel about color? Should we add color support? Should we make the game text a different color depending on the status?
How difficult would it be to go back to monochrome if there's some users who don't like the colors?
Or rather, would the color code explode on someone if their screen didn't support colors or is all that already handled in the nuts and bolts of curses?
I can envision an awesome splash screen generated by alternating the background color. An online ascii art generator already gave me the code to create the MLB logo in ascii. Replacing that code with white space and alternating the background color would give us a pretty good blocked out version of the logo. I could probably feed it a modified version of the mlb logo with tux silhouette as the ball player in the logo.
But audio is looking like a bigger task than I thought it would be. Since speed isn't useful to audio, I should change the dictionary key for feed and expand the listings code.
Temporarily, I'm going to one-off the mlbviewer and make a mlbaudio script. I'll let jkr decide how he wants to combine the two.
Color is great for the interface. Splash screen sounds fine to add, but as with other things, I would say there should be an option to turn it off (splash=0). I would go crazy if I had to deal with the emacs splash screen every time I opened it up to edit something.
As a promise of cool stuff in the future, though, and speaking of interfaces, I just wanted to send you to a link of about 5 minutes worth of work, using wxPython and the already existing classes. Great thing about this gui library is that it's already cross-platform (much more so than python-curses). This is just an example, but I think some people might like this. And if anyone is actually good at programming wxPython, you know, make yourself heard.
Daftcat-- I'll add those bits to the file soon. Things sound great. I might not get the chance to update the official script, so in the next day or two, I'll set up an svn repos on sourceforge, and people can update, branch, etc. to their hearts' content.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.