You are not logged in. Please login or register.
QElectroTech → Posts by xavier
Hello,
Here we are, 26 months after 0.22, releasing the 0.3 version. Oh, just an alpha to start out: we made enough changes to deserve a test period. So, feel free to download this version, and do not hesitate to report any bug you would encounter.
A few links:
ChangeLog: http://qelectrotech.org/wiki/en/doc/changelog_0.22_0.3a
Download page: http://qelectrotech.org/download
Code documentation: https://download.qelectrotech.org/qet/d … index.html
Enjoy!
Qui devrait formaliser par écrit les différents test à faire et comment établir ceci (car je suppose qu'on balance pas comme sa en disant tien on clic par ci par la voir si sa marche. Il doit y avoir une méthodologie en fonction du code à certain endroit qui est susceptible de posée problème).
Les techniques de tests automatisés se multiplient pour le web, mais pour les applications standards GUI, je ne connais rien. De fait, la ou les personnes qui endossent ce rôle ont carte blanche au niveau des outils et méthodes.
fichier texte -> 0 . Je suppose que je peut trouvé de la doc la dessus ( Mais pourquoi avoir besoin de savoir sa ? c'est en vue de l’intégré dans le site, genre en html ?)
Les fichiers .elmt, qet_directory et .titleblock sur lesquels les traducteurs travaillent sont des fichiers textes ; dans un but de propreté et d'harmonisation, il y a une petite palanquée de règles à faire respecter (ce que j'ai cité + l'indentation en fait) au sein de la collection, d'où le besoin de maîtriser le concept de fichiers textes. C'est une notion sur laquelle j'insiste pas mal ces temps-ci, ayant croisé trop d'ingénieurs en informatique n'ayant aucune notion sur ce sujet qui s'avère rapidement handicapant.
Hello,
Today, the QElectroTech project would like to sum up its needs in terms of contributors. We are currently looking for:
A translation manager, i.e. someone who would welcome new translators, teach them how to contribute, help them when they encounter difficulties, ensure they are still active, etc. Required skills:
Being able to read and write correctly in English; French is appreciated
Knowledge of Subversion (at least enough to teach it)
Knowledge of subtleties inherent to text files (encoding, carriage returns, BOM, etc.) -- this can be taught in a few hours though.
Availability and patience
A native English translator: in order to check every English sentence produced by the project, be it part of translations, news or documents, we need someone whose native language is English and could therefore be authoritative about "the right way to say it". Required skills:
Being born in the right place I guess?
Electrical knowledge is an asset
Documentation writers: while we try to make the software as intuitive as possible, end users may appreciate relying on a well-written documentation. Our current status regarding this point is: chaotic. Of course, writing documentation is not enough: we are looking for people interested into writing, maintaining and updating documentation. Required skills:
Pedagogy
Good sense of writing and spelling
Self-organization
Formal testers: we currently have no procedure (be it manual or automated) to test all aspects of our application. Since it is a standard GUI application, all known-and-popular techniques used in the web development world do not apply; we do not have any tool or methodology in mind, so volunteers would be free to organize the way they want.
C++/Qt developers: well, this one is pretty simple: if you feel like "Hmm, I could change this or that in this software, I'd just have to hack this part of the code" when trying QElectroTech, then you are certainly a good candidate. Required skills:
Subversion (sorry Git-fanboys... you can still use git-svn)
C++: don't be afraid, you don't have to be an expert at structures sizes, padding, virtual tables, private inheritance, reinterpret_cast, templates, mainly because...
Qt: makes a lot of things easier.
A MacOS packager/tester/maybe-developer: I stopped counting people who applied for this position; nevertheless, we are still looking for an active, available and efficient MacOS packager. Required skills:
Living in the Apple world, I guess?
Being able to regularly produce an usable and consistent MacOS package
Programming skills are an asset
Let's finish with some common requirements: some projects live through their mailing lists, other live through real-life meetings, audio and video conferences, ... the QElectroTech project lives on its IRC channel. Therefore, anyone who wants to seriously contribute to the project is supposed to be present as much as possible on the IRC channel. It is not as difficult as it sounds: it mainly implies reading what happened while you were away.
That's it. You may apply by sending an informal mail to qet@lists.tuxfamily.org. Stay tuned, we should have interesting news in the next weeks :-)
On a du taff à revendre...
La documentation a clairement besoin de main d'oeuvre ; à noter que le document que mentionne scorpio est non seulement à traduire mais aussi à mettre à jour avec les nouveautés de la version 0.3 (modèles de cartouches notamment).
Concernant les tests, il faudrait les formaliser par écrit pour obtenir une liste complète des actions à reproduire pour tester QElectroTech de manière exhaustive, avant une release par exemple. C'est un travail plutôt pénible (car répétitif) mais qui apporte beaucoup à la fiabilité de l'application.
Enfin, si par hasard tu as les compétences suivantes :
savoir lire et écrire correctement en anglais
connaître Subversion (c'est beaucoup plus accessible que C++)
savoir ce qu'est un fichier texte (problématiques d'encodage, de retours chariot, de BOM, ...)
être patient
... alors je pourrais te déléguer la gestion des traductions, c-à-d non pas la traduction elle-même, mais le fait d'accueillir, former, relancer et dialoguer avec les traducteurs qui se proposent.
Oh, j'oubliais : pour contribuer au projet, il est fortement conseillé de rejoindre (et rester) sur le channel IRC. C'est un peu la condition sine qua none pour s'intégrer efficacement dans le projet.
Hmm, oui, là, je crois que je vais blâmer le thème, surtout si "utiliser les couleurs systèmes" ne fait rien (avec les thèmes standards Qt/KDE, l'effet est immédiat). Tu peux essayer de jouer avec avec l'option -style <nom du style> ou l'utilitaire qtconfig (mais c'est un coup à casser ton thème). Sinon, est-ce que tu as d'autres applications GTK ou Qt avec une fonction "Qu'est-ce que c'est ?" pour comparer ?
En tout cas, merci pour le test rapide de cette nouveauté 
Salut,
Lorsque je clic sur quelque chose avec le 'Qu'est-ce que c'est?' , je ne vois pas ce qu'il y a d’écrit, l'encadré est blanc/jaune mais on ne distingue pas les textes... en fait il faut que je mette mon regard presque tangent à l’écran pour voir ce qu'il y a d’écrit (un écran LCD les couleurs/contraste change quand on regarde sous un autre angle)..
Je rencontre ce problème que sous linux mint 11, sous ubuntu 12.04 pas de problème.
Peut être un problème de Qt (4.7.x sous mint 11) du même style que j'ai avec l'aperçu avant impression qui est incomplet?
On peut avoir un screenshot du WhatsThis qui déconne ? Ça m'inspirera peut-être une solution, mais pour le moment, tout ce que je peux te dire, c'est que je n'ai normalement pas la main sur le rendu des bulles de WhatsThis. Autre question : est-ce que l'option Configuration > Général > Apparence > Utiliser les couleurs du système est cochée ?
Dans le 'Qu'est-ce que c'est?' du schéma, il manque un espace: "en y ajoutantdes éléments".
voila.
Merci pour le signalement, je viens de corriger ça dans la révision 1727.
A priori, ça ne passera pas non plus ; je ne m'en souvenais pas, mais les collections sont effectivement chargées en ignorant les liens symboliques :
QStringList dirs = cat_dir.entryList(QStringList(), QDir::AllDirs | QDir::NoSymLinks | QDir::NoDotAndDotDot, QDir::Name);
là, dans fileelementscategory, ligne 342 ^ Si je n'arrive pas à me rappeler pourquoi j'ai mis ce QDir::NoSymLinks, promis, je l'enlèverai :-)
Concernant la collection d'éléments perso, il s'agit toujours du dossier "elements" dans le dossier de configuration, lequel peut être redéfini via par l'option --config-dir=DIR. Si elle n'est pas redéfinie (c'est sans doute ton cas), la configuration de QET est stockée dans :
sous Windows : dans %APPDATA%/qet, ou, dans l'éventualité où cette variable d'environnement ne serait pas renseignée (je serai curieux de voir le bordel qui irait avec), dans <dossier du profil utilisateur courant>/Application Data/qet
Partout ailleurs : dans le sous dossier .qet du home de l'utiliateur courant ; en clair : ls -al ~/.qet
Voici les quelques points qui pourraient à mon sens pas mal améliorer l'utilisation :
- pouvoir aligner les éléments (alignement par le haut, le centre ou le bas, verticalement et horizontalement)
Ce n'est ptet pas si difficile que scorpio le laisse entendre (surtout si on se cantonne aux éléments). En revanche, ça a le mérite de ne pas avoir été trop demandé, c'est presque original ;-)
- pouvoir tracer quelques formes simples sans que ce soit des éléments : carrés, cercles, éventuellement flèches. Un ex pour éclairer : si je fais un schéma qui regroupe des éléments qui sont dans deux coffrets séparés, j'aimerais bien pouvoir le signifier en encadrant chaque groupe d'éléments
Oui, je vois le manque mais je te préviens de suite que ça ne sera jamais implémenté tel quel : les formes simples posent un problème : elles sont horriblement simples, dans le sens où elles ne colportent aucune information sur leur utilité et leur signfication ; pour un banal rectangle donné sur un schéma, il n'est pas aisé, même à grands coups d'heuristiques, de déterminer s'il s'agit d'un coffret ou d'un rectangle pour décorer. Encourager la prolifération d'items dénués de sémantiques ne peut que nous compliquer le travail le jour où nous commencerons à implémenter des fonctionnalités intéressantes, je pense notamment à tout ce qui s'approche de la simulation. Sans parler de l'inévitable tendance que les débutants auraient à faire leurs conducteurs et éléments à partir de formes libres... on a déjà reçu un schéma comme ça, c'était un massacre.
L'approche prévue pour ton exemple serait plutôt d'ajouter un outil "coffret".
- pouvoir changer la police (ou au moins la taille) d'une zone de texte volante (enfin qui ne fait pas partie d'un élément). J'ai vu qu'il y avait des éléments qui pouvait faire le job, mais c'est pas très pratique.
Oui, ça a déjà été demandé ; mais je rebondis sur les dires de scorpio : je confirme que les textes, c'est une put*** de plaie à gérer. D'ailleurs, je travaille sur un bug au niveau du déplacement des textes à la souris là, je suis bon pour réviser mes changements de repère...
- pouvoir changer la couleur d'une sélection de plusieurs fils plutôt que de les faire un par un ...
C'est pas tant compliqué à faire que chiant (parce que, pour être juste, le changement doit porter sur tout le widget d'édition d'un conducteur, pas uniquement sur la couleur).
Bref, à l'exception des formes libres, tout finira par être implémenté... mais pas pour la 0.3 parce que ça fait trop longtemps qu'on n'a pas releasé ; donc en ce moment, c'est stabilisation, stabilisation, stabilisation : je n'attaque pas de nouvelle fonctionnalité.
Pffffrrttt... j'en fais régulièrement de belles, mais celle-là, c'est juste la lose...
diff --git a/sources/diagramview.cpp b/sources/diagramview.cpp
index 112d9dd..a2904cb 100644
--- a/sources/diagramview.cpp
+++ b/sources/diagramview.cpp
@@ -985,7 +985,7 @@ void DiagramView::editConductorColor(Conductor *edited_conductor) {
QColorDialog *color_dialog = new QColorDialog(this);
color_dialog -> setWindowTitle(tr("Choisir la nouvelle couleur de ce conducteur"));
#ifdef Q_WS_MAC
- color_dialog.setWindowFlags(Qt::Sheet);
+ color_dialog -> setWindowFlags(Qt::Sheet);
#endif
color_dialog -> setCurrentColor(initial_properties.color);nleroy: réessaye donc avec la version 1653...
Bonjour,
Pour information, dans les derniers commits (révision1642 et antérieures), l'éditeur de cartouches a été légèrement amélioré : corrections de bugs dans la gestion des spans, possibilité de travailler avec 0 ligne / colonne, ajout de barres d'outils. De plus, l'impression a été modifiée pour exploiter l'espace laissé vacant par le cartouche lorsque l'on désactive son rendu, ce qui devrait résoudre le problème initial de ce topic.
J'avais constaté des problèmes similaires sous X11 avec Qt 4.7.x, ils semblent avoir disparu avec Qt 4.8 (fourni dans les paquets récents) -- peux tu vérifier à coup de Dependency walker (ou encore Processs Explorer) que tu utilises bien les DLLs de Qt 4.8 ?
Salut,
Oui, c'est une limitation connue de l'implémentation du copier/coller. En fait, ça ne se produit pas quand tu ouvres une deuxième "feuille" mais quand tu ouvres un deuxième projet ; le copier/coller d'un projet à l'autre ne provoque pas l'intégration des éléments copiés dans le projet de destination (c'est ça la limitation). Conséquence : les éléments inconnus dans le projet de destination sont remplacés par des éléments "fantômes", reconnaissables à leurs points d'interrogation. Tu peux prévenir ce comportement en copiant habilement les éléments embarqués avant le copier/coller (ou après, mais il faut alors le fichier à cause d'autres limitations encore plus galère...).
De fait, c'est connu depuis la version 0.2 mais il n'y a jamais eu assez de plainte pour que je prenne le temps de bien gérer le problème...
Bonjour,
Voici un retour sur la compilation de la 0.3 sur Mac :
J'utilise avec succès la version 0.3 avec Wine sous Mac OS 10.6.8 et j'ai tenté la compilation des sources de la 0.3 à partir du svn (release 1624). La compilation n'aboutit pas et voici l'erreur que j'obtiens :
[prose habituelle de g++]Si vous avez une idée ...
Oui, je soupçonne ton g++ d'être un peu vieux, cf cette charmante explication ; peux-tu vérifier sa version (g++ --version) ?
J'ai installé le SDK de Qt :
QMake version 2.01a
Using Qt version 4.6.3 in /opt/local/libexec/qt4-mac/lib
Tu peux installer la dernière version (4.8.0), c'est celle que j'utilise pour travailler.
En revanche, la compilation de la version trunk se passe parfaitement ...
Pas étonnant, le trunk ne contient pas grand chose de plus que la 0.22 :-)
Plus exactement, les dimensions pour un nouveau schéma proviennent du projet parent dans lequel on ajoute le schéma, cf menu Projet > Propriétés du projet.
Mais d'où viennent ces propriétés ? Elles sont embarquées dans le fichier projet, mais lors de la création d'un nouveau projet, elles sont reprises de la configuration globale de QElectroTech, cf menu Configuration > Configurer QElectroTech, qui n'est qu'un affichage convivial du contenu du fichier qelectrotech.conf.
En cas d'absence de qelectrotech.conf, comme sous Debian au premier lancement ou après suppression de ~/.qet, les dimensions codées en dur dans le binaire (17x60, 8x80) sont utilisées. En revanche, sous Windows, un vieux qelectrotech.conf était fourni d'office avec les valeurs moindres discutées ici, ce qui a été corrigé dans le tout dernier build. Ces valeurs n'en restaient pas moins facilement redéfinissables via les menus mentionnés ci-dessus.
Se serait bien que lorsqu'on desative cartouche, l'ensemble du plan glisse vers le bas pour occuper l'espace utilisé par le cartouche, un peut à sa sauce en tête et pie de page.
Je ne suis pas sûr que ça soit entièrement possible, car le schéma a des dimensions fixes. Mais ça peut impacter quand tu demandes à ce que le schéma soit adapté à la page, oui.
Pour ton crash : du coup si tu pouvais nous indiquer la révision exacte utilisée, ça nous aiderait à mieux cerner le bug
Bonjour Frederico,
@scorpio810: oui entasser plus de symboles, la plupart des symboles que nous utilisons en belgique( habite en belgique) ne se trouvent pas dans la base de données originale et je me crée mes propres symboles.
Première question : pourquoi entasser des symboles dans un coin de schéma ? Ça n'a pas de sens, il y a la "collection utilisateur" pour ça : elle te permet de gérer ta propre arborescence d'éléments personnalisés que tu utilises régulièrement sur ton poste. Ces éléments sont ensuite intégrés dans la "collection embarquée" quand tu les poses sur un schéma d'un projet.
Si lors de l'impression ou exportatio PDF on spécifie de ne pas imprimer le cartouche, l'espace occupé par celui-ci reste blanc et inocupé
Oui, c'est un comportement connu ; je tâcherai de me pencher dessus prochainement, ça ne devrait pas être trop compliqué à corriger
c'est la galère, lorsque j'essaie d'utilser une autre cartouche, ou d'en configurer une et l'intégrer à un schèma, boum ça plante lorsque j'enregistre
Pourrais-tu nous décrire précisément ce que tu fais pour reproduire le plantage ? Nous sommes actuellement en phase de "polishage" et sommes intéressés par ce genre de retours.
je viens de mettre ton fichier dans \conf\titleblocks
et rien je ne le vois pas dans ma liste de cartouches
Hmm... normalement ça doit apparaître dans "cartouches utilisateur" ; tu peux alors le glisser sur le schéma.
Salut,
En l'état actuel des choses, tu ne peux pas enlever le cartouche lors de l'édition du schéma (tu peux te faire un cartouche personnalisé discret par contre. genre une ligne de 5px, une colonne de 100%, une cellule vide). Le rendu du cartouche peut être désactivé lors de l'export / impression (mais j'ai deux-trois trucs à corriger à ce niveau).
Pour les dimensions de ton schéma, tu peux les spécifier dans les propriétés de ton schéma (clic droit > propriétés du schéma ou double-clic sur le cartouche / le cadre).
Hello,
Today is an important day. Today, the QElectroTech team is pleased to announce the whole project will be renamed to QMusicArt and become a music partition editor. Indeed, thanks to many external contributions, we found out that QElectroTech could be used for non-electrotechnic purposes, ranging from hydraulic to network engineering, without forgetting music. The QElectroTech team members unanimously decided to focus on the musical domain because:
it's cool
musicians always get all the chicks
err... it's cool, y'know?
have we mentioned the chicks yet?
By the way, we intend to release QMusicArt much more often we did for QElectroTech: we expect at least one stable release per month !
Well, whatever, we let you appreciate the power of QElectroTech in the music kingdom:
Thanks to Pawel for lending us his latest piece of art 
Edit: it was, of course, our April's fool :-)
Bonjour,
Pour information, à partir de la révision 1593, il est possible de déplacer le schéma à la souris en maintenant Ctrl et Shift enfoncés. Je n'ai pas utilisé le clic milieu, car il est déjà utilisé pour coller à un endroit précis (oui, c'est X11-like) et ça aurait compliqué les choses.
Salut,
Merci pour le rapport, il y avait en effet un bug ; la correction est disponible à partir de la révision 1587 : qelectrotech-branche-0.3-rev-1587-x86-win32-readytouse.zip
++
This is quite a shameful birthday. Two years ago we were releasing the 0.22 version of QElectroTech. Of course, this means two years without the urgent need to release a 0.23 version to fix a major problem in our current stable version. But this means a two-years gap without a release. This has also meant relatively long periods with no news. Still, the project is alive: new commits appear in our 0.3 branch (alas unmonitored by some tools like Ohloh), builds for Windows and Debian are regularly produced, new threads pop in the forum, new translators apply to translate the application...
The next stable version (0.3) has been delayed several times, due to incompleteness compared to the always-moving roadmap, and lack of time on my own. The recent improvements were not judged sufficient to tag the 0.3 version right now: the title block template system still needs a bit of polishing, texts-related improvements have to be fully tested again, printing has to be checked against regressions and recently reported problems, etc. However, no major feature shall be added to the current 0.3 branch in order to get a release-compatible version of QElectroTech as soon as possible. Stay tuned ;-)
Ah ben ouais, y'a un mustélidé dont le nom commence par xav et se finit par ier qui a oublié de scripter l'ajout de bin/sqldrivers/qsqlite4.dll ; alors forcément, au moment de contacter le cache SQLite, ça fonctionne moins bien :p
Bon, je vais builder la 1540...
Edit: voilà, c'est bon, tu peux charger la 1540, le souci devrait y être corrigé.
Hello,
Once again, our talent helped us pulverize all of our previous records with a total of 137 days without any news nor any signs of life... apart from the forum, bugtracker and Subversion repository, since we have actually been quite productive :-)
Let's begin with some figures:
157 commits;
the elements collection now contains 1258 elements within 202 categories
The "diff" between the C++ sources at the time of the last news and the sources now is 18032 lines-long.
Yes, 18000 lines! Ok, there is the Unified Diff context. And the copyright-change-that-occurs-on-each-new-year too. But it mainly includes the long-waited WYSIWYG title block template editor:
... along with the following features:
access to editors through the systray menu
new system and user wide collections dedicated to title block templates
ability to open/save a template from/to a regular file
ability to apply a template by drag'n drop
automatic integration into the parent project when dropping a template onto a diagram
ability to clean unused templates within a project
etc.
Basically, title block templates are managed exactly like elements :-) There is still some work to be done, but it is already pretty usable.
The "elements panel" (which we could rename to "everything you may access panel") was also refactored to make the creation of tree-based widgets easier. The main consequences for end users are:
a sensible speedup of the element editor's Open/Save dialogs (which were not using the SQLite cache mentioned in the previous news);
after having filtered the panel, the tree returns to its initial state instead of keeping almost every item expanded.
Last but not least, a new contributor named Mohamed Souabni began translating the application in arabic, bringing the need to check and fix existing layouts to ensure the application remains consistent in a Right-to-Left fashion:
By the way: the topic will hardly make sense for anyone on Earth.
Bonjour,
Je crois que ton clavier s'est blo
QElectroTech → Posts by xavier
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.025 seconds (59% PHP - 41% DB) with 6 queries