PDA

View Full Version : Re: Possible button "shift" implementation



fcm4711
2003-11-27, 10:07
Hi there

I'd love to have the possibility to expand
the remote with different map files, since I'm
always short of buttons on the remote.

BTW: I have a solution for the example of
loading and playing a particular playlist
with one button push.

Have a look at my QuickAccess plugin here:

http://www.gwendesign.com/slimserver/development.htm

Enjoy
Felix

--- Robert Moser II <rlmoser (AT) earthlink (DOT) net> wrote:
> dean blackketter wrote:
> > So, I'm not sure why this is a button map issue.
> Why not create a new
> > mode for playlists that is triggered by the
> SEARCH button.
>
> Doing it with a couple of maps and two simple
> functions: about 16 lines
> of code, plus 2 files: one 2 lines, one 12. Writing
> a whole new mode
> for the same thing: lots more code.
>
> Keep in mind that the scenario I gave was just one
> example of one use
> for rapid map switching. Another scenario would be
> a husband and wife
> who can't agree on how best to map the buttons on
> the remote. Create a
> husband.map and a wife.map, and reserve one button
> to flip back and forth.
>
> Another scenario: add a saveToPlaylist function,
> takes the currently
> playing song and adds it to a specified playlist:
> have a FixTags
> playlist for songs that need to have their tags
> adjusted, a PartyMix
> playlist to add to while you are going through your
> whole collection, a
> NeedToReRip playlist for tracks that don't sound
> right.
>
> The main point to being able to switch maps quickly
> is to expand the
> options available from the remote. Not everyone
> needs or wants to use
> every function, rapid map switching included. It
> has no impact on
> people who like the default configuration, but it
> allows others to do a
> lot more with their remote.
>
> What I see as being great about the Slim system is
> the wide range of
> things possible with it. In any given mode there
> are tons of different
> functions which could be implemented. If people
> like the functions they
> can map a button to use them, if they don't, well,
> the function isn't
> doing them any harm by being there. Notice when I
> wrote the INPUT.Text
> mode how many functions I included, now look at how
> many are mapped.
> Taking advantage of all the functionality of just
> that one module would
> require a remote with as many keys as a keyboard.
>
> I'm sure that the users out there will be able to
> come up with all kinds
> of scenarios where it will come in handy.
>
> By the way, heres the untested code for the
> loadPlaylist function:
>
> ,'loadPlaylist' => sub {
> my ($client,$funct,$functarg) = @_;
> return if !$functarg;
> Slim::Buttons::Block::block($client
> ,Slim::Player::Playlist::shuffle($client)
> ? string('PLAYING_RANDOMLY_FROM')
> : string('NOW_PLAYING_FROM')
> ,$functarg);
> Slim::Control::Command::execute($client
> ,['playlist','load',$functarg]
> ,\&Slim::Buttons::Block::unblock
> ,[$client]);
> }
>
>
> >
>
>

Robert Moser II
2003-11-27, 12:00
Felix Mueller wrote:

> Hi there
>
> I'd love to have the possibility to expand
> the remote with different map files, since I'm
> always short of buttons on the remote.
>
> BTW: I have a solution for the example of
> loading and playing a particular playlist
> with one button push.
>
> Have a look at my QuickAccess plugin here:
>
> http://www.gwendesign.com/slimserver/development.htm
>
> Enjoy
> Felix

I have a philosophical problem with your plugin. Your numberScroll
function isn't actually scrolling, it is loading the requested playlist.

Other than that small gripe, it looks good. If you have the time, I'd
be interested in having you convert it to use the INPUT.List mode so
that I could get feedback on that. You can look at Information.pm and
Settings.pm for examples. I'm going to be updating the documentation today.

Kevin Deane-Freeman
2003-11-27, 15:23
Quoting Robert Moser II <rlmoser (AT) earthlink (DOT) net>:


> I have a philosophical problem with your plugin. Your numberScroll
> function isn't actually scrolling, it is loading the requested playlist.
>
> Other than that small gripe, it looks good. If you have the time, I'd
> be interested in having you convert it to use the INPUT.List mode so
> that I could get feedback on that. You can look at Information.pm and
> Settings.pm for examples. I'm going to be updating the documentation today.

I haven't had enough time to really look over it, so I figured I'd just ask
anyway :) Does the INPUT.List mode handle directory browsing? When you first
started bringing it in, that application immediately jumped to mind. A couple
of plugins could make use of that for sure. If its simple, then even the server
could use ir for navigating music folder and for saved playists sub-folders.

-kdf

Robert Moser II
2003-11-27, 15:57
> I haven't had enough time to really look over it, so I figured I'd just ask
> anyway :) Does the INPUT.List mode handle directory browsing? When you first
> started bringing it in, that application immediately jumped to mind. A couple
> of plugins could make use of that for sure. If its simple, then even the server
> could use ir for navigating music folder and for saved playists sub-folders.
>
> -kdf

It doesn't handle it all by itself, it would need some support from the
calling mode. However, once I get around to writing it, directory
browsing will be completely handled by INPUT.Tree, which will most
likely just wrap around INPUT.List. I haven't even gotten around to
spec'ing out INPUT.Tree yet.

I'm in the middle of updating input.html (the doc for INPUT.*) right
now, so you'll have to rely on the source to get an idea of how
everything works. I'll most likely be checking in the updated doc
sometime today.

-Robert

Kevin Deane-Freeman
2003-11-27, 16:34
Quoting Robert Moser II <rlmoser (AT) earthlink (DOT) net>:

> > I haven't had enough time to really look over it, so I figured I'd just
> ask
> > anyway :) Does the INPUT.List mode handle directory browsing? When you
> first
> > started bringing it in, that application immediately jumped to mind. A
> couple
> > of plugins could make use of that for sure. If its simple, then even the
> server
> > could use ir for navigating music folder and for saved playists
> sub-folders.
> >
> > -kdf
>
> It doesn't handle it all by itself, it would need some support from the
> calling mode. However, once I get around to writing it, directory
> browsing will be completely handled by INPUT.Tree, which will most
> likely just wrap around INPUT.List. I haven't even gotten around to
> spec'ing out INPUT.Tree yet.

Sounds right in line with what I expected. Read the dir, send the list to
INPUT.List, callback reads the sub-dir, etc.

cheers,
kdf