Search options (Page 11 of 14)

Pour résumer, il a privilégié le schéma basique car :

• il est plus facile à réduire pour les petites tailles d'icônes

• il est beaucoup plus intuitif pour tout le monde et cela améliore la « découvrabilité » (`discoverability') de l'application ; en clair : un schéma bateau compris par tout le monde (y compris moi), c'est une application comprise par tout le monde rien qu'en regardant son icône.

Sinon Nuno pense pouvoir produire rapidement la troisième et dernière icône (pour les fichiers .elmt). Nous pourrons alors passer au peaufinage (derniers petits détails, etc.) de ces trois icônes, puis nous pourrons les intégrer dans le dépôt Subversion. S'ensuivra quelques tests au niveau des icônes pour Windows, du `make install' upstream, et du packaging Debian. Enfin, nous pourrons... tagger une version beta \o/

Edit : pour plus de clarté, je remets tous les liens du blog de Nuno ici :

• http://pinheiro-kde.blogspot.com/2009/0 … r-app.html

• http://pinheiro-kde.blogspot.com/2009/0 … l-app.html

• http://pinheiro-kde.blogspot.com/2009/0 … -poll.html

et ceux à venir

Au passage, le point de vue du développeur :
Tout d'abord, le développement d'un écart dynamique paraît peu faisable : ce serait très compliqué à programmer et, une fois mis en place, il faudrait alors un doctorat pour créer un élément.
Ensuite, de par le fonctionnement actuel des branchements entre conducteurs et éléments, si on ne veut pas perdre les schémas créés jusqu'à maintenant (et j'aime à croire, après tout le feedback que nous avons eu, que des gens utilisent QElectroTech), on ne peut pas supprimer les éléments actuels de la collection.
D'ailleurs, si un espacement à 20px comme proposé ci-dessus semble convenir, cela n'exclut pas que certains utilisateurs apprécient un espacement à 10px. Cela n'exclut pas non plus que d'autres apprécient un espacement à 30, 40 ou 42 pixels. Bref, il me paraît difficile de fixer de manière pérenne un espacement inter-bornes "qui-va-bien". La preuve, il semblerait que 10px ait été une erreur.
À un moment donné, chaque utilisateur est libre de faire lui-même ses éléments ultra-spécialisés. Exit donc l'idée de fournir nous-même les éléments dont les bornes sont espacées de 42 pixels en bas, 41 pixels en haut et 43 sur les côtés préférés du capitaine.
En revanche, on peut imaginer deux approches complémentaires pour attaquer le problème :

• Améliorer les fonctionnalités relatives aux textes ; cela implique notamment la possibilité de tourner un texte sur le schéma. Les textes relativement longs pourraient alors être disposés différemment.

• Fournir plusieurs variantes des éléments concernés : typiquement 10px et 20px pour commencer. Quitte à les faire cohabiter, ils seraient dans la même collection, dans les mêmes dossiers. L'utilisateur aurait alors le choix de l'espacement pour chaque élément posant problème.

Reste le problème du bordel apparent dans le panel d'élements (enfin, pas de quoi en faire une maladie je pense) si on met autant d'éléments en double. De ce point de vue-là, il serait assez facile de tagger les éléments sur leur écart, avec des valeurs prédéfinies : 10px, 20px, any.
Il serait également facile d'implémenter un filtre sur ce tag dans le panel d'éléments. Actuellement, il y a un petit champ pour filtrer sur le nom ; on pourrait ajouter une petite liste déroulante qui ferait apparaître :

• pour 10px : les éléments estampillés 10 px (donc arborant un espacement de 10 pixels) et tous les éléments non concernés par ce critère - cela correspond à la collection actuelle.

• pour 20px : les éléments estampillés 20 px (donc arborant un espacement de 20 pixels) et tous les éléments non concernés par ce critère.

• pour any : absolument tous les éléments.

Et bien sûr, on pourrait mettre le filtre sur 20 px par défaut. À noter que le système est rapidement extensible à d'autres écarts voire à d'autres critères de filtrage.

Also, if you do know Subversion, we could give you a write-access account to the Subversion repository, so that you can commit your translations yourself.

Donc tu serais plutôt pour l'ajout de cases à cocher ou de boutons Verrouiller dans la liste des parties ? Mais dans ce cas, il faut trouver un moyen pour que celle-ci soit plus explicite (actuellement, elle affiche "ligne" pour toutes les lignes, etc.), non ?

En fait, il semblerait que ce caractère nécessite trois octets pour être stocké correctement (en UTF-8, un caractère peut prendre un à quatre octets). Ça ne pose semble-t-il aucun problème dans l'implémentation C++ de QtXml. En revanche, cela semble coincer dans PHP/SimpleXML, qui est utilisé pour générer le rendu SVG d'un élément à partir du fichier .elmt sur le dépôt. Je verrai plus tard si je peux arranger la situation. Je pense que nous allons garder la version avec le caractère spécial pour la collection officielle.

Oui, ce sont des coordonnées `bitmap-like', c'est-à-dire que les axes sont orientés de la même façon que dans les programmes de traitement d'image. C'est très naturel dans le domaine informatique. Effectivement, ça change un peu du repère utilisé traditionnellement pour représenter une fonction.

Il est possible d'éditer le "chemin" emprunté par un conducteur : quand tu le sélectionnes, il apparaît en rouge avec de petits carrés verts : tu peux alors "tirer" sur les différents segments du conducteur pour modifier son tracé. Tu peux alors dissocier complètement deux conducteurs ou bien les faire se chevaucher. Les points de jonction sont calculés automatiquement en fonction de ces trajets.

Donc si tu veux déplacer le point de jonction ci-dessous, tu tires sur le segment indiqué par la flèche :

Et hop :

En conséquence, ils sont disponibles ici : http://qelectrotech.org/showcategory.ph … 2Ffonction
À noter que les éléments or.elmt et nor.elmt ont subi une légère modification sur le dépôt uniquement : afin de compenser un problème dans la gestion du caractère spécial >=, j'ai mis un simple >.

Bonjour Charlie, et merci pour ton suivi régulier de QET. Effectivement, nous avons constaté ce bug, qui est dû à l'utilisation de la version 4.5 de Qt ; sont donc impactés :

• la version Windows

• les machines Linux / X11 avec Qt 4.5 installé

Nous avons corrigé le bug entretemps et il n'apparaîtra donc plus dans la prochaine version (0.2 beta à priori) ; en attendant, tu peux utiliser le build 601.

@+

Oui, c'est toi qui nous a fourni cette archive "microstation.rar" avec un schéma sous plusieurs formats. Pour information, j'ai commencé quelques expérimentations basiques pour exporter au format DXF, mais ça n'est pas pour tout de suite (enfin, pas pour la version 0.2 à venir).
Pour ce qui est de l'import, c'est encore plus difficile, je pense que ça relèvera de l'import en tant que "gros élément" ou "image embarquée".

Ravi d'avoir pu t'aider