Bugzilla – Bug 474
Multiple problems with INPUT.Text
Last modified: 2009-09-08 09:21:46 UTC
1. Slim::Buttons::Common::pushMode( $client, 'INPUT.Text', ... ) does not update the display when the mode is selected. The input appears after a button is pressed. 2. The callback function is executed in the INPUT.Text mode. It would be more clear to execute the callback in the parent mode (particularly if the parent is using specialized line handlers). 3. The reference passed in valueRef is suffixed with "\x(1f}rightarrow\x(1f}" when it is evaluated in the callback. 4. Popping back to the INPUT.Text mode leaves portions of the previous display on screen. 5. There is no practical mode default mapping.
1. haven't seen this one myself 2. this is how the imput modes are designed. exitHandler can handle the exits. what application is it that you require the callback externally? 3. will be fixed shortly. 4. should also be fixed shortly as I have not seen it with the patched version I'm working on. 5. no idea what you mean here. the IP/Default.map has a set of functions for Input.Text. what is the issue with them?
Created attachment 89 [details] so far. try this out and see what improves. rightarrow should be fixed, as well as the stray characters. this does not address design changes, as that is not my call.
The Live365 plugin has been updated since it was last posted, and I was doing some stupid things in 0.03; my examples apply to the as yet un-released 0.04 1. Specifically, the code snippet: 'right' => sub { my $client = shift; Slim::Buttons::Common::pushMode( $client, 'INPUT.Text', { 'callback' => \&doSearch, 'valueRef' => \$searchString{$client}, 'header' => string( 'PLUGIN_LIVE365_SEARCHPROMPT' ) } ); } ...does not update the display. Until a mode-appropriate button is pressed, the box appears to hang. 2. Live365 searching on entered text can sometimes take more than a second or two. The PLUGIN.Live365.* modes have a ability to set a status display like this, but there seems to be no such facility in INPUT::Text. As a workaround, I call $client->lines( \&searchModeLines ), which is my my parent mode line function, then reset it when the status message is gone. 5. You're absolutely correct, there is a mode mapping there... and I'm confused. Unless I call Slim::Hardware::IR::addModeDefaultMapping and set up some buttons on my own, the remote is "dead" when I enter Input::Text. I'll try your patch either tonight or tomorrow. Thanks much.
I've committed the patch so it should be in the Aug 6 build. You might want to also check out the SavePlaylist plugin that's included with the server. It uses INPUT.Text as well, and does show an initial value when the mode is entered. It also should work with button functions. At least it does for me. Hopefully you will see marked improvement in the latest version. Please continue to hammer away at it :)
I must have been confused when I was having trouble with the button mapping. I tried it again and the default mapping is clearly in effect. With Slimserver v2004-08-06, still suffering. From --d_plugins --d_files: 2004-08-06 12:50:51.0556 pushing button mode: PLUGIN.Live365 2004-08-06 12:50:54.8955 pushing button mode: searchMode 2004-08-06 12:50:57.0521 pushing button mode: INPUT.Text (at this point the display is still displaying lines from searchMode) 2004-08-06 12:51:26.2904 Live365.doSearch exit input mode: 'nextChar' 2004-08-06 12:51:26.2914 Live365.doSearch string: 'AEROSMITHrightarrow' (note the "rightarrow" suffix -- I'm content to strip it for now) 2004-08-06 12:56:37.4708 pushing button mode: Live365Channels 2004-08-06 12:58:45.0057 popped to button mode: INPUT.Text (see attached Corrupted.jpg) I've also attached 0.04 as of 08-06-2004 1:00pm mountain time.
Created attachment 92 [details] Softsqueeze screenshot of the corrupted display popping to INPUT.Text
Created attachment 93 [details] Live365 0.04 -- 08-06-2004 1:00pm mountain time
Input.Text is meant for input, and status messages as a result of that text should be part of the ExitHandler in the parent mode. You can make use of onChange and callback references if need be. rightarrow will have to be stripped from the string on exit (tho I suppose that would make sense to strip withing the Module. You might want to pose some of this as a development question to the Dev list, and hope that Moser pokes his head in to help. I suspect something isn't quite right in setting up the params hash for the Input.Mode, but I'm not an expert at how that works.
I've had a chance ot do a quick test. It look like the problem with the display characters on entering the mode is due to an undefined search string. The input mode needs to have a default starting point (for example 'A') or it does this. Perhaps the Input mode could detect this and supply 'A' by default.
that doesn't work either. darn. I can't see what makes it different from SavePlaylist.pm, but that modules doesn't seem to show the problem, but I can definately see them while using Live365. have to ponder that one.
The numbers refer to the original bug report. 1) No mode performs an update when you enter it. It is for the calling mode to do the client update. The reason for this is that most mode switches are performed with pushModeLeft and popModeRight, which involve an animation which would not look correct if the display were to be updated prior to the animation. 2) The reason for the callback function to be executed in the INPUT.Text mode is so that the param hash on the client stack still contains the all the data used by the INPUT.Text mode. When you pop out of the mode, you lose all that information. Not a problem if you still have the original scalar refered to by valueRef, but I did not want to assume that that was the case. 3) We should probably have a function in INPUT.Text to strip off the right arrow char, whatever it happens to be. The main reason I don't is that there may be times when you don't really want to exit the INPUT.Text mode, in which case that right arrow would need to stay.
1. pushModeLeft to INPUT.Text animates the prior menu item, then displays a blank display. It doesn't appear to be accurate that pushMode doesn't update the display, as it displays as expected when called in SavePlaylist.
SavePlaylist.pm does the pushMode call in its setMode function, so it is subject to the $client->pushLeft called in Slim::Buttons::Plugins -> right function. I installed Live365.pm and with the right function of the searchMode mode using pushMode I see the non-update until an up/down action. However, when I change that to use pushModeLeft instead, I see a normal update (it does crash the server when I attempt to perform a search, but that is a different issue).
so, which (if any) of these issues are currently remaining with INPUT.Text itself?
There is still a problem when entering INPUT.Text with pushModeLeft on a graphics Squeezebox, but not on a character-based one. This can be seen on a SoftSqueeze by switching back and forth between the Noritake display and the Graphics display. Error messages produces when entering the mode are: substr outside of string at H:/projects/slim/server/Slim/Player/SqueezeboxG.pm line 504. Use of uninitialized value in concatenation (.) or string at H:/projects/slim/server/Slim/Player/SqueezeboxG.pm line 417. And when leaving the mode: Use of uninitialized value in repeat (x) at H:/projects/slim/server/Slim/Display/Graphics.pm line 56. The odd bit is that the SavePlaylist plugin, which also uses INPUT.Text does not experience the problem when entering the mode, but does produce that same error when exiting.
I think the problem with the repeat error has to do with an empty string. This one is reported as bug 475, which I'll reopen.
I've attached a patch to bug475 that should fix that. The substr issue, I believe, is a bug in the scroll routine that happens when the frambuf length is somehow less than the screensize. the offset will continue to 560, but will cause that warning in the case of pushign right in Live365 for Search Artist (length of 520).
and it looks like Dean just fixed it with SqueezeboxG.pm v1.6. its a case of not having an overlay. as a note, for the search menu it would fit consistency to add the right arrow overlay to indicate that pushing right is an option from that menuitem. if there are other issues with INPUT.Text, please reopen.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.