This is the final episode of this series since we don’t need to browse the full code of the application, but I will stop only where there is something noteworthy. Last time, the main window was up and running – ready to accept user events. The code that handles them starts from line 157, and at line 189 we see another use of threading, in this case to load the DB. I didn’t do it in the non-GUI app, the reason here is that if it is a big file, we still want the UI to be responsive (i.e. updating a progress bar). Same usage of threading goes at line 218 when we update the view of data. Here, note that the toggle is to display only tracks that are missing sort information. This way, the user can choose between seeing the whole DB, or just the songs that need sort information. I used only the latter option but I thought the former can be useful to others. When the user right-clicks a track, we want to provide a quick way of entering sort information; this is accomplished through the function at line 270. At 295 there is code to automatically handle “The” in front of a band name. Here, there could be more ideas in place. The other automatic option is looking for the first space to try offer: “Bruce Springsteen” or “Springsteen, Bruce”. This may work well if you have a single track, but it’s not handy with many of them. Also because I wasn’t able to correctly handle the right-click on a multiple selection to update a group of tracks. To solve this issue, I came up with the “filling” icons on the toolbar. There’s three of them: automatically, asking and manual. The automatic one is implemented from line 536 and this is similar to the right-click on the track, but with no user input. Since this was written originally for me, I want “Houston, Whitney” and “Smiths, The”, with the year, as album sort information. If you want something different you can use the other ones or change the code. Note also that here “Green Day” will become “Day, Green” which of course is unwanted. Automatic, but not very clever.
Voici le dernier épisode de cette série, puisque nous n'avons pas besoin d'examiner le code complet de l'application ; je m'arrêterai uniquement quand il y a quelque chose à remarquer. La dernière fois, la fenêtre principale était en état de marche et prête à accepter les événements de l'utilisateur. Le code qui les traite démarre à partir de la ligne 157 et, à la ligne 189, on voit une autre utilisation du parallélisme : dans ce cas, pour charger la base de données. Je ne l'ai pas fait dans l'appli sans interface graphique, car, même si le fichier est gros, nous voulons que l'interface soit réactive (c'est-à-dire avec une barre de progression qui se met à jour). Le même usage du parallélisme se trouve à la ligne 218 quand nous mettons à jour l'affichage des données. Ici, remarquez que le commutateur sert à n'afficher que les pistes où il n'y a pas d'informations de tri, de cette façon, l'utilisateur peut choisir de voir toute la base de données ou seulement les chansons qui ont besoin d'informations de tri. Je n'ai utilisé que la dernière option, tout en pensant que la première peut être utile aux autres.
Quand l'utilisateur fait un clic droit sur une piste, nous voulons lui fournir la possibilité d'entrer des informations de tri rapidement ; cela se fait avec la fonction à la ligne 270. À la ligne 295, il y a le code pour le traitement automatique de l'article « The » au début du nom d'un groupe. Ici, on pourrait insérer plus d'idées. L'autre option automatique est la recherche du premier espace pour essayer l'ordre : « Bruce Springsteen » ou « Springsteen, Bruce ». Ceci peut bien fonctionner si vous n'avez qu'une seule piste, mais ce n'est pas utile quand il y en a beaucoup. En fait, je n'arrivais pas à gérer correctement le clic droit sur une sélection multiple pour mettre à jour un ensemble de pistes. Pour résoudre ce problème, j'ai eu l'idée de mettre des icônes de remplissage sur la barre d'outils. Il y en a trois : automatiquement, en demandant et manuel. Celle qui est automatique est implémentée à partir de la ligne 536 et est similaire au clic droit sur la piste, mais sans instructions de l'utilisateur. Étant donné que je l'avais écrit au départ pour mon usage, je veux « Houston, Whitney » et « Smiths, The », accompagnés de l'année comme informations de tri des albums. Si vous voulez quelque chose de différent, vous pouvez vous servir des autres ou modifier le code. Remarquez aussi que « Green Day » deviendra « Day, Green » ici, ce qui, bien entendu, n'est pas ce que l'on veut. Automatique, mais pas très futé.
The second mode (line 569 and on) asks for user input, so you can avoid the Green Day issue amongst other things. Still the year is hard-coded. When the user is asked to choose, we don’t want him to play around with the other windows of the application, it doesn’t add any value to the user and it could cause issues (closing the DB in the middle of this function, or reloading an older version….). Hence at line 596: selection_dialog.set_modal(True) This locks the user on the dialog window until a choice is made. Since this process can take some time, and stops when the user has to make a choice, we have the following lines of code: while Gtk.events_pending(): Gtk.main_iteration() This allows the UI to react in between user inputs (and while cycling through tracks). One reason is to update the treeview on the go.
Le deuxième mode (à partir de la ligne 569) demande une contribution de l'utilisateur ; ainsi, vous pourrez éviter le problème de Green Day, parmi d'autres. Mais, l'année reste codée en dur. Quand l'utilisateur doit faire un choix, nous ne voulons pas qu'il s'amuse avec les autres fenêtres de l'application, car cela n'ajoute rien qui l'intéresserait et pourrait créer des problèmes (la fermeture de la base de données au milieu de cette fonction ou le chargement d'une ancienne version…). Ainsi, à la ligne 596 :
selection_dialog.set_modal(True)
Ce qui verrouille l'utilisateur au niveau de la fenêtre de dialogue jusqu'à ce qu'il fasse son choix.
Puisque ce processus peut prendre du temps et s'arrête quand l'utilisateur doit faire un choix, nous avons les lignes de code suivantes :
while Gtk.events_pending():
Gtk.main_iteration()
Celles-ci permettent à l'interface de réagir entre les entrées de l'utilisateur (pendant qu'il parcourt les pistes), pour, notamment, mettre à jour l'affichage de l'arborescence à la volée.
The subsequent lines try to add a bit of cleverness to the program. If the user has already said that “Scouting for Girls” should stay as it is, there’s no point in asking it for every track. So every time we have some user input, this is saved in a temporary array: already_found.append(selected_artist) already_chosen.append(proposed_sort_artist) This is checked at the beginning of the loop where user action is required, only if it is a “new” artist encountered: if selected_artist not in already_found: This information is lost at the end of the function, I’ll come back to this. The third option allows the user to enter any sort information including the album sort field. The code begins at line 637. All of these functions use the update_record to change the DB (in memory, not on the file yet!). This function (line 702) is very similar to the code of the non-GUI application we saw months ago, so you should be already familiar with it.
Avec les lignes suivantes, j'essayais d'ajouter une peu d'ingéniosité au programme. Si l'utilisateur a déjà indiqué que « Scouting for Girls » doit rester tel quel, il est inutile de poser la question pour chaque piste. Aussi, chaque fois qu'il y a une entrée faite par l'utilisateur, celle-ci est sauvegardée dans une table temporaire :
already_found.append(selected_artist)
already_chosen.append(proposed_sort_artist)
Ceci est vérifié au début de la boucle où une action de l'utilisateur est demandée, mais seulement s'il s'agit d'un « nouvel » artiste :
if selected_artist not in already_found:
Cette information est perdue à la fin de la fonction et j'y reviendrai.
La troisième option permet à l'utilisateur d'entrer des informations de tri, y compris dans le champ de tri de l'album. Le code commence à la ligne 637. Toutes ces fonctions utilisent l'update-record pour changer la base de données (dans la mémoire, pas encore dans le fichier !). Cette fonction (ligne 702) est très similaire au code de l'application sans interface graphique que nous avons vu il y a des mois ; ainsi, vous devriez le connaître déjà.
Finally, I had to convert posix date to year - at line 760… this function comes from googling how to do it, and merely copies someone else’s idea. The beauty of the modern world where information is few clicks away! This is the end of my brief overview of fixrhygtk. which has a huge space for improvement and to correct any bugs. For example, when it fills sort information by asking the user about the artist names, these choices could be permanently saved, so that if, at another time, the same artist is encountered, you don’t need to ask the user again. Another major point is localisation. The current code is not written for easy changing of language. Lines like: confirm_text = “Rhythmbos is currently running.” requires changes to the source code – which is not the way it should be.
Enfin, j'ai dû convertir la date posix à l'année, à la ligne 760. Cette fonction est le résultat de mes recherches sur Google et ne fait que copier l'idée de quelqu'un d'autre. La beauté du monde moderne où l'information n'est qu'à quelques clics de la souris !
Ici se termine mon bref aperçu de fixrhygtk, qui laisse beaucoup de place aux améliorations et, éventuellement, à la correction de bogues. Par exemple, quand il remplit des informations de tri en questionnant l'utilisateur au sujet des noms d'artistes, ces choix pourraient être enregistrés de façon permanente, pour que, si à un autre moment, le même artiste se présente, vous n'ayez pas besoin de questionner l'utilisateur à nouveau. Un autre point majeur est la localisation. Le code actuel n'est pas écrit pour faciliter les changements de langues. Des lignes comme :
confirm_text = “Rhythmbos is currently running.”
nécessitent la modification du code source, ce qui est contre-productif.
There’s also no proper installation procedure: it will run from its folder, but if you want to install it system-wide, there are a few commands you have to enter at the CLI (including the schema for the settings – see https://askubuntu.com/questions/251712/how-can-i-install-a-gsettings-schema-without-root-privileges). Even better, a package for a PPA could be created. I tried this last bit, with no luck. I read many web pages and tutorials on this, but I couldn’t figure out the proper way of doing it for a Python application. Which brings me to the concluding thought – which was also the one at the beginning of this project: the open source community. I don’t have the time, the skills and the patience to move forward from here, but I am happy if anyone else will do it. The whole project is available for download at: http://www.paolopelloni.com/download/fixrhygtk.tar.xz feel free to use it, improve it and share it. I hope others will benefit from it as I am benefiting from the whole OSS world! This is the end of my little story and again I want to thank Ronnie and Full Circle Magazine for the precious information, Greg D. Walters for teaching me Python and motivating me to use it and of course the whole open source world starting from the rhythmbox team!
Il n'y a également pas de bonne procédure d'installation : il s'exécutera à partir de son dossier, mais si vous voulez l'installer sur le système en général, il y a quelques commandes qu'il faut saisir sur l'interface de commandes en ligne (y compris le schéma des paramètres (Cf. https://askubuntu.com/questions/251712/how-can-i-install-a-gsettings-schema-without-root-privileges). Mieux encore, un paquet pour un PPA pourrait être créé. J'ai essayé de le faire, mais sans succès. J'ai consulté beaucoup de pages Web et de tutoriels à ce sujet, mais je n'arrivais pas à saisir la bonne façon de faire pour une application Python. Ce qui m'amène à ma réflexion finale, qui était aussi celle du début de ce projet : la communauté de l'Open Source. Je n'ai ni le temps, ni les compétences, ni la patience pour continuer à partir d'ici, mais je serais ravi si quelqu'un d'autre le faisait. Le projet entier est disponible au téléchargement à : http://www.paolopelloni.com/download/fixrhygtk.tar.xz. N'hésitez surtout pas à l'utiliser, l'améliorer et le partager. J'espère que d'autres en profiteront, comme je tire profit de l'ensemble du monde du logiciel libre !
Nous voici à la fin de ma brève histoire et je voudrais remercier à nouveau Ronnie et le magazine Full Circle pour les renseignements précieux, Greg D. Walters pour m'avoir enseigné le Python et incité à l'utiliser et, bien entendu, le monde entier de l'Open Source à commencer par l'équipe de Rhythmbox !