Si, ça a été lu. Le bug 40 sera traité en son temps. Le bug 39 n'étant pas clair et  sous-entendant surtout que tu as une mauvaise imprimante, ça ne risque pas d'être traité de manière prioritaire...
Conseil : pour ce genre de problèmes, démontrer le problème avec une impression sur une imprimante virtuelle PDF (y'en a une dans Cups, elle génère ses impression dans ~/PDF) : ça blâme forcément le logiciel au détriment du matériel. Si par hasard tu sous-entendais dans le bug 39 que ça irait mieux en réglant le bug 40, alors un seul bug suffisait nomicons/smile

52

(128 replies, posted in Bar Fourre-tout)

Bonjour romill,

Dans la mesure où electrx mentionne des "modifs" de manière générique, je pense qu'il s'agit d'un problème différent du tiens (que je viens de résoudre).

Bon, après enquête, il s'avère qu'il s'agit d'un problème causé par l'élément repartiteur.elmt (que nous fournissons et que tu as utilisé dans ton schéma) : celui-ci comporte plusieurs bornes avec des coordonnées identiques, ce qui, cumulé à une optimisation présente dans le code de chargement des schémas, empêchait le chargement de pas mal de conducteurs. En conséquence :

  • Nous avons enlevé l'optimisation en question : révision 1415

  • Nous avons corrigé l'élément repartiteur.elmt : révision 1416

Nous t'invitons donc à télécharger la toute dernière révision de la version 0.3 ici :
https://download.qelectrotech.org/qet/builds/20111229/

romill wrote:

C'est fait par mp.

Pour information, j'ai reçu ton fichier .qet, et j'ai pu reproduire le problème de chargement des conducteurs. J'étudie ça et je reviens vers toi quand c'est réglé.

Salut,

Peux-tu nous faire parvenir le fichier qui pose problème ? Ça facilitera le diagnostic.
Au passage, la dernière build est dispo ici : https://download.qelectrotech.org/qet/builds/20111229/ -- même si ça ne devrait pas arranger ton problème en particulier.

56

(128 replies, posted in Bar Fourre-tout)

Salut,

electrx wrote:

Par contre si j'ouvre un projet déja sauvegardé, je le modifie, je l'enregistre et le referme, a la réouverture les modifs n'ont pas étées prises en compte??
J'ai bien essayé aussi de faire enregistrer sous mais c'est pareil.
Avez vous une solution?
Merci

Nous n'arrivons pas à reproduire ton problème pour le diagnostiquer/solutionner ; en plus des questions de scorpio, as-tu la possibilité de nous faire parvenir le fichier qui pose problème ?
Au passage, la dernière build est dispo ici : https://download.qelectrotech.org/qet/builds/20111229/ -- même si ça ne devrait pas arranger ton problème en particulier.

Ah non mais y'a pas de mal (bon, à part que ça sert pas à grand chose parce que les threads de spam, on les voit via le flux RSS et on les vire dans les 24 heures). Par contre, on recherche bel et bien quelqu'un qui pourrait prendre en charge la maintenance des applis web, ça ferait un truc en moins à gérer. D'ailleurs je vais voir pour l'upgrade PunBB là...
Edit: Effectué ; le captcha a été remplacé par une question. On va voir ce que ça donne sur le long-terme au niveau du spam....

Est-ce que je dois prendre ça comme une candidature pour prendre en charge la mise à jour des softs web que nous utilisons (DokuWiki, Mantis, PunBB) ainsi que leur maintenance (genre trouver de meilleurs captchas) ? nomicons/smile

Hello,

fiddler wrote:

A slight abnormality is when editing an element, the updated part does not appear until next time the element is dragged onto the screen. Ie when changing allowable orientations Ctrl+t it does not update until new part is loaded.

Yep. After modifying an element, you should use the "Reload" button in the panel to see its new appearance in the panel, it is not automatic yet.

Regarding elements already added to the diagram: do not forget they are actually instances of the element automatically copied in the "Project collection > Imported elements". But indeed, existing elements are not updated until the file is opened again, the main problem being the management of updates that would forbid the state of the element on the diagram : moving/deleting terminals imply losing the attached conductors, and forbidding an orientation  imply we should choose an arbitrary new orientation for impacted elements.

fiddler wrote:

Also it would seem the by default it would be good to have a positions ON by default, ie Nort, South, East, West.

As far as I remember, the assistant you go through when creating a new element suggests using North as the default, with the three other orientations allowed, ans this also occurs when creating a raw element editor using the systray icon. Is this what you are referring to?

Eticoat wrote:

En fait, « Effacer le filtre » devrait refermer les catégories sous les répertoires QET et Utilisateur à l'identique de l'arborescence développée à l'ouverture de QET.

"En quel honneur ?" Intuitivement, si on efface le filtre, je peux comprendre qu'on s'attende à retrouver l'arbo dans l'état où elle était avant la saisie du filtre, mais cela ne correspond à l'état de l'arbo à l'ouverture de QET que dans un cas particulier qui est "je tape directement un filtre après ouverture du logiciel". D'ailleurs, l'état de l'arborescence est déjà sauvegardé et restauré lorsque l'on recharge la collection ; sans cela, recharger la collection la remettrait dans l'état inital à l'ouverture du logiciel, et je ne pense pas que ce serait très pratique.

Eticoat wrote:

Charge au créateur de schéma de refaire un filtre pour rechercher un nouvel élément (ou le même), s'il le souhaite. Autrement, il fait une recherche manuelle.

De la même façon, je pourrais te répondre que comme il y a la possiblité de filtrer, tu n'as pas besoin d'avoir une arbo toute repliée quand tu cherches un élément, tu peux filtrer de nouveau.

Eticoat wrote:

On peut éventuellement trouver un intérêt à utiliser le filtre pour ranger rapidement une arborescence qui a été trop développée par l'utilisation de beaucoup d'éléments.

Ah non, là ça devient carrément foireux et contre-intuitif ; si je veux "ranger" une arborescence, je m'attends à un bouton / un menu / un raccourci pour ça, pas à un effet secondaire d'une autre fonctionnalité.

Eticoat wrote:

Par contre, je dois dire qu'à mon niveau actuel de création de schéma (néophyte 1er degré), je n'ai pas d'idée sur l'intérêt de « ... pouvoir conserver les développements / replis de catégories faits juste après l'application  du filtre... ». A voir avec la pratique de QET.

À mon sens, c'est le même besoin que pour les catégories ouvertes avant le fitre : quand on fait une action manuellement (ici : déplier une arbo, par exemple les catégories les plus souvent utilisées), on ne s'attend pas à ce que ce "travail" soit foutu en l'air par une fonction de filtrage.

Bref, je verrai ce que je peux faire, mais je travaille sur un autre sujet ces temps-ci...

Salut,

En fait, c'est le comportement normal par rapport à l'implémentation actuelle : à partir du moment où tu tapes une lettre, le filtre va immédiatement déplier plein de catégories car beaucoup d'éléments contiennent cette lettre. Il est techniquement possible de remettre l'arbo dans l'état où elle était avant la saisie du filtre, mais je ne te promets pas de pouvoir conserver les développements / replis de catégories faits juste après l'application  du filtre...

62

(1 replies, posted in FR : Aide, suggestions, discussions, ...)

Salut,

En effet, il s'agit d'une possibilité qui apparaît à partir de la version 0.3, qui est toujours en cours de développement mais qui peut tout de même être téléchargée et utilisée.

63

(2 replies, posted in News)

Hello,

Once again, we managed to be mute during two months. But we have not been inactive since the latest news:

  • Our elements collection now contains 1123 elements within 179 categories.

  • A few improvements and bugfixes in the elements panel or when opening files.

  • Pressing F2 now allows to quickly change the colour of a conductor.

  • The elements panel now displays the folio index right before its title.

  • We implemented a SQLite-based cache to speed up the elements panel loading.

  • We also stopped loading the whole collection in memory, therefore speeding up the start time and sparing a lot of memory, especially when the SQLite cache is filled.

The elements repository is concerned too:

  • a bug in the generation of ZIP archives has been fixed

  • from now on, the elements collection as it can be found in our 0.3 branche will be synced to the "collection_officielle" directory every hour.

See you!

Salut,

À partir des informations complémentaires fournies dans http://debian-facile.org/forum/viewtopic.php?id=4256, à savoir que les fichiers qui posent problème proviennent du dépôt d'éléments et non du logiciel tel que nous le distribuons dans nos paquets, j'ai pu trouver l'explication du problème : le script chargé de générer les archives ZIP à la volée pour le dépôt d'éléments avait un bug (sans doute apporté par la montée de version PHP de notre hébergement) qui lui faisait inclure les fichiers spéciaux "." et ".." dans l'archive.
Ces fichiers spéciaux sont en fait des liens vers respectivement le répertoire courant et le répertoire parent, et il n'y a pas lieu de les ajouter dans une archive ZIP. C'est désormais corrigé.

fusible09 wrote:

ps il y a t'il un moyen de notifier que le post est résolu, comme sur le forum Ubuntu ?

Nope, on est relax ici, on tagge pas les sujets nomicons/smile

Ou menu configuration > Sortir du mode plein écran ; si par hasard ceci ne fonctionne pas, donne-nous des informations sur ton système, qu'on puisse essayer de reproduire le problème.

scorpio810 wrote:

J'arrive pas à reproduire ce bug sous ma debian Sid .
rev 1350 , Qtcore 4.7.3-8

ps je pense à un bug lié avec la version de Qt fourni avec le build windows .
La dernière release QT est en version 4.7.4 , celle fourni est en 4.6.2 .

Ouais, ça y ressemble bien. Je vais tâcher de builder Qt avec une version plus récente sous Windows, mais je suis un peu pessimiste parce qu'avec Qt 4.7.3 sous Debian, je reproduis encore et toujours le bug #30...

Edit: à noter que sous Windows XP SP3, avec Qt 4.6.2 (celui fourni dans les ready to use), je n'arrive à reproduire que ce qui est décrit dans le bug #30, mais pas les symptômes supplémentaires de Klaus, c-à-d que je n'ai pas besoin de cliquer 25 fois pour éditer un autre champ de texte.

Salut,

Ton problème ressemble à celui décrit dans ce bug, mais en aggravé : http://qelectrotech.org/bugtracker/view.php?id=30 -- est-ce que la description de ce bug te parle ?
Sinon, peux-tu me rappeler quelle version de QET tu utilises, sur quel système et avec quelle version de Qt ? Merci d'avance.

Bon, j'ai implémenté l'affichage des numéros de folios dans le panel d'éléments, c'est disponible dans la branche 0.3, à partir de la révision 1350. Il y a un build Windows disponible sur https://download.qelectrotech.org/qet/builds/20111001/

Salut,

friskolon wrote:

Y a t'il un moyen de modifier le nom affiché dans l'arborescence des projets ?
Je m'explique : dans le rectangle gauche (celui ou sont afffichées les collections), il y a tout en haut, les projets ouverts, et on voit dessous l'arborescence des schémas qui porte le nom du titre des pages des schémas.
Mon soucis est qu'avec un projet de 10 pages dont toutes les pages ont le meme titre, j'ai 10 fois le meme nom qui s'affiche .

Non, en l'état actuel des choses, ça prend le titre du schéma, c'est codé en (très) dur.

friskolon wrote:

Comment pourrais-je faire , sans modifier les noms de mes schémas, pour afficher par exemple à la place le n° du folio dans l'affichage de l'arborescence. Cela me paraitrait plus clair surtout avec des projets de 80 pages.

De fait, il n'y a actuellement rien dans QET qui permette de spécifier un pattern/format pour l'affichage dans le panel d'éléments. Je vais voir si je peux facilement ajouter le numéro de folio dans le panel, ça aiderait.

friskolon wrote:

A moins peut-etre de passer sur des cartouches personnalisés : ?

Oui, il est possible de contourner le problème en maintenant séparément un "alternative-title" qui serait affiché par le modèle de cartouche tandis que le panel d'élément continuerait d'afficher le "title" originel. Ça donnerait ça en termes de code (à coller dans l'ersatz de pseudo-éditeur qu'on se coltine ces temps-ci, après avoir saisi un nom de template comme "alternative-title") :

    <informations>Author: The QElectroTech team
License: see http://qelectrotech.org/wiki/doc/elements_license</informations>
    <grid cols="t22%;r100%;t22%" rows="25px;25px">
        <field rowspan="0" row="0" col="0" name="author" displaylabel="true" align="left">
            <label>
                <translation lang="en">Author</translation>
                <translation lang="fr">Auteur</translation>
                <translation lang="it">Autore</translation>
            </label>
            <value>
                <translation lang="en">%author</translation>
            </value>
        </field>
        <field rowspan="0" row="1" col="0" name="date" displaylabel="true" align="left">
            <label>
                <translation lang="en">Date</translation>
                <translation lang="fr">Date</translation>
                <translation lang="it">Data</translation>
            </label>
            <value>
                <translation lang="en">%date</translation>
            </value>
        </field>
        <field rowspan="1" row="0" col="1" name="title" displaylabel="false" align="center">
            <label>
                <translation lang="en">Title</translation>
                <translation lang="fr">Titre</translation>
                <translation lang="it">Titolo</translation>
            </label>
            <value>
                <translation lang="en">%alt-title</translation>
            </value>
        </field>
        <field rowspan="0" row="0" col="2" name="file" displaylabel="true" align="left">
            <label>
                <translation lang="en">File</translation>
                <translation lang="fr">Fichier</translation>
                <translation lang="it">File</translation>
            </label>
            <value>
                <translation lang="en">%filename</translation>
            </value>
        </field>
        <field rowspan="0" row="1" col="2" name="folio" displaylabel="true" align="left">
            <label>
                <translation lang="en">Folio</translation>
                <translation lang="fr">Folio</translation>
                <translation lang="it">Foglio</translation>
            </label>
            <value>
                <translation lang="en">%{folio-id}/%{folio-total}</translation>
            </value>
        </field>
    </grid>

++

Problème réglé sur la mailing list ; résumé du problème :

C'est curieux, tes deux fichiers comportent un certain nombre d'octets zéro
(0x00) à la fin, alors que ce n'est pas prévu par notre format. C'est comme
s'ils avaient été copiés / transférés bizarrement. Tu trouveras ci-joint tes
deux schémas sans ces octets zéro, ils devraient désormais s'ouvrir. Je n'ai
par contre aucune idée de ce qui a pu provoquer ça.

Si quelqu'un a une hypothèse, qu'il se manifeste...
Solution possible :

> Si cette mésaventure se reproduisait pouvez-vous me dire comment
> être autonome pour réparer?
Tu peux utiliser un éditeur hexadécimal comme frhed[1] pour éditer le
fichier corrompu et enlever les rafales de "00" à la fin du fichier.

Bonjour,

Pourrais-tu nous envoyer le fichier .qet par mail à qet@lists.tuxfamily.org ? Merci d'avance.

On se calme les enfants ; la version 0.3 a toujours été une version de développement, même pas une alpha/beta/RC, et je n'ai jamais garanti la pérennité des schémas générés avec des versions de développement, c'est du pur "without any warranty". En revanche, tous les schémas créés / modifiés avec une nouvelle version seront immunisés d'office contre ce qui est, petit rappel, un cas particulier.

En ce qui concerne une éventuelle réécriture forcée : non, empiriquement, il vaut mieux ne pas réenregistrer un schéma tant qu'il n'est pas modifié : on gagne en performance et en pérennité ; par exemple, un projet ouvert en lecture seule avec QET 0.3 peut être relu par QET 0.2.

Concernant le nombre de folios, je rappelle qu'il existe un bouton "Enregistrer tous les schémas" (5ème bouton à partir de la gauche) qui se fera une joie de réenregistrer tous les folios d'un projet et ce sans même devoir les modifier (d'ailleurs, je viens de tester avec le Convoyeur_bouteilles.qet, c'est super-lent :') mais ça fonctionne).

https://download.qelectrotech.org/qet/builds/20110830/

Bonjour,

xavier wrote:

En revanche, elle a changé une toute petite chose : elle a changé la version du "project" de "0.3" à "0.22" (alors qu'elle n'a finalement rien enregistré qui soit spécifique à la 0.22). Or, la 0.3 applique un traitement spécial aux textes des schémas lorsqu'elle ouvre un projet estampillé 0.22, traitement qui ne doit pas être appliqué en ouvrant un schéma 0.3, au risque de provoquer... le bug que tu nous as décrit.

Il y a donc clairement des choses à améliorer dans cette gestion des versions, et je suis content d'avoir eu un retour sur le sujet que je savais sensible, et ce avant d'en faire une version stable ("release early, release often" qu'ils disaient...).

Je te tiens au courant des corrections à venir.

J'ai commité hier la révision 1315. À partir de cette révision, chaque schéma d'un projet embarque le numéro de version avec lequel il a été enregistré, ce qui permet de mieux détecter la version d'un schéma à son ouverture et donc d'éviter le bug que tu as rencontré. Toutefois, cette correction s'applique essentiellement aux nouveaux fichiers créés avec l'application, plus exactement à tous les schémas ré-enregistrés en version 0.3rev1315. Il est ainsi possible d'immuniser ses fichiers existants en forçant le ré-enregistrement de chaque schéma dans QET 0.3rev1315 : par exemple "ajouter un élément, le supprimer juste après, enregistrer le schéma" suffit à immuniser un schéma.