Re: [pymecavideo] Re: [branche New_UI]Besoins de tests

[ Thread Index | Date Index | More lists.tuxfamily.org/pymecavideo Archives ]


(REMPLACE LE MESSAGE PRECEDENT !!!!)

Bonjour,

Cette année en ECE il y a eu un sujet (je ne pense pas dévoiler quoi que ce soit de confidentiel..vu qu'on trouvait tout sur le forum TI-Planet) pour lequel il fallait pointer les positions d'un pendule...mais seulement les extrema (donc une image de temps en temps). Une telle chose ne semble pas possible avec pymecavideo (mais l'est avec avimeca).

Oui, j'ai testé cet ECE... effectivement ce serait pas mal de pouvoir utiliser pymecavideo. D'autant plus que de plus en plus de collègues s'y intéressent.
 
Donc, voici ce que l'on peut faire :
1) désactiver toute vélléités de retour en arrière ;) dès lors que l'on a touché à la spinbox.
Solution sale, mais implémentable.. (mes premiers essais montrent que ce n'est pas tout à fait si simple que cela)

Je dirais que le retour en arrière n'est pas indispensable... on pourrait peut-être contourner le problème avec un bouton permettant d'effacer le point correspondant à l'image en cours choisie dans la spinbox. Eventuellement superposer le point en cours avec une couleur différente pour bien l'identifier parmi tous les autres.
 

>Le mode chronophotographie fonctionne bien, est-ce qu'il serait possible de l'enlever après l'avoir activé ?
Peux-tu être plus précis sur ce que tu souhaiterais ? Sur le fonctionnement, une fois la chronophotographie faite ?

désolé, je vais tenter d'être plus clair... En fait lorsqu'on a choisit le mode chronophotographie, on ne peut plus revenir en arrière et retrouver le fond "normal". Si le bouton chronophotographie était checkable, on pourrait passer d'un mode à l'autre en mettant à jour le label.
 
Comme je le disais, de plus en plus de collègues s'intéressent à pymecavideo, c'est une bonne nouvelle ! (peut-être après le passage à win7/ 8 et les codecs qui buggent avec avimeca ???)
Par contre, ils veulent tous une petite fonction en plus.... je compile par ordre de faisabilité/intérêt :

- Pointer sans échelle (relativité du mouvement en 2de par exemple) -> C'était pas possible il y a quelques versions de cela ou je me trompe ??
- Impression des courbes (ou exportation en pdf) -> faisable mais quelques améliorations/options à apporter au traceur avant.
- Un curseur "cible" pour pointer -> visiblement le zoom ne convient pas à tout le monde, ils ont bien tort :-)
- Le tracé des énergies Em, Ep, Ec -> faisable si on entre la masse de l'objet, puisqu'on a déjà la vitesse et la hauteur.
- La modélisation des courbes -> un gros morceau, pas à l'ordre du jour et pas utile ?

Du coup j'ai fait quelques tests :

- Coller un curseur perso (src_curseur en pj). ça marche sur le principe mais le curseur est moche (antialiasing ?)
- Utiliser la branche pyqt5 de pyqtgraph (src_pgraph_pyqt5 en pj). ça marche si on distribue cette version de pyqtgraph (3 Mo)  avec 1 seul fichier Qt.py à modifier : ligne 23 : libOrder = [PYQT5, PYQT4, PYSIDE ]

Je tenterais bien d'étoffer un peut le module traceur (style des points, exportation, énergies ? ...) mais ça dépendra de la méthode choisie pour stocker les points. Dans tous les cas, ce serait pas mal de balancer toutes les valeurs vers le module pgraph et faire le choix des courbes dans le traceur plutôt que dans l'ui principale (plus de flexibilité si on veut à terme superposer plusieurs courbes, tracer les énergies et pourquoi pas modéliser).

Mais tout cela ne répond que partiellement à ta question, JB !
A+

JD



Attachment: src_pgraph_pyqt5.tar.gz
Description: GNU Zip compressed data

Attachment: src_curseur.tar.gz
Description: GNU Zip compressed data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/