[pyddr-devel] Level an Difficulty sorting in songselect

[Pavel N. Krivitsky]

Hi, Frank,

> Wow, I'm impressed.

Was that sarcasm? I wasn't too proud of that code myself...

> You usually don't have time so I append my notes. The patch you send me
> crashes if used for dancing, but I did get to see how you think about
> the interface. See the notes for comments, I repeat my scedual below.

Sorry about lack of reply to your messages. You wrote a lot, and it's
really interesting, but I haven't had a chance to think about it enough
to write a cogent reply. I'll reply tomorrow night (I don't have much
time tonight).

> The crash was caused in line 190 of dance.py, it should read:
>     self._banner.set_song(SongItemDisplay(self.song, playmode))

Ah... I forgot about song info screen.

> > object). This is necessary, because we want to stay on the same
> > song-difficulty combination when cycling through sorting modes.
> 
> I don't like the last sentence, but I don't understand the code well
> enough yet. My main problem is that in an object oriented environment
> coupled object should be objects, usually this means trouble at some
> level. Hopefully I'll clear it up for myself this week, otherwise I'll
> come back on this.

The way I've implemented it, there are modes that collapse multiple
difficulties into one entry (title, mix, bpm, etc.) and modes that list
them as separate entries (difficulty, level). When switching between
these modes, the dance (set of steps) currently selected should be
preserved. SongSelect._find_resorted finds the *ItemDisplay that
corresponds, by looking up in the *ItemDisplay's list of "neighbors".

The only other way I could think of doing this is by having some "key"
associated with each SongItemDisplay and DanceItemDisplay (possibly like
the one used in "records"), that is the same for all SongItemDisplay and
DanceItemDisplay objects associated with a particular song. I ended up
implementing the first solution, but I am pretty impartial.

All that said, I am not very proud of this implementation, so I'd love
to hear other ideas.

> > Also, sorting uses keys rather than custom comparison functions now.
> > That means that the next release requires 2.4, but I think everybody has
> > it by now. The code could probably use some cleanup, but I'd be curious
> > to see if it works for everyone else first.
> 
> Hmmm, trusting people to keep up with new versions... ;)

Well, my reasoning is that if it's in Debian Stable (it is), everyone
has it. ;)

> Remarks patch feb 12:
> 1. It crashes when selecting CONFIRM to perform a dance in songselect.
> 2. Limited choices in the level and difficulty sorting modes (i.e. RIGHT
> and LEFT have no effect.)

True. What if we make it so that hitting RIGHT and LEFT would move the
selection to where that DanceItemDisplay is?

> 3. Multiple use of _song... where _song... contains either song or dance
> data which makes the code ambiguous, maybe replace with _item... 

I meant to do that, but I forgot. Mea culpa. Do you want to fix it, or
should I?

> 4. SongItemDisplay and DanceItemDisplay both share almost all
> parameters, but this is not enforced by AbstractItemDisplay.

I am not sure I understand. How should this be enforced?

                                   Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/pyddr-devel/attachments/20070212/fb8c5642/attachment.pgp>