Note that adding more categories wouldn't be a problem with the current database code. Just add them to the dbitem.song class, and register a new index. What does not work this easily, though, is to construct the intersection of different categories, so for instance: get me all slow waltzs.
Right and thats just a simple search. More complex ones are possbile.
from a touchscreen. I've only just started so its very incomplete. But it does load and display some items queried from the database. No player functions yet.
I looked at it, and it looks like being designed for your specific needs, which of course is not bad but somehow limits it's general usefulness. But maybe there will be more functionality in the future?
Yes exactly to my specific needs. More functionaity in the future as I work on it.. However, I don't think I will ever target it as a general useage interface. The general case adds complexity that I don't want. By nature its specific to my goal which is the quick and simple selection of particular dance songs.
Your curses interface already provides a good general interface. So I don't see where its needed.
every time. So to support that I had to create a new song_lite class that did not go read all the meta-info of a song when instantiated.
Actually, this is not a big problem. One could actually make the pure container class the superclass.
Works for me. I'm good with any suggestions like that you have.
pyTone wants to parse a collection of files and display all the ID3 info in an organized manner. DanceBox doesn't care about the id3 info.
Yes, I've seen that. But again this makes your SQLite code not very usefull for PyTone...
I think you misunderstand. The design of DanceBox can use any id3 info that currently exists. In fact my latest build now makes the 'Import' button run the autoregistersongs. Which will populate the tables with info from the mp3s. I just didn't go all the way (yet). Eventually I'm planning on using all the ID3 info of a song if its present. its just not necesary right now in my developement stage. The user will have to input all the dance info anyway.
implemented with the database I setup. So if someone wanted to re-tool pyTone into using SQLite this should be a great start. I saw in the archives that moving to SQLite was suggested but met some resistance due to the additional dependencies that would add.
Yes, but I still have moving to the SQLite db in mind. But IMHO this requires a bit of thinking about the database scheme before.
I'm all ears. I tried to build something that would encapsulate all of PyTones functionality but if you think I missed something let me know. My design is by no means static. Nor do I think its perfect.
That's ok, although syncing things is probably not so easy. Looking at your code, there are already various differences here and there, which you have to keep track off.
Right it will never be 100% automatic. But lets say you switch to SQLite then its certainly in my best interest to try to use as much of your code as possible given the amount of work you've already put into the project. The converse may also be true. Hopefully you can take what I've done and leverage it for your use.
probably continue to do that. Since I don't really care as long as its readable and to me longfuncitonnames are not readable.
Coding conventions are always a matter of taste. Although I think it's good style to use the style already used in a project.
I agree. And with the Qt code you can see that I did exactly that.
I tried working without breaks in my function names but my english trained brain just rejected it. I eventually decided that if I were to have to continue this myself I was going to have to have entity names I could easily read.
I'm somewhat flexable here. If you did want to move pyTone to SQLite then it really dosen't make much sense to have 2 different versions of the same thing. So I might be convinced to grin and bear it until I get used to looking at it.
But thats _only_ if we can achieve a code base with a high amount of code useable by both projects.
This seems very reasonable to me. Anyway, there should only be one thread which accesses the database.
Apsw complained about that early on. So right now I workaound by grabbing an new cursor every time a query is made and releasing it when I'm done.
Why?
I'm not really sure. I thought was that all the database operations ran in a single thread. My debugging prints indicate that all the requests come from the same thread 'Main' But apsw dosen't seem to agree. I haven't put a large amount of time in figuring out the cause. Perhaps you can shed some light on the issue.
If you look in _initdb you will see a self.cursor that holds a dbcursor. If you try to use this cursor in something run via a request then apsw will whine.