Nouveautés de la version de développement 0.7 (Page 19 of 23)

We added KCoreAddons dependency in latest source code.

Revision: 5788
Author:   blacksun
Date:     2019-03-16 11:50:30 +0100 (Sat, 16 Mar 2019)
Log Message:
-----------
Use KAutoSaveFile for the backup system, instead of home made function.

For mainstream packagers or for compiling sources you need libkf5coreaddons-dev/kf5-kcoreaddons-devel libs.

Btw, macOS build fails with latest frameworks, 5.56 like this issue : https://github.com/KDE-mac/homebrew-kde/issues/285

t/5.12.1/lib -framework QtSvg -framework QtWidgets -framework QtGui -framework QtCore -framework DiskArbitration -framework IOKit -framework QtPrintSupport -L/usr/local/Cellar/kf5-kwidgetsaddons/5.56.0_1/lib -lKF5WidgetsAddons -framework QtNetwork -framework QtXml -framework QtSql -framework QtConcurrent -L/usr/local/Cellar/kf5-kcoreaddons/5.56.0_1/lib -lKF5CoreAddons -framework OpenGL -framework AGL   
Undefined symbols for architecture x86_64:
  "KColorButton::setColor(QColor const&)", referenced from:
      ConductorPropertiesWidget::setProperties(ConductorProperties const&) in conductorpropertieswidget.o
      ShapeGraphicsItemPropertiesWidget::updateUi() in shapegraphicsitempropertieswidget.o
      DynamicTextFieldEditor::updateForm() in dynamictextfieldeditor.o
      TextEditor::updateForm() in texteditor.o
  "KColorButton::KColorButton(QWidget*)", referenced from:
      Ui_ConductorPropertiesWidget::setupUi(QWidget*) in conductorpropertieswidget.o
      Ui_ShapeGraphicsItemPropertiesWidget::setupUi(QWidget*) in shapegraphicsitempropertieswidget.o
      Ui_DynamicTextFieldEditor::setupUi(QWidget*) in dynamictextfieldeditor.o
      Ui_TextEditor::setupUi(QWidget*) in texteditor.o
  "KAutoSaveFile::allStaleFiles(QString const&)", referenced from:
      QETApp::checkBackupFiles() in qetapp.o
  "KAutoSaveFile::KAutoSaveFile(QUrl const&, QObject*)", referenced from:
      QETProject::setFilePath(QString const&) in qetproject.o
  "KColorButton::color() const", referenced from:
      ConductorPropertiesWidget::properties() const in conductorpropertieswidget.o
      ShapeGraphicsItemPropertiesWidget::associatedUndo() const in shapegraphicsitempropertieswidget.o
  "KAutoSaveFile::managedFile() const", referenced from:
      QETApp::checkBackupFiles() in qetapp.o
      QETDiagramEditor::openBackupFiles(QList<KAutoSaveFile*>) in qetdiagrameditor.o
      QETProject::QETProject(KAutoSaveFile*, QObject*) in qetproject.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [qelectrotech.app/Contents/MacOS/qelectrotech] Error 1

Btw, backup files is stored on ~.local/share/stalefiles/QElectroTech on Linux.
C:\Users\username\AppData\Local\stalefiles\QElectroTech on Windows
/Users/username/Library/Application Support/stalefiles/QElectroTech/ on macOS
 

Cool !

Les crashs lors de l'export DXF sont  provoqués par les pages sommaires, il suffit de les décocher ou les supprimer et les re générer avant l'export.

C'est pas mieux pour les textes des éléments, en plus de quelques bizarreries .... A mon avis, vaut mieux désactiver la fonction ....

Nous y voila, c'est la dernière ligne droite avant une RC1 de QET 0.7,
Il n'y aura donc plus de nouvelle fonctionnalité (même mineur), en revanche il est encore temp de faire remonter les petits défauts et/ou modifications pouvant être apportées aux nouveautés de cette version, durant la période de RC, afin d'avoir une version 0.7 la mieux finie possible.

Oui effectivement, il faut que je regarde un peu ça.
Je dit 'un peu' car c'est du code qui n'est plus maintenue par la personne qui l'a crée, et je n'ai pas le temps (et j'avoue pas trop l'envie) d'apprendre le dxf.
Donc ce sera uniquement de la correction si besoin, mais en aucun cas du nouveau code.
L'export en dxf est donc expérimental à partir de QET 0.7 et le restera faute de mainteneur.

Je trouve dommage de lancer une ""version stable" avec une fonctionnalité qui reste boiteuse.
Dans l'usine où je travaille, le dwg/dxf en schéma élec est le standard, mais c'est en train d'évoluer.

C'est dommage, mais je comprends...
Qu'est devenu le développeur de cette partie ?

On ne le sait pas encore, mais Joshua aimerai faire une refonte du code en profondeur,  ce serait un nouveau logiciel avec des éléments au format SVG, et qui serait incompatible avec vos anciens projets.

Création d’éléments facilitée par d'autres logiciels, plus besoin de passer par le convertisseur DXF->elmt pour les éléments complexes.

Je suis d'accord la dessus, après il est facile de switcher de version avec les ReadyToUse sous Windows, les dmg sous macOS, et les AppImages sous Linux.

Oui c'est un truc que j'aimerais faire, mais ça ne sera pas pour la 0.8.

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.

En revanche pour le svg il n'y aura pas de sondage, ce sera imposé mais voici quelque explications:

à la base le format de fichier des éléments est très proche du svg, puis avec le temps il l'est devenue de moins en moins....
Avec le recule et l'expérience (si je peut me permettre) je me rend compte que c'est une grosse erreur, pourquoi réinventer la roue (notre propre format) alors qu'une belle roue qui dispose de plus de fonctionnalité que nous en avons besoins existe et en plus est standardisé (svg).
Le xml dispose d'un système d’espace de nom, qui pour résumer permet d'inclure plusieurs norme xml (le svg par ex) au sein d'un même fichier xml. Ainsi le fichier .elmt aurai deux parties : un sous ensemble 100% svg et un autre propre à qet (borne, texte dynamique, info d'élément etc....).

Pour moi en tant que dev ça m'arrange bien la vie car :
-Si un jour je veut ajouter un nouveau truc graphique, par exemple une courbe de Bézier, le format svg possède déjà tout ce qu'il faut pour enregistrer ça, pas besoins de réinventer la roue qui en plus sera probablement moins bien que ce que propose le svg (c'est du vécu).
-Réduction du code coté éditeur de schéma, actuellement on parse le fichier .elmt pour créer toute la partie graphique. Avec le sous ensemble svg pas besoins, Qt possède déjà tout ce qu'il faut il me suffit de donner à la bonne classe le bout de svg puis il me ressort l'image de l'élément.
-Mélange des deux précédents : Avec le format actuel si j'ajoute une courbe de bezier, je suis obligé dans l'éditeur de schéma de codé un truc pour faire le rendu de la courbe depuis la description xml, alors qu'avec le svg, ba absolument rien à faire je donnerais toujours mon bout de svg à Qt qui lui me ressortira tout comme il faut.

Pour vous en tant qu'utilisateur.
-Format standard et ouvert, cad que vous pouvez créer/récupérer un svg puis l'importé directement dans l'éditeur d'élément tout simplement, pas de bidouille ou hack tordu à la scorpio .
Bon attention si vous importez un truc de ouf genre ça il est évident qu'il n'en sortira rien, ce sera une implémentation basique du svg (uniquement ce qui est utile à qet), on code pas un éditeur svg , mais je resterais ouvert par exemple si un truc sympa existe en svg, mais pas dans qet de l'implémenter.
-Sur le net il existe une multitude de convertisseur dxf -> svg.
-Redimensionnement, c'est pas prévu, mais pas exclu non plus car svg est prévu pour (cas concret de l'avantage d'utilisé un format standard).
-De l'animation, encore une fois pas prévu, mais svg sait le faire.

Mais tout cela est une partie d'un chantier beaucoup plus gros dont entre autre un nouveau format de fichier pour les projet (.qet) qui serais en fait une archive zip.
Encore une fois je ne vais pas faire la liste des avantages, mais il y en a pas mal et ça ouvre la porte sur beaucoup d'autre chose.
Bien entendue cela représente une bonne quantité de code à ajouter et modifier, et ce serais donc le bon moment pour faire une refonte sur des truc tordue que l'on traine depuis un moment (bonjours les couches de rétrocompatibilité) qui pollue le code.
Tout ça, ce sont des choses que je voie avec le recule et l'expérience (si je peut me permettre encore une fois) qui à mon avis seront nécessaire un jour ou l'autre.
Tout ça mènerais à un fork de QET (et donc l’abandon de QET), afin de repartir sur un nouveau logiciel et surtout un nouveau format de fichier mieux réfléchie.

Bon je vais m’arrêter la, le post est déjà bien assez long, et je pourrais écrire un romans sur tout les idées que j'ai vis à vis de qet.