OpenPlane

a marqué ce sujet comme résolu.

qwerty: en gros l'idée c'est que le centre de gravité d'un avion doit être dans une certaine zone, sinon ça vole comme une merde. Par exemple, quand c'est trop arrière c'est super instable, j'en ai fait les frais sur un de mes planeurs RC, départ en vrille à gogo et après faut sortir la colle. Du coup, son soft permet de calculer la position du centre de gravité selon le poids des passagers et de tout le bordel pour savoir si t'es dans une bonne plage de centrage pour voler. Il y a aussi un convertisseur pied/m parce que les pilotes utilisent souvent des valeurs d'altitude en pieds.

+1 -0

Salut tout le monde !
Pour l'extension personnelle :
Non ce n'est pas absolument pas nécessaire, mais ça me permet plusieurs choses dont notamment limiter la sélection de fichier à cette extension. Actuellement, l'importation de fichier affiche tous les .json ce qui veut dire que l'on peut importer tout et n'importe quoi. D'où le but d'avoir sa propre extension pour limiter ce choix. Et WinXaito te donne une autre raison.

Merci WiXaito ! :)

Je publie la version 0.7 d'ici peu (qui est chargé niveau changement) et je m'attaquerais à la version 0.8. J'ajoute ta proposition à cette prochaine version.
L'application est fournie avec deux avions de test, rend toi dans Masse et centrage, sélectionne un avion et règle la masse à vide standard à 722kg. Tu peux voir les autres valeurs dans mon premier post. :)

+0 -0

Je n'ai jamais fait de TKinter pour la simple et bonne raison que je le trouve hideux.

J'en suis moi-même le plus impressionné, crois-moi ! Jamais je ne me serais crû capable de ça.

Récapépet' de la v0.7

Voilà, la version 0.7 d'OpenPlane ne devrait pas tarder à être mise en ligne. Il me reste deux trois trucs à régler mais globalement, j'ai fais ce que je voulais faire pour cette version. Petit listing :

  • Séparation de l'historique du fichier README.md
  • Ajout du logo (cf. Blackline)
  • Toutes les fenêtres sauf le convertisseur utilisent un fichier Glade désormais. Ça me permet de grandement alléger les fichiers Python et de ne plus me prendre la tête avec les layouts
  • Le hangar et l'éditeur d'avion passe au format Dialog
  • Conséquence de cette modification, ajout d'un bouton qui mène vers le hangar dans la fenêtre de masse et de centrage
  • Tous les chemins et nom de fichier sont stocké dans un seul et même fichier, config.py, ce qui permet notamment la mise en place de chemin compatible avec tous les systèmes
  • Tous les textes affichés dans les GUIs qui ne sont pas généré par Glade mais manuellement sont stockés dans un seul et même fichier, text.py afin de faciliter la traduction
  • Amélioration de la preview du graphique de masse et centrage. Le contour devient rouge si les points sortent du cadre :
    Image utilisateur Vous pouvez voir au passage le fameux nouveau bouton à droite du sélecteur d'avions
  • Quasiment tous les boutons utilisent un format prédéfini par Gtk. Ce qui permet les traduction automatique de ceux-ci et des petites icônes si vous les autorisez sur votre système.

Voilà, j'espère ne rien avoir oublié. Il me reste tout de même une question, concernant la licence. Je pense me tourner vers la GPLv3, est-ce une bonne idée ?

Merci à vous de me suivre et de me faire part de toutes vos questions & remarques ! :)

+1 -0

Personnellement je mets des licences permissives sur mes logiciels, d'une part parce que tout le monde se fout de ce que je fais. Tout ce qui compte pour moi c'est qu'il y ait mon nom dessus et un disclaimer légal. Du coup je mets une licence MIT, même si j'aime bien le concept de la Licence Publique Rien à Branler :D

C'est une question de choix personnel. J'aurais tendance à dire que ce qui compte c'est que ton code aide le plus grand nombre, donc autant prendre une licence qui met le moins de restrictions possibles et qui ne soit pas assez épaisse en version imprimée pour caler un meuble (tousse GPL)

+1 -0

Je sais pas si ça était dit ou si j’ai rêvé, mais pourquoi pas mettre quelques fichiers de démonstrations pour que les néophytes fassent joujou en testant des valeurs ? (Oui, je sens que je vais installer ton logiciel juste en guise de jeu !)

+3 -0

Bonjour à tous !
La version 0.7 d'OpenPlane à été pushé sur Github il y a quelques minutes. Je vais vous écrire ici un petit guide pour jouer avec celle-ci ! (Je suis gentil hein ? :p )

Pour la licence, j'ai choisi la GPL3, comme ça, c'est réglé. C'est une licence qui me convient et elle n'est pas totalement permissive, ce que je voulais.

Et oui deux avions sont déjà prêt à être tester, F-TEST et F-BTBB. Ils ne devraient pas tarder à disparaître, pour y avoir à la place le profil des différents avions de mon aéroclub.

Utiliser OpenPlane

Lancez OpenPlane (rappel, avec python3 app.py). Vous vous retrouvez devant une mini-fenêtre contenant 5 boutons. Je vous invite à d'abord faire un tour dans la fenêtre about en cliquant sur le bouton correspondant afin de découvrir un logo disproportionné.

Passons aux choses sérieuses. Ouvrez Masse et centrage. Ne vous inquiétez pas devant le nombre impressionnant de boutons. En haut sélectionnez l'avion F-BTBB grâce à la liste déroulante. Si vous vous sentez d'humeur, je vous invite à cliquer sur Ajouter afin de découvrir le Hangar. Sélectionnez un des deux avions et cliquez sur modifier. Explorez les différents onglets, mais ne modifiez pas les valeurs (du moins, pas celle de l'onglet Centrage si vous ne savez pas ce que vous faites).

Une fois l'avion F-BTBB importé, remplissez le tableau comme-ceci : Image utilisateur
Puis amusez-vous à changer les valeurs et observez ! :D

+0 -0

J'ai moi même un mac chez moi mais impossible d'installer PyGObject, comme tu peux le voir ici c'est assez compliqué. C'est pour ça que je ne demanderais jamais à quelqu'un se trouvant sous un système Apple de tester mon application. Après si tu te sens d'attaque, je ne dirais pas non, au contraire ! :)

En tout cas, merci de suivre le projet !

+0 -0

Sous Linux, PyGObject s'installe avec un simple sudo apt-get install python3-gi.

Passer le projet en C++, non c'est au-dessus de mon courge. Parce que je ne supporte pas la syntaxe du C++ et que je n'ai pas envie de me prendre la tête.

De plus, le Python est réputé pour être multiplateforme. Si PyGObject est un frein, je peux passer le programme sous une libraire Qt en python. PyQt serait-il une solution ?

EDIT : je suis désolé, j'ai trouvé mon non un peu trop sec.. :(

+0 -0

Bonjour à tous,

Je suis entrain de penser au carnet de vol qui va être la grosse nouvelle fonctionnalité de la v0.8.

L'utilisateur devra ajouter un vol et donner les informations de celui-ci. Ma question est, comment stocker ces informations ? Trois solutions :

  • Au format JSON
  • Avec SQLite
  • Avec MangoDB

Les avantages du JSON sont surtout que ça ne fait pas de nouveau module à installer et que ça rend les vols facile à modifier. Cependant, ce format n'est pas forcément très adapté à cette situation (beaucoup de lecture mais pas beaucoup d'écriture). De plus, ça fera un fichier par vol, sois beaucoup de fichiers, ce qui ne me convient pas du tout.

SQLite ou MangoDB, c'est là ma vraie hésitation. J'avoue ne jamais avoir touché à MangoDB contrairement à SQLite (énormément avec Ruby, pas beaucoup avec Python). Mais apparemment MangoDB est beaucoup plus rapide qu'SQLite en lecture.

À vous de me dire ce que vous en pensez, je pencherais personnellement plus pour SQLite. Et vous ?

+1 -0

Autant faire simple. MangoDB il faut un serveur, pas besoin pour SQLite. C'est donc soit SQLite soit JSON.

Pour le coup de "un fichier par vol", rien ne t'empêche de zipper tous tes fichiers JSON. Est-ce que tu pourrais donner plus d'infos sur le carnet de vol et les infos sur chaque vol, qu'on te guide mieux ?

Personnellement, je pense que la vitesse de lecture on s'en tape totalement dans ton cas, ce n'est pas très significatif. Je dirais donc JSON parce que c'est un format texte et que t'as pas besoin de nouveaux modules.

+0 -0

Merci de ta réponse.
À vrai dire, je ne savais que MangoDB nécessitait un serveur pour fonctionner. :-° Donc clairement oui, pas MangoDB.

Si j'opte pour les fichier JSON, j'obtiendrais la hiérarchie suivante (noms temporaires) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
.
└── Carnets de vol
    ├── Carnet de vols 1
    │   ├── config.json
    │   ├── vol (3e copie).json
    │   ├── vol (4e copie).json
    │   ├── vol (5e copie).json
    │   ├── vol (6e copie).json
    │   ├── vol (autre copie).json
    │   ├── vol (copie).json
    │   └── vol.json
    └── Carnet de vols 2
        ├── config.json
        ├── vol (3e copie).json
        ├── vol (autre copie).json
        ├── vol (copie).json
        └── vol.json

Avec donc la possibilité d'avoir plusieurs carnets de vols. Une autre solution que je n'avais pas envisagé serais un fichier CSV par carnets de vol qui contiendrais toutes les entrées. Bien que je ne suis pas fan du CSV, ça peut se faire.

Ensuite, un vol contient 21 données (pour le moment, d'après ce que j'ai en tête). En voici la liste :

  • Date
  • Aeronef
  • Fonction à bord
  • Nature du vol
  • Membre d'équipage
    • Jour
    • Nuit
  • Pilote monomoteur
    • Jour
      • Double
      • Commandant de bord
    • Nuit
      • Double
      • Commandant de bord
  • Pilote multimoteurs
    • Jour
      • Double
      • Commandant de bord
      • Co-pilote
    • Nuit
      • Double
      • Commandant de bord
      • Co-pilote
  • Vols aux instruments
    • Double
    • Pilote
  • Simulation
  • Arrivées IFR

Ça se sont vraiment les données de base qui sont dans un vrai Carnet de vols. Après je compte rajouter quelques infos comme le terrain de départ et d'arrivée, les heures de départs et d'arrivées, commentaires sur le vol (pour garder des souvenirs, ou je ne sais quoi), la météo, etc.
Toutes ces données afin de réaliser des statistiques sympa, car c'est bien d'avoir des chiffres, mais autant les faire parler ! ;)

Les stats n'arriveront pas tout de suite dans la v0.8 je pense, mais après. Les carnets de vol devront cependant être disponible.

Il vaudrait mieux faire un CSV non ? Ouvrir un seul fichier qui possède toutes les données vaut mieux que de parcourir tout un répertoire pour lire les données dans un fichier un à un, non ?

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte