[pyddr-devel] Level an Difficulty sorting in songselect

[Frank Foeth]

Hi Pavel,

Finally, the structural comments. First some general remarks, followed
by a suggestion for a change in the ...ItemDisplay-s.

> > > Wow, I'm impressed.
> > 
> > Was that sarcasm? I wasn't too proud of that code myself...
> 
> It wasn't, as I wrote earlier I had specific bits of code all over the
> place to deal with the dance-sort ideosyncracies. And suddenly these
> were gone. Great. I do understand that a lot can be improved upon, which
> can be approved upon, etc., but it's a promissing start.

Sorry, I'm still enthousiastic. In addition to the above, it's great
that the complexity sort works without folders. But at least you made me
look extra careful at things before responding. I have to fly blind a
bit, as you never told me what it is you don't like.

As far as I can see SongSelect is ok. Having to consciously switch lists
may not feel pretty, but it's unavoidable, song level and dance level
information are a bit too different. Deferring the switch to a higher
level (plug the switch in an ItemDisplay object) isn't a real option, as
you need to feed the ListBox. You could debate endlessly about how to
construct the code to make it more readable, but if your problems centre
on SongSelect, adding a well crafted comment will probably be the best
thing to do. Again: as far as I can see.

The idea of using a family of display items is fine. The only question
is what should be in them. The best way to play with them seems to
centre on how to do "versus" mode complexity sorting, it is the only
part of the interface that I really don't like; furthermore, it is
technically the most difficult part; lastly, future changes will hit
hardest here (e.g. adding the option of different games for different
players.) 

I would feel ok with allowing the users to mess up our carefully crafted
and neatly sorted complexity folders. They'll find out soon enough that
it won't do them much good. I have been juggling with numerous options
of how to track/grant/... a player the right to choose freely and fix
the other, but all of them have flaws; either the interface becomes
obscured and slightly unpredictable (folder changing), or it's not
always possible to figure out which player benefits from being fixed in
place (technically: owning the folder) and which should have the right
to choose. ... Basically, unless you have a great idea, i'd mimic the
other left/right effects.

A second (and partially overlapping) angle is how to best divide the
functionalities in between both SongSelect and the item displays.
Currently songselect is responsible for just about anything. To not make
songselect any heavier, I'd like to see the responsibility for handling
"ui.RIGHT and LEFT" deferred to the display items. (Yes, it does limit
possibilities a lot, e.g. your suggestion of linking dance items and
tracking accross folders the would not be possible.) A consequence would
be that especially dance display items become containers with
preferences, more than individual adapted songselect items. On the
upside: this makes future development easier. On the downside: building
the items may become tricky, especially in versus mode if both players
are allowed their own queries.

Lastly, I would like to limit the access to the display items. By
properly encapsulating them, we get a neater situation where we can
leave songselect alone in during most future developments. A further
advantage of encapsulation is we can hide ideosyncracies in the methods,
e.g. .info("rank") could hide the generation from the records. Even if
for future development the argument lists of the methods need changing,
it will only have superficial effects on SongSelect.

Maybe I'm going too far, I'd like your ideas before adapting anything.

Anyway, have a nice time,

Yours,

Frank