Closed Luthaf closed 8 years ago
Another Python interpreter to be embeded in Qt applications : http://pythonqt.sourceforge.net/
I would personally go for option 1 or 2 (3 is out of my league with my knowledge of python), however, option 1 needs more work, so it has to be worth it!
Hence the question: What is the interest of using patacrep as an embedded library and not just a songbook generator? If it is just to start the generator and retrieve the results, option 2 is the way to go. If there is any added value in using option 2 (song validation, clean insertion of songs, anything?), I am perfectly ok with this.
The main reason why I would embed the python library in C++ is if it can be used to deal with some song library level work (like storing properly a song in the right folder or validating syntax). I suppose that this is useful on patanet as well, but if we can make sure this is ok before starting working actively on this that would be great!
What is the interest of using patacrep as an embedded library and not just a songbook generator ?
You can use it to :
So it may be good enough to embedded Python inside.
like storing properly a song in the right folder or validating syntax
This function does not exist yet, but may be added after.
Salut,
Je suis toujours en train d'essayer de faire marcher patagui avec patacrep 4. Pour l'instant, pythonqt fonctionne très bien, j'arrive à importer le module, mais là ça bloque, en particulier à cause de la différence de typage entre Python et C++ (j'ai un peu de mal à lire le code Python...)
Quand on initialise l'objet SongbookBuilder (https://github.com/patacrep/patacrep/blob/master/patacrep/build.py), on doit lui donner un raw_songbook et un basename. De quel type d'objets parle-t-on alors ? Je dois juste lui donner le chemin vers le fichier .sb et le nom de sortie ou est-ce plus sophistiqué ?
Merci!
songbook_builder
est un dictionaire python, et basename et le chemin vers le ficher de sortie voulu, sans extension.
Des exemples d'utilisation sont dans le script principal : https://github.com/patacrep/patacrep/blob/b35da1325fae01d0c352d7eb65baaef6ab0ae9e4/patacrep/songbook.py#L136, et dans patanet : https://github.com/patacrep/patanet/blob/170a7e99c69521773d39f9b83428584f8a057284/generator/build.py#L66
Ça progresse lentement mais surement... J'arrive à lire et écrire des fichiers valides, par contre la structure de données ayant un peu changé, j'ai une question sur les datadirs:
patacrep cherche les chants répertoriés de manière automatique et récursive dans un datadir donné, ou il faut un chemin complet (relatif par rapport au datadir) ?
Je n'ai pas tout à fait compris la question. Si on prend la chanson /home/foo/bar/songs/my_song.sg
, et que /home/foo/bar
est un datadir, alors il suffit de passer à patacrep le chemin my_song.sg
. Les chansons sont cherchées dans le dossier songs
de tous les datadirs connus.
Les carnets de patadata sont en général de bon points de départ. https://github.com/patacrep/patadata/tree/master/books
Je pense que ça répond plus ou moins. Un détail seulement: si on prend la chanson /home/foo/bar/songs/author/my_song.sg
, il faut mettre dans le songbook le datadir /home/foo/bar
et la chanson author/my_song.sg
. Est-ce que mettre uniquement my_song.sg
fonctionnera ? (i.e. Sans spécifier le chemin complet)
Non, je pense qu'il faudra en effet mettre author/my_song.sg
. @paternal, tu confirme ?
Après test, effectivement, c'est nécessaire. Après, c'est discutable…
Je préfère ce comportement, ça limite les collisions de noms.
Oui je suis d'accord. Je voulais juste vérifier comme je suis en train de réimplémenter pas mal de fonctions dans patagui.
Et du coup une autre question, patacrep tolère-t-il un datadir qui n'est pas organisé en datadir/songs
? En gros, le répertoire songs
est obligatoire ou juste optionnel ?
Et d'ailleurs, dans l'organisation des datadirs, (ref ici) tous les dossiers sont nécessaires, ou certains sont optionnels? Je suppose que songs
et templates
sont nécessaires, mais pour les autres ?
chanson.sg
placé à la racine du datadir ne sera pas considéré (seulement songs/chanson.sg
).
How should the client interact with the new core (4.0) ? The client is a C++ application, and the core is a Python application
I see two main possibilities:
And another possibility (3) would be to rewrite the app in Python, with PySide or PyQt. This would be lot of works, but give the better flexibility.
Choose two options in the three: