Search options (Page 30 of 33)

Tu as juste à poser un élément de la collection officiel (collection patché avec les uuid) déjà existant dans ton projet (par ex une bobine) normalement tu devrais avoir le dialogue signalant que l'élément est déjà intégré, mais semble différent.
A cette question tu coche "écraser", ce qui aura pour effet de remplacer l'ancien élément par le nouveau (donc avec les uuid).
Fait une copie de ton projet avant quand même .

Bonjour,
Pour les questions de nuri :

1° - Il s'agit clairement d'un bug ou défaut, donc il faut que je vois cela.

2° - Pour la stabilité du dock, je ne peux pas dire aussi sûrement que Laurent, qu'il l'est. Seul les retours le rendront plus stable. (Pour info, le dock et les widgets qui sont "insérés" dedans sont deux choses distinctes, cela veut dire qu'il peut y avoir un bug dans l'édition des éléments mais pas celui des images, car ce sont deux widgets différents).
-Pour les dialogues, perso je pense les laisser pour plusieurs raisons:
*Ils sont déjà présents.
*Ils ne représentent pas une masse de code supplémentaire.
*Par expérience, il vaut mieux laisser le choix à l'utilisateur (je pense que chacun utilise qet de manière plus ou moins différente). Et je suis prêt à parier que si je les enlèves, on me demandera de les remettre.
Après il peut-être envisageable de créer une option qui désactive les dialogues quand ils existent aussi dans le dock (comme disait Laurent)

3° - Actuellement, par défaut il se trouve à droite, car:
*C'est comme ça que je l'ai codé.
*On retrouve souvent ce genre de dock (édition de la sélection) à droite dans différent logiciel. (j'ai donc suivie une pratique commune).
*C'est moi qui code, c'est moi qui commande (bon j'avoue c'est pas une bonne raison :p )
Après, savoir ou le mettre par défaut c'est un sujet probablement sans réponse, car chacun aura ça préférence.
Pour ma part, je ne propose rien pour les raisons évoquées.
De toutes manières Qt permet de poser le dock où l'on veut par la suite et c'est sauvegardé dans la conf.

J'ai pas fait attention aux check box, je m'en occupe.
Je vais aussi faire (j'ai encore pas touché au code, mais c'est bien réfléchie) le merge des undo des link/unlink élément quand c'est possible. De la même manière des info d'élément, quand on remplie les info, il n'y a qu'un seul undo (et non pas un pour chaque lettre....)

Perso,
je me voyais bien faire comme la page 1 et 3 du pdf de Nuri. Après en fonction des demandes ça peut évoluer bien entendue.
Ensuite comme à dit Nuri, il faut bien distingué deux choses.

1° la partie Data.
2° la partie graphique.

(je prend ma casquette de développeur....)
Il me faut avant tout connaître de manière claire (En d'autres mots vos attentes) toute ce qui doit figurer dans la partie data, car c'est le plus important.
Ensuite vient la partie graphique qui  est (j'exagère un peu) juste la mise en page des data, et cela vient après dans le résonnement.

Donc pour faire avancer le truc (même si c'est pas pour tout de suite) mettez à plat tout les choses correspondant à la partie data.

Laurent au sujet du plugin python rêve pas trop .....   faire des plugin C++ pourquoi pas car Qt le permet out of the box (mais faut avoir une base bien clean avec certain prérequis, enfin bref je m'égare la...) en revanche pour le python c'est pas trop le cas et je pense qu'on dépasse mes connaissances....

Cela dit l'idée est très bonnes même si c'est plutôt l'inverse au niveau du résonnement car le coté data Qet le connais donc suffit juste de fournir toutes les info au plugins, par contre le coté graphique peut être fait de plusieurs manière différente surtout au niveau des options (barrette de jonction, ajouté un ou deux bornier de plus ect....).
Et la le plugins peut être sympa car c'est lui qui ferait tout ça et il renvoie juste un pixmap qu'on intègre dans les folios.

Une dernière choses, pour moi je verrais bien les borniers en post traitement, c'est à dire pas de mise à jour lors d'une suppression/modif/déplacement (en gros ce serais juste une image, voir réellement une image).
Pour les raisons suivante.
-Gros truc et usine à gaz à codé (comparé au post traitement)
-fort risque d'erreur, en post traitement les erreurs serais toujours possible (et oui je fournis beaucoup de bug) mais très minimisé étant donné qu'on récupère les data à un moment T, donc si c'elle ci sont bien interprété et mise en page y'a pas de raison.

L’inconveniant c'est qu'il faut refaire le bornier si on touche au schéma, mais en principe on fait ça à la fin donc bon....

A+

Il s'agit bien d'un bug (de ma part )
Réglé dans la révision 3833.
Merci du retour.

Bonjours dae,
je suis l'actuel développeur de QElectroTech, à 95% (actuel car je ne suis pas le créateur du logiciel).
Comme scorpio, je travail en 2/8 et ne code que sur mes temps libre, ce qui explique le rythme de développement qui peut paraître lent.
Je vais tenter de répondre au mieux à tes questions.

Cette partie du code est à revoir, mais nous avons aussi beaucoup d'autre chose à faire.

Visiblement tu connais un peu le monde linux, donc je vais supposé que tu connais gtk et Qt, les tools kit respectif de gnome et kde.
QElectroTech est codé avec Qt. Sauf erreur de ma part (je n'ai pas cherché non plus, car tu est le premier à demander ça) Qt ne permet pas de redimensionné les icônes comme tu le souhaiterais "out the box" ce qui veut dire qu'il faudrais crée cela nous même, et ont à nettement plus urgent à coder que ça.

Qet n'a pas vocation à être un éditeur d'image (même simple) donc cela ne changera pas, en tout cas pas avant un long moment (au moins jusqu'à tout ce qui est nécessaire à l'elec pur soit crée).

La aussi je te répondrais comme la question précédente, voir pire.
Tout les format que tu mentionne ne sont pas libre, cad qu'on ne sait pas comment les lire/écrire.

Pour finir nous somme une toute petite équipe qui construit qet sur leurs temps libre et nous manquons de bras, donc nous nous concentrons sur les taches prioritaires pour la création d'un projet, au sens large du terme.
Mais nous somme toujours à l'écoute des demandes des utilisateurs (on crée beaucoup de chose que les utilisateur demande, quand cela nous écarte pas trop de la route).

En espérant avoir répondue à tes question

Hum en regardant le code, je vois que c'est un seul QString avec plusieurs saut a la ligne.
Les sauts à la ligne sont il bien respecté dans la traduction?
Pour info, un saut à la ligne est écrit comme ça : \n

Bonjour,
Il n'est pour l'instant pas possible d'importé la nomenclature dans un / plusieurs schéma.
Comme à dit scorpio810 le fichier csv est exploitable avec un tableur, et c'est à l'heure actuel l'unique moyen de crée la nomenclature avec QElectroTech.
Cela dit j'ai moi même crée un projet + nomenclature imprimé depuis libre office et mis à part le cartouche qui n'est pas présent, la nomenclature rend très bien dans le projet (une fois le tout relié ).

Le problème vient du fait que des éléments ont une position (x,y) négative.
Dans votre cas il s'agit de conducteur (je n'ai pas pris la peine regarder qui, car y'en a plusieurs).
Attention, je tient à préciser (et ici c'est le cas) ce n'est pas par ce que les éléments sont bien dessiné dans le schéma que sa position est dans le schéma.
Au final ceci n'est pas un bug, car quand on dé-zoom, on stop dès que tout est "contenue" sur l’écran, donc comme la position des conducteur est négative, on arrête dès que leurs position est "contenue" à l'écran, même si il n'y à pas de représentation graphique.

Cela s'explique, car on supprime avec les conducteurs en position négative.
Tu peut aussi supprimé puis faire un undo le comportement restera normal.

Je n'arrive à produire ton problème.
J'ai testé plusieurs schéma, avec image verrouillé et non verrouillé, debian <-> windows et je ne rencontre aucun problème.
Est tu sur d'avoir la dernière version sur les deux OS?

Bonjours le problème doit être réglé avec la rev3460 (pouvez vous le confirmé).
Attention, vous retrouverez les anciens textes seulement si vous n'avez pas sauvegardé votre schéma avec la version bugué.

Merci de vos retour.