You are not logged in. Please login or register.
QElectroTech → News → Nouveautés de la version de développement 0.7
Pour le coup je pense que Qtsvg sera suffisant car justement avec Qet nous avons besoins de chose simple.
Après l'avantage encore une fois c'est standard, donc rien n’empêche de changer de moteur de rendue svg dans le code.
Revision: 5819
Author: blacksun
Date: 2019-04-02 19:36:32 +0200 (Tue, 02 Apr 2019)
Log Message:
-----------
Improvement : minimize the unwanted gap of the top right folio of the view
J'ai encore amélioré voir supprimé (c'est comme les conducteurs fantôme, je comprend pas pourquoi ça agit comme ça) le problème du bord supérieurs gauche du folio qui est décalé par rapport à la vue.
Pour les schémas existant avec ce problème, il suffit de tout sélectionné (ctrl+a) déplacer un petit coup par exemple flèche haut puis bas (comme ça tout revient à sa position initial) et le problème est réglé.
Attention fait bien les mouvements avec retour à la position initial vous même, si vous faite une annulation (ctrl+z) ça ne sera pas pris en compte.
Beaucoup d'informations essentielles de Joshua dans les messages des derniers jours 
Alors, le plus important : laisser tomber QET et en faire un fork. Oui, pourquoi pas 
.
En fait, ce sera pas vraiment un fork, vu que la branche principale de développement s'achèvera quand la nouvelle commencera.
Il s'agit simplement de ne plus assurer de rétro-compatibilité.
Personnellement, je suis plutôt pour car il manque à QET certaines choses primordiales qui n'ont pas été pensées à la base.
De mon point de vue, le fait que les bornes de connexion (les barres rouges et bleues) n'aient pas un ou plusieurs champs texte qui leur soit attaché représente une grosse lacune de conception.
Cela revient à dire que QET ne sera jamais capable de dire sur quelle borne d'un appareil est relié tel ou tel conducteur.
Cette fonctionnalité, c'est la base nécessaire à beaucoup d'édition de post-traitement, comme par exemple :
- les borniers automatiques complets (ceux de Unalcalde ne sont pas complets mais il a tiré le maximum de ce qu'on pouvait faire dans l'état actuel des choses).
- les listes de câble
- les plans/listes de filerie
- etc.
Evidemment, c'est une grosse décision de stopper la rétro-compatibilité.
Mais franchement, pour moi, elle a déjà cessée entre la 0.61 et la 0.7.
Récemment j'ai du retrevailler le plus gros projet que j'ai fait avec QET jusqu'à maintenant. Environ 150 folios créés avec la v0.5-dev de l'époque.
J'ai essayé de la passer en v0.7-dev pour pouvoir profiter des derniéres fonctionnalités et notamment le chercher/remplacer très pratique dans les gros projets. Et ben j'ai failli m'arracher les cheveux quand j'ai réalisé le travail que je devais accomplir pour upgrader tout le projet à la v0.7-dev. Donc je me suis contenter de sortir l'appimage v0.61, d'ouvrir le projet et de réaliser les modifications pour lesquelles mon client me paye.
Ce projet ne sera donc vraisemblablement jamais édité avec une version supérieure à la v0.61.
Evidemment, si ce projet ne faisait que 15 folios, ce serait assez rapide de l'upgrader, mais là, 150 folios, personne ne paiera le travail nécessaire.
Petite anecdote pour éventuellement modérer la dureté de l'évolution possible de QET :
en 1984, Eplan 5 sort sur plate-forme MS-DOS.
Quelques années plus tard, suivant l'évolution des systèmes d'exploitation, Eplan 5 est adapté à Windows et devient, déjà à l'époque, une référence dans son domaine.
Les années passent, le logiciel évolue et est toujours rétro-compatible : on peut toujours ouvrir un ancien projet avec une nouvelle version du logiciel.
Début des années 2000, Windows 7 va bientôt devenir le nouveau standard et Eplan 5 commence à faire viellot dans tous les domaines : performances, graphismes, utilisation, étendu des fonctionnalités, ergonomie... Bref, ce logiciel de plus de 20 ans, qui trimballe toujours sa base MS-DOS sous le capot, doit être remplacé sinon il mourra.
Son remplacant arrive en 2006 et s'appelle Eplan P8. Totalement nouveau (partant d'une page vierge) et utilisant le .NET framework de Microsoft, Eplan P8 est complètement dans l'air du temps et utilise déjà nombres d'améliorations déjà inclues dans QET ou intuitivement souhaitées par Joshua, comme par exemple :
- stockage de quasiment toutes les informations en format XML
- utilisation de base de données pour gérer, entre autre, les articles
- un projet est une archive comprimée contenant toutes les données nécessaires (projet en xml, images, extraits de bdd...)
Malgré tous les chamboulements et améliorations, il est toujours possible de convertir un projet Eplan 5 créé par exemple en 1988 au nouveau format d'Eplan P8 version 2018. Grosso-modo, 30 ans de rétro-compatibilité. Pas mal !
Mais... et il fallait que cela arrive, avec la publication d'Eplan P8 version 2.8 en 2018, la maison-mère arrête officiellement le support et la conversion des projets de l'époque Eplan 5 (1984-2006).
Ce qui signifie que le vieux format devient un gros boulet qui freine voire empèche de nouvelles fonctionnalités (ou mêmes des simplifications qui seraient bienvenues) de voir le jour. Il est donc purement et simplement abandonner après 12 ans pendant lesquelles les utilisateurs avaient la possibilité d'upgrader leurs anciens plans.
Voilà... Il aura fallu 12 ans à QET pour apprendre de ses erreurs de jeunesse. Entre les premières lignes de code de Xavier-l'étudiant-en-informatique aux fonctionnalités pro écrites par Joshua-l'électricien-de-maintenance-qui-maîtrise-bientôt-Qt... Sans compter tous les hacks et améliorations réalisées par Laurent.
Aujourd'hui on en est là et je trouve très bien que Joshua pose ouvertement la question :
faut-il rester éternellement retro-compatible ou non ?
Ça ne serait pas un vrai fork à proprement parlé pour ainsi dire afin ne pas perdre nos utilisateurs et contributeurs, on conserverait le nom mais il évoluerai en version 1.0, le travail continuerai sur notre forge dans le trunk comme d'habitude, la version précédente étant placée sous une nouvelle branche du Subversion pour d’éventuelles corrections de bug.
La rétrocompatibilité serait possible en passant par un outil dédié sans complexifier et alourdir le code de QET.
Mais on n'en est encore loin.
Revision: 5822
Author: blacksun
Date: 2019-04-02 23:01:52 +0200 (Tue, 02 Apr 2019)
Log Message:
-----------
Fix crash
https://qelectrotech.org/bugtracker/view.php?id=168
J'ai essayé de la passer en v0.7-dev pour pouvoir profiter des derniéres fonctionnalités et notamment le chercher/remplacer très pratique dans les gros projets. Et ben j'ai failli m'arracher les cheveux quand j'ai réalisé le travail que je devais accomplir pour upgrader tout le projet à la v0.7-dev. Donc je me suis contenter de sortir l'appimage v0.61, d'ouvrir le projet et de réaliser les modifications pour lesquelles mon client me paye.
Ce projet ne sera donc vraisemblablement jamais édité avec une version supérieure à la v0.61.
Evidemment, si ce projet ne faisait que 15 folios, ce serait assez rapide de l'upgrader, mais là, 150 folios, personne ne paiera le travail nécessaire.
Çà se fait, je l'avais fait pour mon projet "Parc a bois" si tu te souviens ce n'est pas un petit projet ...113 folios, ça a quand nécessité environ 3 bonnes heures de travail assez pénible et de nombreuses crampes dans les doigts ... pour ré afficher les commentaires disparus avec l'arrivé des textes dynamiques.
Mais de l'autre coté j'ai pu en 2 minutes déplacer tous mes textes de conducteurs placés avant par défaut sous les conducteurs en haut, et de droite à gauche juste en éditant le XML pour les textes non déplacés manuellement lors de la pose, le peu restant s'est avéré rapide a déplacer..
Tip : on 0.7-dev you have new options for choose conductors texts positions, if you want to move all default conductors text drawn with old version to top and left position to conductors.
Open your project on a text editor, or use sed on linux and replace all items :
vertical-alignment="AlignRight" by vertical-alignment="AlignLeft"
horizontal-alignment="AlignBottom" by horizontal-alignment="AlignTop"
Libre ensuite d’améliorer la présentation de tous mes textes, on peut faire ce que l'on veut maintenant avec les textes dynamiques, police, taille, couleur, longueur, orientation, groupement, etc, rajouter modifier des textes sur des éléments sans devoir re passer par la case éditeur, le search and replace, etc.
La perte de temps engendrée lors de la conversion sera grandement payante si je dois retoucher en profondeur ce projet dans le futur..
Revision: 5823
Author: blacksun
Date: 2019-04-03 18:06:21 +0200 (Wed, 03 Apr 2019)
Log Message:
-----------
Fix : when create multiple conductors with the free hand selection, the checking of existing potentiel don't search trought a folio report.
Moi, ce qui m'inquiète pour le futur de Qelectrotech c'est le "bus factor" proche de 1 ou 2.
Comment l'augmenter ?
Joshua, est-ce que les fonctionnalités que tu recherches, ne-sont-elles pas dans le logiciel FreeCAD ? (SVG, DXF, format de fichier type zip, langages : C++, Python, Qt,...)
Peut-être qu'un rapprochement avec cette communauté serait bénéfique.
FreeCAD fonctionne par "Workbench", il pourrait y avoir un workbench indépendant Qelectrotech.
Qu'en pensez-vous ?
Edit :
Workbench intéressant : FreeCAD-Reporting (SQL Like Reporting for FreeCAD Documents)
Oui le bus factor est très faible, mais comment l'augmenter ?
Il n'y a pas vraiment grand chose à faire, besoins de contributeurs C++.
Pour info depuis les débuts de qet ça à toujours été le cas, je dit pas que c'est top mais c'est ainsi.
Pour le rapprochement avec freecad, c'est un modeleur mécanique 3D, pas vraiment proche de l'elec...
De ce que j'ai pu lire, Kicad ses rapproché de freecad, non pas pour être incorporé mais pour créer une passerelle entre les deux soft pour la représentation 3D des cartes.
De plus bien que proposant un statue intermédiaire entre logiciel basique et pro, les sources de qet sont déjà conséquente. Autant dire que si on voulaient s’intégrer dans un autre soft, cela reviendrai à repartir de zéro.
En revanche un avenirs (lointain ?) avec une passerelle entre qet et freecad par le biais d'un workbench et quelques script python afin de crée le rendu 3D d'une armoire peut être possible.
Puisque on est en train de parler du format svg, il y a aussi quelque chose à laquelle je pense depuis un petit moment.
Alors c'est un truc qui aurais été possible avec le format actuel (.elmt) mais ce format n'a pas été pensé pour (et serais donc une sorte de rustine si devais être implémenté).
Avec la création d'un nouveau format (.selmt ?) ce 'truc' peut être pensé dès la conception.
Allé trêve de bavardage
Avoir plusieurs représentation graphique d'un même élément.
Je m'explique :
Vous créez un élément contacte, ensuite vous lui crée plusieurs 'apparence' ouvert, fermé, ouvert tempo travail, fermé tempo travail etc...
Pour chaque apparence les propriétés changeront, pour un contacte les numéro de bornes changeront mais aussi le type (tempo, NC, NO etc....) les informations etc....
Ensuite sur l'éditeur de schéma vous posez votre élément puis dans les propriétés de celui il y aura la possibilité de changer d'élément (oui car au final ce n'est pas que l'apparence mais toutes les propriétés qui vont avec, donc pour résumer, ce qui définit un élément).
Les deux seul contrainte serais les bornes qui devront resté au même nombre, le changement du nombres de bornes risque d'être complexe à gérer, et la seconde l'emplacement des bornes (et encore celui-ci j'en suis pas sure), bon au vue des possibilités les contraintes me semble mineurs.
Bien entendue j'ai pris en exemple un contacte mais ça peut être n'importe quoi d'autre.
-Une carte automate, de nombreux constructeur crée des cartes rackable ayant la même taille le même nombre de bornes...
-Un capteur, changer facilement entre inductif, capacitif, ultrason etc...
Bref voila une des nombreuses idée que j'ai (quand je dit que je pourrais bosser des année sur qet tellement j'ai d'idées).
Comme dit au début ce n'est pas le fait de passer au svg qui permettra ça, mais bien de revoir le format de fichier .elmt
Après l'utilité de la chose, je vous laisse juger (Dans tous les cas, le format de fichier sera pensé pour afin de ne pas fermer la porte).
Bonjour. Moi je vote pour le SVG car je suis enseignant et j'utilise un peu qet pour des petits schémas avec mes élèves. Mais s'utilise également le SVG pour réaliser des animations en htlm et js. Donc j'imagine très bien les petites animations de fonctionnement que je pourrais faire pour mes élèves sans devoir redessiner le schéma sous un éditeur SVG. Bravo pour les projets.
@ Joshua :
Tes idées sont très bien. Pratiques, bien pensées et, après une phase de tests, très bien implémentées également.
Seulement voilà, s'il faut refaire une partie de QET, autant que la PRIORITÉ soit mise sur les fonctionalités DE BASE attendues pour un éditeur de schémas électrotechniques.
Et ces fonctionalités DE BASE sont principalement toutes les opérations de post-traitement demandées par tous les pros :
- éditions de nomenclature (intégrée au projet, pas seulement export csv)
- plans de borniers
- listes des câbles
- listes de filerie
- listes d'entrées/sorties d'automate
- etc.
Bref... A force de faire l'impasse sur ces choses DE BASE, utiliser QET va bientôt être comparable à acheter une grosse Benz de luxe, magnifique à tous points de vue mais pas très pratique à l'usage car la boîte de vitesse n'a qu'un seul rapport 
Alors la voiture plafonne à 55km/h maximum dans un boucand d'enfer 
A part ca, la voiture est vraiment super : confortable, spacieuse, luxueuse... 
Donc, tant qu'à repenser une grosse partie du code, autant définir tout de suite précisément dans quelle direction il faut aller.
Après, moi je trouve les propositions concernant le svg, la passerelle vers FreeCAD pour les mises en armoire, le format projet en archive compressée... Tout ca c'est très bon, mais c'est peut-être pas la prio n° 1.
T’inquiète pas, si je parle de tout ça c'est que Laurent avais évoqué le svg pour la 0,8 mais j'ai bien précisé que ce ne serais pas le cas pour la 0,8. Et comme je disais quelque post plus haut
Je comprend bien que c'est dommage, mais je peut pas me permettre pendant 6 mois d'apprendre le format dxf (et donc stoppé le dev de Qet, et j'avoue que ça me botte pas non plus) alors qu'il reste une quantité astronomique de chose à apporter à Qet ( et ça, sa me botte
Je comptais en faire un pour la 0.8 peut être en passant par framform histoire que la prochaine grosse fonctionnalité soit profitable au plus grand nombre.
Donc oui je parle de tout ça car ce sont des choses qui me trotte dans le tête, mais pour la 0,8 (et sûrement les autres aussi) c'est vous qui choisirez la grosse fonctionnalité à venir.
Donc oui je parle de tout ça car ce sont des choses qui me trotte dans le tête, mais pour la 0,8 (et sûrement les autres aussi) c'est vous qui choisirez la grosse fonctionnalité à venir.
On peut ouvrir un vote pour la grosse fonctionnalités de la 0.8 ?
@ Joshua :
Je suis entièrement d'accord avec Nuri.
Nous ne pouvons pas créer de listes pour le moment.
- éditions de nomenclature (intégrée au projet, pas seulement export csv)
- plans de borniers
- listes des câbles
- listes de filerie
- listes d'entrées/sorties d'automate
- etc.
En tant que constructeur, vous avez besoin de ces listes.
C'est un problème qui dure depuis 2 ans.
Voir ma réponse le 2017-02-20 23:53:34 Re: Ideas to solve Terminal Blocks creation
Voir mon topic l’éditeur d’élément
svg pour les enseignants
Je préfère csv pour le fichier d'élément.
Erik
On peut ouvrir un vote pour la grosse fonctionnalités de la 0.8 ?
https://qelectrotech.org/forum/viewtopic.php?id=1382
https://www.leetchi.com/c/qelectroteck
Bonjour, FYI, le dépôt MXE de Vincent de l'equipe Kdenlive https://github.com/vpinon/mxe ne semble plus maintenu, ils sont d'ailleurs passé sur une autre façon de porter leur application sur Windows https://kdenlive.org/en/2019/01/buildin … s-and-mac/ avec KDE Craft package manager.
J'ai donc du étudier une autre solution en utilisant les scripts MXE de Gilles de l’équipe Digikam https://github.com/KDE/digikam/tree/mas … undles/mxe basé sur le dépôt MXE master.
Mes premiers essais semblent concluants, paquet 64 bits bien plus léger, et aussi bien plus fluide il me semble, hélas ces essais nécessite de longues heures pour compiler ces environnements et l'on doit recommencer souvent pour la mise au point.
Certains utilisent encore des machines et des Windows 32 bits?, ça m’allégerait de ne plus supporter cet environnement.
Vous pouvez aussi nous aider dans le renouvellement de la builder machine, machine qui produit tous les paquets sur tous les OS.
https://www.leetchi.com/c/qelectroteck
Malheureusement au travail je suis en 32bits encore.....
J'ai peur hélas que tu ne sois pas le seul, j'ai donc lancé la construction de l'environnement i686-w64-mingw32 Qt5 + Kdeframework sur la machine, faudra attendre demain voir si tout c'est compilé sans erreur, et commencer les premiers essais.
Malheureusement, en entreprises le renouvellement du parc informatique est très lent ...
Les premiers paquets Windows sont en cours d'upload, merci de vos retours, enjoy !
Malheureusement au travail je suis en 32bits encore.....
Il me semble que cette version de la ReadyToUse dépote plus que l'ancienne version .... pour du Windows, tu l'as essayée?
Avec la 5848, je n'ai rien remarqué : le chargement de la collection est toujours de plus de 30s....
QElectroTech → News → Nouveautés de la version de développement 0.7
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.026 seconds (24% PHP - 76% DB) with 12 queries