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.
This is based on an older version of our VERSION text but we can change that.
Please keep in mind the splash screen is only there to serve as a buffer between the time you start the application and when the listings load. There are no additional sleep commands in the splash code. So under normal network conditions, the amount of time this screen would be displayed would be relatively short (unlike Adobe Photoshop or Gimp, for example.)
What do you think?
a) Keep it simple. I like the splash the way it is.
b) That rocks. Let's go with it.
c) I'm indifferent.
I'm guessing just based on the time difference between this post and jkr's that you just missed his check-in. Try checking it out again.
I'll see if I can re-raise the Exception when debug is enabled just in case we're masking something else. Debug is intended to let most errors drop through like a lead ball so we can find the "unknown" errors.
Pulled it down on another machine and it all worked fine. May just have been timing. I'll go back and try the original.
This is based on an older version of our VERSION text but we can change that.
Please keep in mind the splash screen is only there to serve as a buffer between the time you start the application and when the listings load. There are no additional sleep commands in the splash code. So under normal network conditions, the amount of time this screen would be displayed would be relatively short (unlike Adobe Photoshop or Gimp, for example.)
What do you think?
a) Keep it simple. I like the splash the way it is.
b) That rocks. Let's go with it.
c) I'm indifferent.
I would actually go for (a). Not necessarily because of personal preference (I'm pretty indifferent, as far as that goes), but because MLB is one of those entities that is *very* touchy about its brand property. And this logo possibly moreso than anything else, since it signifies their imprimatur (a real, licensed cap vs. a knockoff). Frankly, we probably shouldn't even be using 'mlb' in the program name, but I don't think that's a big deal. This, though, might actually lead to a cease and desist if we released with it.
I would actually go for (a). Not necessarily because of personal preference (I'm pretty indifferent, as far as that goes), but because MLB is one of those entities that is *very* touchy about its brand property. And this logo possibly moreso than anything else, since it signifies their imprimatur (a real, licensed cap vs. a knockoff). Frankly, we probably shouldn't even be using 'mlb' in the program name, but I don't think that's a big deal. This, though, might actually lead to a cease and desist if we released with it.
a) Keep it simple. I like the splash the way it is.
b) That rocks. Let's go with it.
c) I'm indifferent.
How about "b". I like it plus I'd like to see if they are petty enough to whine about it. I suspect they may be, however. I wish I wasn't addicted to MLB, I gag every time I end up giving them any money.
I really like the addition of the top play listings, it's great stuff.
I'm with jkr on the logo, there's no sense in doing anything to upset major league baseball. That's not to say you shouldn't add some sort of splash screen, just that it shouldn't look like a copyrighted image.
Is there any way to let us make our own ASCII splash screen (and maybe put a variable somewhere to let it know where to put the version info)? That way if people wanted, they could make the MLB or their team's logo in ASCII art, but it wouldn't be officially released with it so it shouldn't attract the hounds
Is there any way to let us make our own ASCII splash screen (and maybe put a variable somewhere to let it know where to put the version info)? That way if people wanted, they could make the MLB or their team's logo in ASCII art, but it wouldn't be officially released with it so it shouldn't attract the hounds
Ah, now this is the beauty of open source. This sounds like a great opportunity for you to look at our splash screen code (which is all of about four lines) and decide if you want to implement your own custom splash screen (which would bloat it up to about six or eight lines.)
The biggest problem I see with implementing a user-defined splash screen is replacing whatever user-defined tag with the version string. I guess if the user wants to go through all the trouble of formatting an ascii graphic that doesn't look like a$$ when cooked through curses, then it should be up to them to also figure out where to put the version string in, how long the version string will be, and go through all the iterations of poorly formatted splash screen until they get it right.
All in all, this doesn't really sound like a feature I want to implement--a very low bang to buck ratio. Try bribing me with tickets and maybe I'll reconsider. ;-) What's your local team?
I tried a knock-off of the MLB logo with a silhouetted Tux, the penguin, but it was virtually unrecognizable as a penguin and wasn't fat enough to accommodate a version string. Who wants a skinny penguin?!
I'm looking at the alarm clock feature and then I'm calling it done for this release. I probably should implement meta-refresh for "Estimated delay" pages but it might be more annoying to wait for our app to retry under network congestion conditions. Perhaps I'll just write a "mlb.com congestion" error message and call it a day.
I'd like to get a working version of mlbscores (which is behaving very badly right now) into the next release.
Is it more intuitive to use 'L' (or lowercase 'l' too) to return to listings from Top Plays or would you rather use 'q' to quit out of the Top Plays screen?
My feeling is that 'q' should work universally to quit the application no matter what screen you're in and thus, 'l' or 's' (when scores is implemented and integrated) would indicate which screen you want to go to next.
I propose a menu-based system where you go to the day and game you want and press "m". This would bring up a menu for that game where you could select:
Audio
Top Plays
Game Notes
Box Score
Record (if implemented)
"Esc" would be the universal "Back" function. It also makes it easier to add functions as menu items rather then assign them hotkeys to remember.
Ah, now this is the beauty of open source. This sounds like a great opportunity for you to look at our splash screen code (which is all of about four lines) and decide if you want to implement your own custom splash screen (which would bloat it up to about six or eight lines.)
The biggest problem I see with implementing a user-defined splash screen is replacing whatever user-defined tag with the version string. I guess if the user wants to go through all the trouble of formatting an ascii graphic that doesn't look like a$$ when cooked through curses, then it should be up to them to also figure out where to put the version string in, how long the version string will be, and go through all the iterations of poorly formatted splash screen until they get it right.
All in all, this doesn't really sound like a feature I want to implement--a very low bang to buck ratio. Try bribing me with tickets and maybe I'll reconsider. ;-) What's your local team?
Ahh, I hadn't looked at the code, and just thought you were feeding it in there in plain text, so thought you could just pull the text from a file. I may add my own in there, but then I would have to re-do the changes everytime I pull down new versions from svn right? (this is my first time using svn)
I'm from St. Louis, so I'm a Cardinals fan, although I don't live there anymore. I'm in Columbus, OH now, so I don't really have a 'local' team. I'm right in between Cincinnati, Cleveland, and Pittsburgh.
I propose a menu-based system where you go to the day and game you want and press "m". This would bring up a menu for that game where you could select:
Audio
Top Plays
Game Notes
Box Score
Record (if implemented)
"Esc" would be the universal "Back" function. It also makes it easier to add functions as menu items rather then assign them hotkeys to remember.
I hate menus because they are clutter magnets. What starts with a "Game" menu, turns into a "Preferences" menu, a "View", a "Help", etc. The other problem with menus is that we'd probably have to draw the menu differently based on the screen we're in, so it becomes another object to manage and more state to keep track of.
I hate "Back" buttons too. I like progress. If I want to start at listings, check the scores, see the line scores, the box scores, and then the highlight video of Alex Gordon's HR, I want to say, "take me to it" rather than retracing my steps until I reach a junction point again. I'm a big fan of hot keys because it's instant gratification (no hoops to jump through or menu options to look for.) From a code perspective, "back" functionality becomes a pain because then I have to keep a history of which screens you visited.
I can sympathize with having too many, though. Hotkeys is both a strength of mplayer and a point of contention. I find myself going to the docs or the man page frequently to figure out which hotkey does what I want. I think <enter> in jump prompt makes it easy enough to jump to today without wasting another hotkey on it. At least 'h' for help should work in every screen. ;-)
A compromise I could think of is to put hotkey hints at the bottom of the screen above the status bar like pine and nano (except without having to use the Ctrl-key to get anything done. ;-)
Another thing I'm talking to jkr about is supporting a core set of actions for each screen and implementing each screen as its own class. The screen would have to implement each core action (or print a "not supported" message.) The user experience would be a common set of methods like up/down/left/right/enter/jump/audio and selecting which screen they want to go to. This is similar to the web experience where you select your screen (scoreboard, standings, players, teams, etc) and your actions (play video, select date, give me more details.)
I'll look at the hotkey hint bar and see if it adds more value than clutter.
Maybe I wasn't clear. I said "back" when I meant "up," I suppose. Think of it this way:
You navigate to the game that interests you (the object) and then you press one button that gives you a list of things you can do with that object. "Escape" just gets you out of that. It would do the same thing the "L" key does when you're in the "Top Plays" menu.
You already use menus, I'm just suggesting using one more to make the program's features transparent. Not only does it eliminate the needs to remember (or use a legend) all the hotkeys, it allows users to see new features after an upgrade without having to dig through documentation or read changelogs.
Suppose MLBAM reinstates Condensed Games and you add support for it. If you have an "action" menu, users can clearly see that "Condensed Game" is now something they can do with their chosen game. Otherwise, they just have to know that pressing "C" will accomplish this.
I'm not proposing a menu system like desktop applications have (File, Edit, View, etc.) but more of a navigational vehicle, akin to MythTV, though simpler.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.