Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 22-04-2014 18:55:56

leonlemouton
Adhérent(e)
Distrib. : Jessie
Noyau : Linux 3.16.0-4-686-pae
(G)UI : Mate 1.8.1
Inscription : 14-08-2012

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Lunatic,

Voici la réponse de tryolabs à propos de la demande de login pour leur site de démo de LibreQDA:

thank you for your interest! We recommend you to install it locally following these instructions: https://github.com/tryolabs/libreQDA


Donc il va falloir mettre les mains dans le cambouis si tu veux voir à quoi ça ressemble... big_smile
Si je test chez moi je te fais signe.

@+


Leonlemouton
°(")°

Hors ligne

#27 30-04-2014 22:54:39

Lunatic
Membre
Lieu : Lyon
Distrib. : Fedora 24
Noyau : Linux 4.6.5-300.fc24.x86_64
(G)UI : Gnome
Inscription : 03-08-2013
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Merci leon pour ces news.

Je reviens avec quelques questions. J'ai commencé à concevoir l'interface avec QT Designer. Je découvre au passage QT et la poo dont je n'avais que des connaissances très théoriques et « de base ».

Ma première question concerne l'aspect XML : je me demandais s'il était préférable d'avoir un seul fichier XML par projets (par projets, j'entends un ensemble de textes codés avec les mêmes codes) contenant tout ce qu'il est possible de stocker (les codes, les références des fichiers textes importés, les méta-données, les segments codés, les requêtes enregistrées) ou bien au contraire s'il valait mieux multiplier les fichiers (un fichier XML pour les codes, un pour les segments, etc).

D'un côté, je me dis qu'il est plus simple pour l'utilisateur de n'avoir qu'un seul fichier à sauvegarder ou déplacer. De l'autre, je me demande si un tel gros fichier ne ralentit pas les opération (en lecture/écriture) et si ce n'est pas moins « sécurisé » : si la syntaxe est erronée pour un seul élément, c'est tout le fichier qui risque d'être illisible.

Ma seconde question concerne justement l'écriture d'un fichier XML. Dès que l'utilisateur surligne le texte pour le coder, il introduit un changement. Ce changement (i) doit-il être immédiatement écrit sur le disque en modifiant le fichier XML ou bien (ii) ne doit-il être fait qu'en mémoire et n'être « concrétisé » dans le fichier que lors d'une sauvegarde ?

Ma troisième et dernière question (pour le moment !) concerne plus généralement le « style » de codage. Je découvre (ou redécouvre parce que j'avais déjà un peu vu ça avec wxpython) que l'interface consiste en une « grosse » classe contenant l'ensemble des élément visuels (widgets et autres) et quelques fonctions « connectant » les éléments entre eux. Plus précisément, je respecte ce qui est indiqué ici : QT Designer crée une classe, j'en crée une seconde qui hérite de la première.
J'aimerais savoir où je suis censé placer les fonctions « moteur » si j'ose dire, celles réalisent les tâches les plus spécifiques (comme extraire du texte surligné pour l'enregistrer dans un fichier XML avec les bonnes informations) : est-ce que tout ça est censé se trouver dans ma classe « enfant », ou bien en dehors de toute classe ? Je pencherais pour la dernière solution, mais les exemples (certes triviaux) que je trouve montrent tous des fonctions incluses dans une classe.

J'sais pas si je suis très clair :-/

Merci smile

Dernière modification par Lunatic (30-04-2014 22:57:00)


Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000

(J'applique la règle de proximité)

Hors ligne

#28 30-04-2014 23:30:10

nIQnutn
Modérateur
Lieu : Lyon
Distrib. : Jessie
Noyau : Linux 3.16-amd64
(G)UI : XFCE
Inscription : 16-03-2012
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

la première question: je pense qu'il te faut garder tes interviews individuellement dans un fichier (on dit que personne n'avait le droit d'y toucher), après tu aura un fichier avec tous les segment et peut être un fichier de "config" pour le projet avec les requêtes et autres éléments à stocker

A voir si tu as l'utilité de mutualiser les codes (j'aurai tendance à dire non). Dans ce cas un fichier pour l'ensemble des codes.

Le pb d'avoir plusieurs fichier n'en est pas dans la mesure ou un fichier zip te feras économiser de la place au sein d'un même fichier.
C'est certain qu'en multipliant les fichiers tu limites la casse. Dans la mesure on ton code est propre et testé ça ne devrait pas poser de pb.
L'avantage du XML est qu'il existe des outils pour voir si le fichier est bien formé et validé (XML Schema) et qu'avec ça pas de pb à ce niveau.


Pour la deuxième question, je n'ai pas d'avis. Pas beaucoup de développement et surtout ça passait sur des bases de données. Il faudrait savoir à quel rythme tu avances dans le codage de tes interviews. Si c'est long ou très long, une sauvegarde plus fréquente peut être utile.

Tu peux envisager tout mettre dans une seule classe mais ça devient vite le bordel. Je dirai qu'il te faut autant de classe que tu as d'objets à manipuler: les interviews, les synthèses, etc..


Je relirai ce qui a été dit et reprendrai ce que j'ai déjà fait en programmation pour essayer de t'aider (c'est pas gagner)
Je pense qu'un document de synthèse accessible serait utile pour bien comprendre ton jargon et voir où tu en es, des choix que tu as fait, des éventuelles pb, etc.

Hors ligne

#29 01-05-2014 10:08:31

Lunatic
Membre
Lieu : Lyon
Distrib. : Fedora 24
Noyau : Linux 4.6.5-300.fc24.x86_64
(G)UI : Gnome
Inscription : 03-08-2013
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Merci pour tes conseils et avis smile Je détaillerai un peu les choses, avec un document de synthèse, lorsque j'aurai avancé davantage sur le projet. Pour le moment je n'ai qu'une belle interface qui ne fait pas grand chose tongue

Bonne journée

Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000

(J'applique la règle de proximité)

Hors ligne

#30 01-05-2014 12:37:26

nIQnutn
Modérateur
Lieu : Lyon
Distrib. : Jessie
Noyau : Linux 3.16-amd64
(G)UI : XFCE
Inscription : 16-03-2012
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Bon courage.

Hors ligne

#31 01-05-2014 16:10:25

Lunatic
Membre
Lieu : Lyon
Distrib. : Fedora 24
Noyau : Linux 4.6.5-300.fc24.x86_64
(G)UI : Gnome
Inscription : 03-08-2013
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Y'a un truc que je n'arrive pas à saisir avec la poo, c'est la façon dont on accède à un objet précis. J'explique : dans les tutos que je lis, les objets sont créés « en dur » dans le code. Par exemple, on a une classe Voiture() et deux instances de cette classe, voiture1 et voiture2, apparaissant explicitement dans le code. Du coup, il n'est pas difficile d'accéder aux attributs et méthodes de ces deux objets puisqu'on les connaît.

Dans mon cas, je crée, par exemple, une classe Interview(). Disons qu'elle a une méthode qui « nettoie » le texte (supprime les éventuelles lignes blanches finales), et différents attributs (le nom de la personne interviewée, le chemin vers le fichier texte de l'interview, etc.). À la différence de la situation précédente, je ne peux logiquement pas créer mes objets « en dur » : ils dépendent entièrement des données de l'utilisateur. Je peux les créer en parcourant mon fichier XML : j'en ai trouvé un exemple ici mettant en scène, c'est le cas de le dire, des objets « films » et « oscars ».
Dans cet exemple, les objets sont « printés » au fur et à mesure de leur création. Mais comment est-on censé s'y prendre pour récupérer plus tard dans le programme, par exemple, l'attribut « réalisateur » pour l'objet dont le titre du film est « Black Swan » ? L'objet existe puisqu'il a été créé, mais je ne pige pas comment on est sensé le « retrouver ».

Merci wink

Dernière modification par Lunatic (01-05-2014 16:13:44)


Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000

(J'applique la règle de proximité)

Hors ligne

#32 01-05-2014 21:45:52

bendia
Admin stagiaire
Distrib. : Jessie
Noyau : 3.16.0-4-amd64
(G)UI : Gnome + XFCE + Console
Inscription : 20-03-2012
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Salut

Dans l'exemple que tu donnes, il me semble que les objets sont juste fait pour simplifier la mise en forme de l'impression des données. Il sont stockés sous forme de liste et on y accède donc par leurs indices dans cette liste. Si tu ne connais pas l'indice, tu ne peux pas retrouver l'instance qui t'intéresse. Pour retrouver ton info, tu es donc obliger de parcourir toute la liste genre


def real(films):
  for titre in films:
    if titre.titre=="Black Swan":
      return titre.realisateur


On pourrait imaginer de stocker ça dans un dictionnaire à la place d'une liste avec le titre comme clé par exemple. Ainsi, on récupérerait le nom du réalisateur comme ceci

films["Black Swan"].realisateur


Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
file-Re06858991f6f328b4907296ac5cea283

Hors ligne

#33 01-05-2014 22:31:27

Lunatic
Membre
Lieu : Lyon
Distrib. : Fedora 24
Noyau : Linux 4.6.5-300.fc24.x86_64
(G)UI : Gnome
Inscription : 03-08-2013
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Ok, merci, donc si je résume, la seule façon de garder la trace des objets créés « à la volée » pour y accéder de nouveau, c'est de soi-même créer une liste (ou un dictionnaire) les contenant tous. Je m'attendais à ce qu'il y ait un mécanisme spécifique.

Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000

(J'applique la règle de proximité)

Hors ligne

#34 02-05-2014 17:59:00

Lunatic
Membre
Lieu : Lyon
Distrib. : Fedora 24
Noyau : Linux 4.6.5-300.fc24.x86_64
(G)UI : Gnome
Inscription : 03-08-2013
Site Web

Re : Préparation d'un projet de logiciel de « codage » (QDA)

Bon, j'ai modestement avancé.

1399044739.png

La liste des textes est lue depuis un fichier XML (composé à la main pour le moment). Lorsqu'on double-clique sur le nom d'un texte (ici = nom d'une personne), un onglet s'ouvre avec le texte correspondant. Si l'onglet est déjà ouvert, on bascule dessus.

La liste des codes est également lue depuis un fichier XML composé à la main. En revanche je n'ai pas encore géré l'arborescence. Je sens que je vais bien me prendre la tête avec la fonction récursive qui va me permettre de passer du XML à l'arborescence des codes.

Le bouton « Coder » renvoie bien, dans la console pour le moment, la portion de texte sélectionnée de l'onglet actif.

Mon soucis le plus immédiat est le suivant : comment gérer, pour un même code, deux segments qui se chevauchent et qui ne devraient faire qu'un.

Par exemple, je code sur la chaîne de A à Z ce qui apparaît en gras :

ABCDEFGHIJKLMNOPQRSTUVWXYZ

Je me rends compte plus tard que j'aurais dû commencer à « G ». Si je surligne de G à P, ça ne pose pas de problème : le programme peut facilement détecter que JKLMNOP est une sous-chaîne de GHIJKLMNOP. En revanche, si je surligne de G à n'importe quelle lettre avant P, il faut détecter que je tente de recoder une sous-chaîne d'un segment existant (et non pas de la totalité de ce segment).

Par exemple, je peux coder GHIJK. Comme J..P est déjà codé, je devrais aboutir à un seul et unique segment, de G à P. Alors j'imagine bien qu'on pourrait faire une boucle du type :
- est-ce que GHIJK existe déjà dans un segment de texte ? -> non -> est-ce que HIJK existe déjà dans un segment de texte ? -> non -> est-ce que IJK existe déjà dans un segment de texte -> non -> est-ce que JK existe déjà dans un segment de texte ? -> oui -> fusionner les deux segments

Mais ça me paraît super lourd comme méthode, et risqué. D'ailleurs, ça ne résout pas un problème qui est que je peux coder, dans un deuxième temps, de G à I compris : y'a aucune sous-chaîne identique entre G..I et J..K, et pourtant on doit bien aboutir à un et un seul segment.

En revanche si je me base, finalement, sur la position du curseur, ce soucis est facilement évitable. Le programme détecte aisément qu'un segment chevauche un autre segment, ou que deux segments sont en fait « continus » et ne devraient formés qu'un.

Du coup je me demande s'il est bien judicieux d'utiliser XML. Mais y'a peut-être une solution qui m'échappe

Je suis aussi sur Twitter et nouvellement sur Diaspora*
Mon blog de geekeries : HAL-9000

(J'applique la règle de proximité)

Hors ligne

Pied de page des forums