[pyddr-discuss] Query setup
Pavel N. Krivitsky
pavel at krivitsky.name
Sun Feb 18 17:51:06 EST 2007
Hi, Frank,
Why are we on PyDDR-discuss now?
> I quickly leafed through endless, it seems a bit sparce, and not
> particularly generalised. I tried to use it at some point, even hacked
> the lists of choices (you didn't receive the hack), but after adding the
> level sort I never touched it again, For a beginner it's useless as is.
OK. I guess we'll have to start over WRT filtering.
> To abreviate your menu idea's:
> First menu: Show + song parameters,
> 2nd: math functions for chosen song parameter
> 3rd: function parameters to go with 2nd
> 4th: loop to 1, but delete configured song parameter.
> Show starts the current song select screen.
> There should also be some way to save a query.
Yeah, that's a lot more concise. ;) Saving a query should probably be
done through a menu.
> Apart from deleting the configured parameters (people make mistakes and
> there is no way to undo them) I understand.
Just as you hit CANCEL to back out of a folder, you hit CANCEL to undo a
choice.
> I do have slight problems with it. If songselect were the only
> interface, it could be ok, but it isn't: Endless' interface could be
> replaced with the same new query interface. I wouldn't like to build
> separate query interfaces for both to do the exactly the same thing.
Good idea. We can make a query and then play the results in Endless
mode.
> Placing it in songselect will also delete the "giving both players their
> separate requests" option, which I would like to retain. There simply
> isn't enough space in song selects window to let them both make their
> choises simultaneously.
I am not sure how to handle this. We could allow the players to have
different difficulties unless they choose to filter by LEVEL or
DIFFICULTY.
> Also it will further complicate songselects already involved encoding.
OK... Now we are getting into implementation details. You are right, the
query mechanism needs to be abstracted. Songselect should focus on
displaying lists of songs/choices given to it by the query mechanism and
handling input from the user to pass to the query mechanism.
> Putting the players through to the dance selection parts of the program
> is a good idea. This would be troublesome to accomplish in the "like the
> configuration option screen" idea.
I am not sure I understand this...
> Apart from where to place it, following your idea I think the user has
> more freedom than I had in mind. But it won't look as dawnting to a
> user, my interface would look complicated. I distrust the mathematical
> capabilities of people a lot, so also in your idea there should be
> examples in 5) and perhaps all over the place. And personally I would
> like a range type statement added to the math list (especially for
> deleting things that are too difficult or too easy in endless.)
Good points. First of all, let's replace "GREATER THAN" with "AT LEAST"
and "LESS THAN" with "AT MOST". Second of all, allow the user to filter
on the same criterion on several levels. That is, instead of entering
"LEVEL -> WITHIN 1 OF -> 5", the user could enter "LEVEL -> AT LEAST ->
4 -> LEVEL -> AT MOST -> 6".
> To allow interfacing to say endless, I still propose to keep the
> entrance to the queries in gameselect, furthermore I would like to see a
> few standard queries to choose from within gameselect. In this same list
> we could place 'go!' (or 'all') to bypass the queries and 'select' to
> enter something along the lines you sketched.
I think we should leave gameselect alone, and just abstract the query
mechanism and have SongSelect and Endless invoke it. We could probably
rewrite the current folders backend in terms of queries as well. E.g.
class SongFilter:
def get_option_list(self):
...
return abstractitemdisplay_list
def choose_option(self,ind):
...
def unchoose_option(self):
...
def load(self):
...
def save(self,fn):
...
def copy(self):
...
return songfilter
def get_matching_songs(self):
...
return songitemdisplay_list
def get_matching_dances(self):
...
return DanceItemDisplay_list
And so on. Then, SongSelect and Endless could each have their own
interface.
> Your ideas don't clash with what I wrote about the query set-up. What I
> can do is build a basic query.py keeping in mind the interface, I need
> it anyway, so I have to keep more things in mind with it. Building it
> should not interfere with discussing the interface.
Agreed.
Regards,
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-discuss/attachments/20070218/452f13cc/attachment.pgp>
More information about the pyddr-discuss
mailing list