Magic Collection, gérer sa collection sous Linux, Mac et Win

J'ai sortie la version 0.8.2 pour corriger un vilain problème avec la version Windows, qui empêchait de télécharger les prix des cartes et de télécharger les images de l'édition Conflux. J'incite vivement tous les utilisateurs Windows à mettre à jour !

OS imbécile qui ne veut pas créer de fichier ou de dossier appelés "CON"...

Sortie de la version 0.8.3.
C'est essentiellement une version "de stabilisation" :

* Correction d'un problème de l'exportation HTML de la collection qui empêchait le fichier généré d'afficher les images des cartes ;
* dans ce même fichier HTML, la ligne de la carte affichée est maintenant coloriée en bleu clair ;
* lorsque Magic Collection choisit une carte au hasard dans la collection, la ligne de la carte est à présent sélectionnée ;
* le popup indiquant le téléchargement de la base de données est remplacé par un overlay ;
* quelques autres changements mineurs (Magic Collection vérifie maintenant qu'il y ait bien des cartes dans la collection avant de la sauvegarder / exporter, idem pour les decks, ...).

Le 21/07/2014 à 18:33, mirandir avait écrit ...
OS imbécile qui ne veut pas créer de fichier ou de dossier appelés "CON"...

Pas convaincu que ce soit la faute de windows 

Essai de créer un dossier nommé "con" sous Windows, et admire le résultat
C'est aussi valable pour tous les noms hérités du DOS style lpt1, ...

Après, c'est possible de créer des dossiers portant ces noms en utilisant certains outils de l'invite de commande, mais ces dossiers ne seront ni renommables ni supprimables par les voies classiques, ce qui est moyennement pratique.

La version 0.8.4 est sortie, avec quelques changements d'interface sympatoches. J'ai essayé de rendre l'interface plus propre et plus claire.



Nouveautés :

* Changements dans l'interface : le menu Modes est remplacé par des boutons plus pratiques, les menus Collection et Decks sont déplacés à l'intérieur de l'application ;
* correction d'un problème qui empêchait parfois le nombre de cartes du deck affiché de s'actualiser ;
* la version Windows informe désormais l'utilisateur lorsqu'une nouvelle version de Magic Collection est disponible ;
* la base de données indique maintenant quelle version minimum de Magic Collection est nécessaire pour l'utiliser. Magic Collection peut ainsi en informer l'utilisateur et proposer de se mettre à jour s'il ne peut pas utiliser la base de données actuelle ;
* en cas de problème avec la base de données, Magic Collection va automatiquement la retélécharger.

Encore Bravo pour ton logiciel, vraiment très pratique et plutôt intuitif je trouve...

Un seule question;penses tu implémenter une sorte gestion des proxys pour les decks qui partagent les memes 
cartes?
Je m'explique: Je possède en collection 4 wasteland et 3 de mes decks  utilisent un carré de wasteland.
Bien sur je ne peux les attribuer qu'à un seul deck mais je voudrais quand même signifier leur place dans chaque deck pour ne rien oublier lors des build irl.

Hello,

C'est une demande qui revient régulièrement, et c'est effectivement prévu ! Dans pas trop longtemps j'espère

Le 31/07/2014 à 18:47, mirandir avait écrit ...
Essai de créer un dossier nommé "con" sous Windows, et admire le résultat
C'est aussi valable pour tous les noms hérités du DOS style lpt1, ...

En fait, t'as parfaitement raison, et c'est pour ca que le nom en 3 lettres de conflux, c'est pas "con" mais "cfx"

Le 03/09/2014 à 11:30, Anastaszor avait écrit ...

Le 31/07/2014 à 18:47, mirandir avait écrit ...
Essai de créer un dossier nommé "con" sous Windows, et admire le résultat
C'est aussi valable pour tous les noms hérités du DOS style lpt1, ...

En fait, t'as parfaitement raison, et c'est pour ca que le nom en 3 lettres de conflux, c'est pas "con" mais "cfx"

Pas si j'en crois le Gatherer, MTGsalvation et Wikipedia

Salut, je suis tombé par hasard sur ton logiciel, moi qui suis sous Linux et GNOME, j'étais content de voir un logiciel de ce type en GTK 3 . À l'utilisation il est assez sympathique, bravo pour le travail effectué, surtout si tu n'est pas programmeur à la base !

Ensuite, il y a tout de même quelques faiblesses:
· les temps de recherche dans la base de données sont assez longs
· aller dans la zone "collection" pour construire un deck s'avère contre intuitif. Quand tu listes un deck, ce · qui t'intéresse, c'est ton deck, rien d'autre.
· avoir des statistiques pour un deck (nombre de cartes de chaque type, mana curve) serait intéressant
· la gestion des proxy
· la miniature de carte à gauche sur la vue collection et à droite sur la vue decks, je trouve ça perturbant

Étant moi même développeur connaissant bien GTK et un peu python, j'ai voulu regarder le code... Et là j'ai encore les yeux qui piquent. Un seul fichier de 6000 lignes, des noms de variables et fonctions en français, conception n'utilisant pas la programmation orientée objet (POO)... Tu as malheureusement perdu un contributeur potentiel. Quelques autres remarques (constructives, j'espère):

· HOMEMC/downloadedPics devrait utiliser XDG_CACHE_HOME/magic_collection/downloadedPics (je ne sais pas en python, mais en C, pour récupérer XDG_CACHE_HOME, il faut appeler g_get_user_cache_dir). Cela permet de séparer le cache des données utiles, c'est préconisé par la spécification XDG.
· construire des chemins de fichiers/dossiers en concaténant avec des "/", c'est mal, c'est pas très portable normalement, et il y a autant en python avec os.path que dans la GLib des fonctions adaptées pour cela.

Voilà pour les première remarques. En tout cas c'est un bel effort, je lui souhaite longue vie

Salut,

Merci pour toutes tes remarques constructives ! Comme tu l'as dit, je ne suis absolument pas programmeur, et c'est ma première fois à la fois avec Python et avec GTK.

Quelques éléments de réponse :
· Qu'appelles-tu un temps de recherche long ? Pour ma part, la recherche simple est rapide, de l'ordre de 1-2 secondes, et je suis loin d'avoir une foudre de guerre comme machine. Par contre, si tu parles de la recherche avancée, c'est l'affichage des résultats qui peut être long, pas la recherche en elle-même. On tombe là dans ma méconnaissance de GTK : j'ignore totalement pourquoi le treeview est si long à se remplir au-delà d'un certain nombre de résultats. Si tu connais bien GTK, peut-être pourrais-tu m'expliquer ce qui ne va pas ?

· Le mode Collection est utilisé pour construire les decks, car tu ne construis pas un deck à partir de rien, tu le fais à partir des cartes que tu possèdes, celles qui sont dans ta collection.

· les stats sur les decks et les "proxies", c'est dans ma to-do list

· le visionneur de carte est à gauche dans le mode Collection pour deux raisons : 1) cela permet à l'utilisateur de savoir immédiatement s'il est dans le mode Collection ou dans un autre mode, 2) dans le mode Collection, c'est les cartes qui sont importantes, pouvoir voir leurs caractéristiques est primordial. Dans le mode Decks, ce n'est pas le cas, ce qui est important c'est l'assemblage de ces cartes (la liste des cartes contenues dans le deck). Dans le mode Decks, le visionneur est là comme un rappel. J'ai organisé les éléments importants dans l'ordre de lecture de l'utilisateur (de gauche à droite).


Concernant le code :
· nous sommes totalement d'accord pour la taille du fichier. Mon problème était qu'au début j'ai eu beaucoup de difficultés pour packager le logiciel, et avoir un seul fichier aidait. Comme tu t'en doutes, ce n'est plus le cas aujourd'hui . J'ai également des difficultés à comprendre comment bien partager les différentes infos et contexte entre différents fichiers Python.

· bonne idée pour XDG_CACHE_HOME, je n'y avais tout simplement pas pensé ! Il faut par contre que je vois comment ça marche sous Windows

· concernant les slashs dans les chemins, je ne vois pas le soucis... Python les convertit automatiquement en fonction de l'OS. Ce code fonctionne sous Windows sans changement, et fonctionnerait sous les autres OS supportés par Python s'il y avait des binaires GTK et pygi dignent de ce nom.


Dans tous les cas, je te remercie pour ces remarques très intéressantes. Comme dit, je ne suis absolument pas un expert ni en programmation ni en Python ou GTK, mais je suis volontaire pour en apprendre plus et progresser. Si tu le souhaites, on peut continuer à échanger là-dessus, mais peut-être sur un autre forum (celui-ci étant plus dédié à Magic qu'à la programmation, le forum Ubuntu-fr sera peut-être plus adapté) ou directement par mail.

Salut,
quand je dis "temps de recherche long", c'est 7 secondes sur mon netbook pour la recherche simple. Pour un logiciel local, je m'attendais à de meilleures performances que les sites web qui proposent des moteurs de recherche de cartes. Je vois qu'il y a une base locale des cartes, au format XML. Une base de données binaire type sqlite donnerait sans doute de bien meilleurs résultats (de l'ordre de la centaine de millisecondes), et réduirait le temps de chargement initial (+de 7Mo à charger au démarrage), au prix d'un peu plus de complexité. C'est une piste.

Pour ce qui est du treeview, ce n'est pas la première fois que j'entends dire qu'il est long quand il y a beaucoup d'éléments. Tu as des soucis à partir de combien d'éléments environ, histoire d'avoir un ordre de grandeur ?

Ensuite, quand tu dis « Le mode Collection est utilisé pour construire les decks, car tu ne construis pas un deck à partir de rien, tu le fais à partir des cartes que tu possèdes, celles qui sont dans ta collection
 ». Je ne suis pas d'accord. Il y a deux manières de faire du deckbuilding: se dire
· « voilà les cartes à ma disposition, qu'est-ce que je peux en faire »
· ou bien « j'ai pensé à un deck autour de telle et telle carte, je vais essayer de le construire et voir si ça fonctionne avant de récupérer toutes les cartes ».

C'est à cause de ce second cas que les proxys existent. Quand tu essaies de créer un deck à partir d'une idée, tu te concentres sur le deck, pas sur la collection. Les deux approches peuvent avoir une utilité, mais celle que tu as choisie est très limitante si tu veux te concentrer sur la construction de ton deck. Elle t'oblige à reposer sans cesse la question du deck auquel il faut ajouter les cartes de la collection, ce qui est assez pénible. Je ne sais pas toi, mais je n'ai jamais listé plusieurs decks en parallèle. Pour moi on crée un deck et on va piocher dans sa collection pour le construire, alors que ton approche est celle du collectionneur qui regarde chacune de ses cartes et se dit "et celle là, dans quel deck je vais la mettre ?". Ce n'est pas très efficace je pense.

Pour ce qui est du visionneur, je ne suis pas non plus d'accord avec la première raison que tu avances. Cela ne devrait pas servir à savoir dans quel mode on se trouve, l'interface des deux modes est déjà assez différente, les boutons au dessus de la fenêtre indiquent le mode également, et normalement on devrait avoir peu d'aller-retours à faire entre les modes. Dans les cas où les cartes qu'on essaie d'ajouter à un deck ne sont pas connues dans la collection, tu peux proposer de les ajouter à la volée ou en tant que proxy. Ainsi tu intègres les proxy à ton workflow.

Dans une interface graphique, la prise d'habitude est primordiale pour l'utilisateur. Savoir que quelque soit le mode, mon regard n'a qu'à aller d'un côté, toujours le même, et je verrai la carte me permet d'acquérir des réflexes. Et puis je ne pense pas que ce soit moins important dans le mode deck de voir la carte: l'assemblage est certes important, mais tu ne connais pas forcément toutes les cartes sur le bout des doigts quand tu construits un deck. Je serais complètement paumé sans visionneuse, parce qu'elle me sert à vérifier que tel combo fonctionne bien en relisant le texte exacts, ou tout simplement parce que le cerveau reconnait plus rapidement une image que du texte.

Pour ce qui est du programme en lui même et de l'architecture, je te conseille vraiment de te pencher sur la programmation orientée objet en python, tu verras que cela simplifie grandement le découpage logique de ton programme. Par exemple, la notion de "carte" englobe plusieurs choses: une carte abstraite (le concept), et une carte physique (le bout de carton). La carte physique est une instance. Ensuite, la gestion d'une collection, des decks, des sideboards, des proxys se résume à des ensembles de cartes physiques ou abstraites, et choisir les bonnes relations entre eux. Par exemple à cause des cartes doubles, tu peux avoir une carte physique qui correspond à plus d'une carte abstraite, il faut donc prendre cela en compte dans la conception.

Pour XDG_CACHE_HOME, si tu utilises les fonctions de la glib pour ça, tout est transparent que tu sois sous Linux ou Windows. Pour ce qui est de la construction de chemins, je confirme que c'est une mauvaise habitude, c'est pour ça qu'il y a des fonctions pour ça. Cf os.path.join en python et g_build_path fourni par la glib (c'est le nom en C). Si ça marche pour le moment, c'est bien, mais c'est parce que tu n'es pas (encore) tombé sur un cas où ça pose problème (séparateurs multiples, fichiers avec des noms bizarres, etc). J'ai 15 ans de développement dans les pattes, et je peux te dire que si, ça arrive .

J'ai des compétence en GTK, en conception objet et conception d'interface utilisateur. Je ne sais pas où tu habites, mais si tu es sur la région parisienne, ça me ferait plaisir de discuter de cela avec toi autour d'une bière . Et sinon, pour les questions en GTK, le forum le plus actif est celui de developpez.net (en français), ou bien sur stackoverflow.com (en anglais). Je réponds sur les deux, même si je ne suis pas très actifs ces derniers temps (claque moi un message privé si tu postes quelque chose, je serai notifié). J'ai le même pseudo sur ces même sites.
http://stackoverflow.com/users/518853/liberforce
http://www.developpez.net/forums/u311541/liberforce/

@+

Le 03/09/2014 à 12:47, mirandir avait écrit ...

Le 03/09/2014 à 11:30, Anastaszor avait écrit ...

Le 31/07/2014 à 18:47, mirandir avait écrit ...
Essai de créer un dossier nommé "con" sous Windows, et admire le résultat
C'est aussi valable pour tous les noms hérités du DOS style lpt1, ...

En fait, t'as parfaitement raison, et c'est pour ca que le nom en 3 lettres de conflux, c'est pas "con" mais "cfx"

Pas si j'en crois le Gatherer, MTGsalvation et Wikipedia

putain t'as raison en fait, y'a que magiccards.info qu'a fait ca. Font jamais comme tout le monde eux.. ^^

Salut,

Le 11/09/2014 à 23:10, Anastaszor avait écrit ...
putain t'as raison en fait, y'a que magiccards.info qu'a fait ca. Font jamais comme tout le monde eux.. ^^

Pour être précis, CFX c'était bien le nom en trois lettre de Conflux avant que Wizards ne décide récemment d'attribuer à toutes les éditions un code de trois lettres, même les anciennes (qui avaient un code de 2 lettres). Et en passant ils ont modifié certains noms de trois lettres déjà existants, ce qui fait que Conflux est passé de CFX à CON.

Le 11/09/2014 à 05:28, liberforce avait écrit ...
Salut,
[...]

J'ai bien reçu ton MP, je vais répondre !
Pour ce qui est de la bière, ça aurait été avec grand plaisir  mais je suis vraiment trop loin de Paris pour l'envisager. Dommage !

Bonjour!

Je suis avec attention le développement de ce petit logiciel, qui parait très prometteur.
Au passage, bravo à toi, Mirandir.
Je n'ai encore pas beaucoup utilisé Magic Collection, mais avec la sortie de Khans of Tarkir, j'ai décidé de m'y mettre très sérieusement.

Hier j'ai commencé à rentrer une (infime) partie de ma collection, et aujourd'hui, lorsque j'ai voulu m'y remettre, impossible de relancer le programme.
J'ai essayer de supprimer certains fichiers dans le dossier "nom d'utilisateur"/.magiccollection/, mais sans succés.
Je les ai donc restauré.
J'ai ouvert une invite de commande comme tu proposais de le faire à illidqn et voici une retranscription de ce que j'ai eu:
C:/Program Files (X86)/Magic Collection>magic_collection.py
Conversion des decks et de la collection en cours...
Traceback (most recent call last):
  File "C:/Program Files (X86)/Magic Collection/magic_collection.py" , line 6136.
in <module>
     ConversionCodes()
 File "C:/Program Files (X86)/Magic Collection/magic_collection.py" , line 6022.
in ConversionCodes()
     contenudeck = fichierdeck.readlines()
 File "C:/Python33/lib/codecs.py" , line 313. in decode
    (result. consumed) = self._buffer_decode(data. self.errors. final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 22: invalid
 continuation byte
J'aime pas m'avouer vaincu donc je cherche encore...
Je décide de simplement déplacer le dossier .magicollection, et je relance.
Et là ça redémarre.
Par chance, j'avais fait un export de ma collection vers un fichier txt.
Je retrouve donc mes cartes rentrées hier, ouf.

M'enfin, ça me dit pas d'ou venait le problème...


Pour finir, j'ai une question sur l'utilisation du logiciel, est-il possible d'ajouter une deck préconstruit?
Par exemple, si j'achète le duel deck speed vs cunning, y-a-t-il possibilité d'ajouter à la collection non pas 1 exemplaire de chaque carte de "l'edition", mais le deck complet en lui-même, avec le bon nombre de carte correspondante, sans avoir à les rentrer une par une?
@+