Re: Sommaire

Nuri, je te dégrossi vite fait une partie du code, pour que tu puisses comprendre .

https://svnweb.tuxfamily.org/filedetail … p;peg=4627




qreal DiagramFolioList::colWidths[8] = {0.05, 0.05, 0.45, 0.10, 0.10, 0.05, 0.10, 0.10};


Création du tableau et largeur de chacune des 8 colonnes.




int cols = 8;//colWidths.size();



fillRow(p, row_rect, diagram_list[i] -> border_and_titleblock.author(),


diagram_list[i] -> title(),


QString::number(diagram_list[i] ->folioIndex()+1),


diagram_list[i] -> border_and_titleblock.folio(),


diagram_list[i] -> border_and_titleblock.machine(),


diagram_list[i] -> border_and_titleblock.locmach(),


diagram_list[i] -> border_and_titleblock.indexrev(),


diagram_list[i] -> border_and_titleblock.date().toString(Qt::SystemLocaleShortDate));


Nos constantes dont on va rechercher les valeurs.





// reduce the font size if the text entry is long


if (origFontMetrics.width(folio) > 0.95*colWidths[0]*row_rect.width())


workingFont.setPointSizeF(origFontSize * 0.95*colWidths[0]*row_rect.width() / origFontMetrics.width(folio));


else


workingFont.setPointSizeF(origFontSize);


qp -> setFont(workingFont);


qp -> drawText(QRectF(x, y, colWidths[0]*row_rect.width(), row_rect.height()), Qt::AlignCenter, folio);


x += colWidths[0]*row_rect.width();


Pour chaque constante tu affiches ou réduit la taille de police, entre les [] tu affectes ta constante à une colonne, ici c'est la constante folio qu'on affiche dans la colonne 1 (car on commence toujours à zéro!)

qp->setFont(QETApp::diagramTextsFont(13));

Taille de police d'origine.



qreal sum = 0;


for (int i = 0; i < 8; i++ )


sum += colWidths[i];


if ( sum < 0.99 || sum > 1.01 ) {


qDebug() << "Invalid input: Column widths do not sum to 1";


return;


}


On ajoute un controle pour que la largeur des colonnes soient compris dans cette fourchette, et donc quelles ne dépassent pas du tableau.




int startDiagram = id * 29;


for (int i = startDiagram; i < startDiagram+29 && i < diagram_list.size(); ++i) {


Chaque tableau contiendra 29 lignes, si le nombre de folios dépassent ce nombre, tu crées autant de tableaux.




--- trunk/sources/qetproject.cpp 2016-08-10 16:48:18 UTC (rev 4621)
+++ trunk/sources/qetproject.cpp 2016-08-11 18:32:08 UTC (rev 4622)
@@ -1039,7 +1039,7 @@
  setFolioSheetsQuantity(0);
 
  int diagCount = diagrams().size();
- for (int i = 0; i <= diagCount/58; i++) {
+ for (int i = 0; i <= diagCount/29; i++) {
 
  //create new diagram
  Diagram *diagram_folio_list = new DiagramFolioList(this);

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

oui, vu comme ca, c'est plus nomicons/happy que nomicons/alien

donc pour rendre cela personnalisable, il faut faire une "abstraction" de ce code pour prendre les nouvelles variables définies par l'utilisateur (largeurs, textes, types de colonnes, etc), alors que là, tout est en dur.
Puis, avec QtDesigner, faut faire la GUI à intégrer à la config projet pour que l'utilisateur puisse définir ses tableaux...
Puis faut faire le code de la nouvelle GUI pour que les éléments (boutons, champs texte, listes déroulantes, etc) fonctionnent correctement...
Puis faut relier les nouveaux éléments de la GUI dans ce code... et dans l'interface globale...
Puis faut intégrer tout ca joliment dans le code existant sans créer de nouveaux bugs... donc il faut comprendre le code existant...
Et à la fin, il faut que ca compile et que ca marche comme prévu !

Waouh.... franchement, vu mes connaissances et le temps disponible, je suis pas très chaud !

Tu saurais faire ca, toi, sans y passer 200 heures ?

Re: Sommaire

Çà risque d’être compliqué sans ré-écrire une grosse partie de ce code.

Post's attachments

Attachment icon 00010.patch 3.51 kb, 377 downloads since 2016-08-15 

sommaire1.png, 17.73 kb, 864 x 642
sommaire1.png 17.73 kb, 411 downloads since 2016-08-15 

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

scorpio810 wrote:

Revision: 4626
Author:   scorpio810
Date:     2016-08-12 13:32:56 +0200 (Fri, 12 Aug 2016)
Log Message:
-----------
Titleblock properties rename property %loc to %locmach

@Galexis, Nuri :
Çà vous intéressent d'avoir %machine et %locmach dans les règles de num des éléments?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

scorpio810 wrote:

Çà vous intéressent d'avoir %machine et %locmach dans les règles de num des éléments?

A priori non car = et + n'ont rien à faire dans le label si on s'en tient strictement à la norme.
Toutefois, je vois pas pourquoi il faudrait limiter QET si c'est une implémentation aisée à réaliser.
D'une manière générale, plus on peut utiliser les variables et les appeler à peu près n'importe où, mieux c'est nomicons/smile
Je pense par exemple à l'utilisation des variables dans les champs texte (ceux qui gèrent aussi le html, dans la même tool bar que les basic shapes).

scorpio810 wrote:

Çà risque d’être compliqué sans ré-écrire une grosse partie de ce code.

il s'agit donc bien de réinventer la roue...

Re: Sommaire

Toutefois, je vois pas pourquoi il faudrait limiter QET si c'est une implémentation aisée à réaliser.

Le patch était prêt, donc autant l'envoyer. nomicons/grin
Et je suis certain que certains auraient demandé à l'avoir.


Revision: 4628
Author:   scorpio810
Date:     2016-08-16 15:43:46 +0200 (Tue, 16 Aug 2016)
Log Message:
-----------
New fields titleblock properties %machine and %locmach can now be called
in the element rules autonum

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

il s'agit donc bien de réinventer la roue...

Peut-être pas !
Là ou tu as des constantes style [8] ça peut-être une variable dynamique ou tu comptes les colonnes demandées par l'utilisateur.

La largeur de chaque colonne tu peux aussi les récupérer depuis le Widget, etc.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

Serait-il possible que les propriétés du sommaire soit sauvegardées dans le projet ? C'est relativement pénible de devoir retaper fichier, indice, auteur, ... à chaque fois qu'on lance une impression.

Post's attachments

Capture du 2016-08-16 18-23-58.png, 12.83 kb, 528 x 267
Capture du 2016-08-16 18-23-58.png 12.83 kb, 399 downloads since 2016-08-16 

Re: Sommaire

scorpio810 wrote:

Toutefois, je vois pas pourquoi il faudrait limiter QET si c'est une implémentation aisée à réaliser.

Le patch était prêt, donc autant l'envoyer. nomicons/grin
Et je suis certain que certains auraient demandé à l'avoir.


Revision: 4628
Author:   scorpio810
Date:     2016-08-16 15:43:46 +0200 (Tue, 16 Aug 2016)
Log Message:
-----------
New fields titleblock properties %machine and %locmach can now be called
in the element rules autonum

Je suis un peu d'accord avec Nuri: je n'en vois l'utilité immédiatement, mais pourquoi se limiter !

86 (edited by galexis 2016-08-16 18:48:12)

Re: Sommaire

scorpio810 wrote:
scorpio810 wrote:

Revision: 4626
Author:   scorpio810
Date:     2016-08-12 13:32:56 +0200 (Fri, 12 Aug 2016)
Log Message:
-----------
Titleblock properties rename property %loc to %locmach

@Galexis, Nuri :
Çà vous intéressent d'avoir %machine et %locmach dans les règles de num des éléments?

Je pense qu'il serait intéressant de pouvoir ajouter aux règles/système de numérotation auto de folio ces informations: machine, localisation, auteur.
Car avec les +-, Nuri nomicons/grin va devoir créer des groupes de folio par sous-ensembles, exemple :
- 10 folios de 1 à 10 de localisation =enrouleur
- 15 folios de +F1 à +F15 de localisation =GR01.
Qu'en pensez-vous ?

Re: Sommaire

Bah, suffit dans projet de renseigner les champs propriétés du cartouche et ensuite de générer tes - 10 folios de 1 à 10 de localisation =enrouleur
Tu modifies ensuite tes champs propriétés du cartouche et tu génères les suivant, non?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

Oui, effectivement, on peut le faire comme ça.

Re: Sommaire

A priori non car = et + n'ont rien à faire dans le label si on s'en tient strictement à la norme.

Me semblai bien avoir compris l'inverse dans tes docs, faudra que je les potasse à nouveau. nomicons/cool

https://download.qelectrotech.org/qet/n … ucture.odp

https://download.qelectrotech.org/qet/forum_img/foliolistlabel8.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

scorpio810 wrote:

A priori non car = et + n'ont rien à faire dans le label si on s'en tient strictement à la norme.

Me semblai bien avoir compris l'inverse dans tes docs, faudra que je les potasse à nouveau. nomicons/cool

https://download.qelectrotech.org/qet/n … ucture.odp

https://download.qelectrotech.org/qet/forum_img/foliolistlabel8.png

C'est là où le champ localisation intervient, non ? Et c'est aussi pour cela qu'on disait que la localisation était lié au label et non pas au Xref. Voir précédemment : https://qelectrotech.org/forum/viewtopi … 5141#p5141

Re: Sommaire

On peut utiliser les variables %M (machine/installation) et %LM (localisation machine) dans les renvois de folio, et aussi dans les XREF sur les contacts esclave seulement.

https://download.qelectrotech.org/qet/forum_img/foliolistlabel9.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

Revision: 4632
Author:   scorpio810
Date:     2016-08-17 08:04:37 +0200 (Wed, 17 Aug 2016)
Log Message:
-----------
Variable properties %M (machine/plant) et %LM (location plant)
can now be called in the xref propertie widget (run now for slave and
master)

Dessiner facilement des schémas à la norme IEC 81346 devraient être bien plus facile, non?...nomicons/ninja
@Nuri : à y être, tu verrais d'autres propriétés à ajouter comme .... fonction?
Pour l'autonum des conducteurs les variables par défaut sont suffisantes pour moi, et vous, vous en pensez quoi?

https://download.qelectrotech.org/qet/forum_img/foliolistlabel10.png

Pour Galexis: nomicons/grin

https://download.qelectrotech.org/qet/forum_img/foliolistlabel11.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

galexis wrote:

Serait-il possible que les propriétés du sommaire soit sauvegardées dans le projet ? C'est relativement pénible de devoir retaper fichier, indice, auteur, ... à chaque fois qu'on lance une impression.

Je comprend pas, si tu as renseigné tes propriétés de cartouche, alors ils seront sauvegardé dans les pages sommaire, tu auras juste le label de folio à renseigner avant l'impression.
Quand tu génères le sommaire il vient lire les propriétés actuelles du cartouche renseignées dans l'onglet nouveau folio.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

94 (edited by Nuri 2016-08-17 10:46:09)

Re: Sommaire

scorpio810 wrote:

Me semblai bien avoir compris l'inverse dans tes docs, faudra que je les potasse à nouveau

Les 3 informations (=, +, -) doivent être renseignées dans des champs distincts.
Il ne faut donc pas faire comme cela :
https://download.qelectrotech.org/qet/forum_img/nuri_img002.png
Peu importe si l'utilisateur emploie des variables ou écrit directement, il ne faut pas faire comme ca !
C'est ce que je voulais dire avec "= et + n'ont rien à faire dans le champ label".

L'idéal serait d'avoir le widget "propriétés de la sélection" comme ceci :
https://download.qelectrotech.org/qet/forum_img/nuri_img001.png

scorpio810 wrote:

Bah, suffit dans projet de renseigner les champs propriétés du cartouche et ensuite de générer tes - 10 folios de 1 à 10 de localisation =enrouleur
Tu modifies ensuite tes champs propriétés du cartouche et tu génères les suivant, non?

oui, il me semble que ca devrait suffir pour l'instant. Mais j'ai pas encore assez testé, à voir.

scorpio810 wrote:

Dessiner facilement des schémas à la norme IEC 81346 devraient être bien plus facile, non?

oui, en tout cas bien plus facile qu'il y a 6 mois, même si tout n'est pas encore terminé et testé de fond en comble.

scorpio810 wrote:

@Nuri : à y être, tu verrais d'autres propriétés à ajouter comme .... fonction?

Pour mettre dans les Xref de renvois de folio ? Perso non, pas besoin, puisque je référence uniquement sur l'identification des folios (càd les infos =, + et id ou autonum renseignées dans les cartouches). Je connais pas d'autre système et j'en ai jamais vu d'autres.

scorpio810 wrote:

Pour l'autonum des conducteurs les variables par défaut sont suffisantes pour moi, et vous, vous en pensez quoi?

Pour moi, l'existant suffit déjà amplement, mais je suis sûrement pas un bon conseil pour l'autonum des conducteurs vu que c'est quasiment pas employé en Allemagne.

Re: Sommaire

nuri wrote:

Peu importe si l'utilisateur emploie des variables ou écrit directement, il ne faut pas faire comme ca !
C'est ce que je voulais dire avec "= et + n'ont rien à faire dans le champ label".
L'idéal serait d'avoir le widget "propriétés de la sélection" comme ceci :

Heuu, là tu nous compliques beaucoup la vie  d'un coup nomicons/getlost, et ça va à contre sens des commits de Davi et des miens.
Je pense qu'il te faudra t'y habituer et faire Label = %M-%LM-M1, et même si je pense que tu as raison et que c'est bien plus logique, le code ne se change pas en trois coups de cuillère à pot. nomicons/smile



nuri wrote:
scorpio810 wrote:

@Nuri : à y être, tu verrais d'autres propriétés à ajouter comme .... [s]fonction[/s]?

Pour mettre dans les Xref de renvois de folio ? Perso non, pas besoin, puisque je référence uniquement sur l'identification des folios (càd les infos =, + et id ou autonum renseignées dans les cartouches). Je connais pas d'autre système et j'en ai jamais vu d'autres.

Je pensai surtout aux propriétés cartouche, tu vois d'autres champ à ajouter, tant qu'on y est?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

scorpio810 wrote:
nuri wrote:

Peu importe si l'utilisateur emploie des variables ou écrit directement, il ne faut pas faire comme ca !
C'est ce que je voulais dire avec "= et + n'ont rien à faire dans le champ label".
L'idéal serait d'avoir le widget "propriétés de la sélection" comme ceci :

Heuu, là tu nous compliques beaucoup la vie  d'un coup nomicons/getlost, et ça va à contre sens des commits de Davi et des miens.
Je pense qu'il te faudra t'y habituer et faire Label = %M-%LM-M1, et même si je pense que tu as raison et que c'est bien plus logique, le code ne se change pas en trois coups de cuillère à pot. nomicons/smile

Ba pour le coup, vous avez inclue énormément de variable Davi et toi (ce qui est bien).
Mais pour l'histoire des + =, comme je l'avais déjà expliqué cela sera géré par le projet lui même (pas les folios ni les cartouches).
Ainsi si un folio se trouve être dans =G01 +L01, il va de soi que tout les éléments présent dans ce folio le sont aussi (ce qui rend les choses nettement plus rapide que de renseigner individuellement chaque éléments) à l'exception des éléments appartenant à une autre localisation, qui seront déterminé explicitement, par exemple en les entourant d'un cadre.
Du fait, une fois ce système mis en place les actuelles variables de localisation seront inutile (à moins de changer leurs comportement, et d'aller chercher directement les info dans le nouveau système).

Développeur QElectroTech

Re: Sommaire

Clair, et comme c'est pas prévu pour demain ni dans trois mois, ça a au moins le mérite de faire le travail en attendant (ce qui est bien). nomicons/smile

D'ailleurs je pense que je peux bientôt préparer le tag d'une version beta.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Sommaire

Je pense que l'approche de Joshua est excellente.
Les infos = et + des éléments doivent prendre directement celles du folio, ca va beaucoup plus vite et c'est de toute facon dans ce sens là que la norme fonctionne.
Ensuite, pour les exceptions, c'est comme Joshua le décrit :
soit on renseigne directement dans les propriétés de l'élément, soit on dessine un rectangle qui donne ses propriétés = et + aux éléments qu'il contient.

Joshua wrote:

Mais pour l'histoire des + =, comme je l'avais déjà expliqué cela sera géré par le projet lui même (pas les folios ni les cartouches).

oui, comme ca ce sera aussi beaucoup plus cohérent, notamment pour afficher le projet sous forme d'arborescence.

Joshua wrote:

Du fait, une fois ce système mis en place les actuelles variables de localisation seront inutile

C'est pas plus mal, car ca commence à être un peu confu. Mais je sais bien que QET se trouve maintenant à un tournant important et il faut bien tester et essayer avant de se fixer sur une solution définitive.

scorpio810 wrote:

Clair, et comme c'est pas prévu pour demain ni dans trois mois

Qui sait... On les avait pas vu venir les variables qui aujourd'hui semblent déjà indispensables !

Re: Sommaire

Quand l'utilisateur va déplacer un folio ou des folios dans l'arbre =,+,- sur le nouveau système, les variables vont surement suivre, mais le résultat risque de ne pas être celui escompter et être surement source d'erreurs, et donc un sacré bazar?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

100 (edited by galexis 2016-08-18 19:19:07)

Re: Sommaire

scorpio810 wrote:
galexis wrote:

Serait-il possible que les propriétés du sommaire soit sauvegardées dans le projet ? C'est relativement pénible de devoir retaper fichier, indice, auteur, ... à chaque fois qu'on lance une impression.

Je comprend pas, si tu as renseigné tes propriétés de cartouche, alors ils seront sauvegardé dans les pages sommaire, tu auras juste le label de folio à renseigner avant l'impression.
Quand tu génères le sommaire il vient lire les propriétés actuelles du cartouche renseignées dans l'onglet nouveau folio.

Pour moi, les paramètres du folio par défaut non pas de rapport avec le sommaire et devrait être disssocié.
Les folios par défaut ne doivent pas s'appeler "sommaire" ou "liste de folio", peuvent avoir un indice différent de celui paramétré et ne doivent pas avoir un label du genre "SOM".
Mais effectivement, c'est une manière de s'en sortir. La définition du folio par défaut sert du coup à :
- folio par défaut
- définition du cartouche
- création de folio en rafale avec le système de règle.
Je trouve du coup ce panneau plus trop cohérent depuis les dernières évolutions (localisation, machine, indice, règle auto).


Nuri a écrit:

scorpio810 a écrit:Pour l'autonum des conducteurs les variables par défaut sont suffisantes pour moi, et vous, vous en pensez quoi?

Pour moi, l'existant suffit déjà amplement, mais je suis sûrement pas un bon conseil pour l'autonum des conducteurs vu que c'est quasiment pas employé en Allemagne.

Des fournisseurs allemand nous ont proposé pour une machine, des repères alliant entre autre les numéros de la bornes du matériel (A1, A2, 13, 14, ...).