Re: [Musicpd-dev-team] couple client-related questions
On Tue, Mar 24, 2009 at 4:45 PM, Max Kellermann m...@duempel.org wrote: On 2009/03/24 16:26, Jeffrey Middleton jefr...@gmail.com wrote: Anyway, I figure a moverange command is a reasonable thing to have within mpd. I've written and tested the queue_move_range function which will be behind it, but haven't dealt with the command parsing side yet. I figure it should (like shuffle_range) use the same command, e.g. move start:end to. Perfect! While testing moving ranges, I ran into the move relative to current song feature. The comments in the source say, for a command move from to: /* * (to 0) = move to offset from current song * (-playlist.length == to) = move to position BEFORE current song */ However, these conditions seem to move to one past where they should. That is, (to == -1) moves to two after the current song, and (-playlist.length == to) moves to one after the current song. From what I can tell, the behavior for (to0) hasn't changed since originally added, so I was wondering if anyone's actually used this feature. I don't want to break clients by fixing it, but I'm pretty sure it doesn't work as documented. Jeffrey -- ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] couple client-related questions
On Tue, Mar 24, 2009 at 4:45 PM, Max Kellermann m...@duempel.org wrote: In this case, is there any point in using getopt? Yes, maybe to get the binary size down on systems which support it. Might be interesting for tiny embedded systems. For now, I'd say just extend the current integrated option parser. We might later add a compile-time option for using getopt_long() instead if available, for those users who think saving a few bytes is useful. Ok, I'll throw the getopt_long code on a branch on my public repository and work on builtin for now. From ncmpc's recent visual selection addition, I noticed that moving a large block of songs is quite slow because it has to send a command for every song in the block. Romain's implementation wasn't well optimized. To move a whole block one up or down, it's enough to move just one single song: e.g. to move 4:8 to 3, simply send move 3 7. This is what I was initially going to do, but the command actually sends swapid instead of move. I meant to ask about this, but got distracted as I started working on the mpd side. So is it reasonable to just have ncmpc use moveid, or should it still use swapid if not moving a range? I'll get the move range command properly implemented eventually too - not totally trivial because of error checking (it'd be the first command which has an argument which could either be a range or an integer, I think). Busy week, though, then going out of town (camping, no computers!) for a week so don't get your hopes up too much! Jeffrey -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] couple client-related questions
On 2009/03/24 22:55, Jeffrey Middleton jefr...@gmail.com wrote: This is what I was initially going to do, but the command actually sends swapid instead of move. I meant to ask about this, but got distracted as I started working on the mpd side. So is it reasonable to just have ncmpc use moveid, or should it still use swapid if not moving a range? Both commands do the job, so I don't care much. It's just obvious to make single move just a special case of range move, i.e. use the same comand for both (and share the same code). I'll get the move range command properly implemented eventually too - not totally trivial because of error checking (it'd be the first command which has an argument which could either be a range or an integer, I think). Busy week, though, then going out of town (camping, no computers!) for a week so don't get your hopes up too much! There's already playlistinfo. I think that range feature isn't documented yet. Documentation patch welcome. Max -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
