Le module de gestion des vues est maintenant en place et semble fonctionnel. Bien sur il faut tester cela en profondeur car il s'agit d'un remaniement important dans le code. Des questions demeurent. Par exemple, que faire dans le cas où la fenêtre du document est divisée en sous-fenêtres ? Chaque fenêtre doit avoir sa vue ou la vue est commune à toutes les sous-fenêtres ? Quelques nouveautés ont été introduites : Le mode "concert" est préservé dans la vue, en espérant que cela répondra à certaines interrogation de l'Atelier. Les groupes sont préservés (en option) dans chaque vue, ce qui permet par exemple, de définir par vue une position ou une présence de symbole des groupes. Dans la fenêtre d'édition des vues, on peut reclasser les vues. On nous a demandé de pouvoir afficher des textes associés aux portées sur un ensemble de vue. Nous avons implémenté une solution simple, si elle ne convient pas on étudiera quelque chose de plus complexe. Chaque texte associé à une portée peut être défini comme global (il s'applique à toutes les vues) ou local (il ne s'affiche que sur cette portée). Chaque vue définit si elle tient compte des textes globaux ou non. Donc, pas de position spécifique à chaque vue par texte ou de texte spécifique à une vue, à voir si cela sera suffisant. La prochaine session de béta test va être chaude... |
|
|
by Didier Guillion | | | |
| Comments
Merci ! C'est allé très vite ! Certains textes ne risquent-ils pas de se retrouver au milieu d'une portée s'il n'y a pas de re-positionnement pour chaque portée ? Si c'est le cas, est-il possible de "fixer" un objet par par rapport à la portée (au dessus ou au dessous) ? |
|
|
'La prochaine session Béta va être chaude' C'est très bon signe : les organismes vivants supérieurs se reconnaissent même à cette propriété |
|
|
Je connais la mode des concerts, les concerts à la mode, mais pas le 'mode concert' De quoi s'agit-il au juste ? Merci de préciser |
|
|
Je suppose que "mode concert" = "pas transposé" |
|
|
Pour la relation entre vues et sous-fenêtres, je dois avouer que je ne visualise pas du tout l'alternative. Les explications de Didier sont un peu compliquées à suivre, ce qui est normal pour des fonctionnalités très graphiques. Avec le logiciel en main cela sera beaucoup plus simple. Pour les textes, la configuration graphique des portées est définissable par vue, donc cela devrait aider à garder les textes globaux dans une position correcte par rapport aux portées. Le fait de définir par vue le mode "concert" était indispensable : seul moyen d'avoir les instruments non transposés dans le conducteur, et transposés dans les parties séparées. Définir la taille de la portée par vue (message d'hier) : c'est une très bonne idée. C'est ce que j'avais fait à la main en octobre dernier, à la demande des instrumentistes qui jouaient une de mes partitions. Keep this good work going on! |
|
|
Je suppose que les sous-fenêtres correspondent à ce qu'on appelle partage d'écran dans un tableur Si l'écran est ainsi partagé (pour une meilleure lecture des partitions volumineuses, il est normal de s'interroger sur le comportement des vues qui seront issues d'un tel écran : seront-elles elles-mêmes partagées de la même manière, ou bien y aura-t-il génération d'autant de vues distinctes qu'il y a d'éléments issus du partage ? Personnellement, et compte tenu de la finalité 'editique' des vues, je pense que les vues ne doivent pas être partagées, en admettant que probablement, elles offriront chacune une place suffisante pour afficher ce qui ne sera en définitive que des sélections partielles du conducteur, y compris au niveau des sous-fenêtres (je suppose que les subdivisions sont uniquement horizontales, et gardent toutes la même largeur, qui est celle de la partition Il semble aussi que ce que nous baptisons 'vues' ne soit en fait que la série des affichages sélectifs en lecture seule, sauf précision contraire Pour moi, outre la direction d'orchestre,l'intérêt des vues qui est aussi de permettre de clarifier le travail compositionnel, en isolant les voix où les systèmes à volonté, devrait impliquer que ces vues permettent la mise à jour, sans retourner à chaque fois vers la partition principale Je ne pense pas que cette question soit englobée dans l'énoncé actuel sauf précision contraire, mais elle l'était en tous cas dans les discussions de l'atelier auxquelles j'ai participé, à moins que je n'aie - une fois de plus - rien compris Cordialement |
|
|
Le partage des fenetres en sous fenetres (verticale ou horizontale) est impleménté depuis la version 7 d'HA si je me rappelle bien. Chaque sous fenetre sera une représentation différente de la même vue. Cordialement |
|
|
Je sais ce que sont les sous-fenêtres, mais c'est la relation entre sous-fenêtres et vues que je ne visualisais pas. En fait, seule la solution donnée par Didier me parait logique, et je ne voyais pas comment il pouvait en être autrement. |
|
|
J'ai vu Sibélius gérer plusieurs fenêtre contenant chacune une vue différente et ça semblait très pratique pour copier\coller les retours à la lignes ... |
|
|
Je connait la notion de vue dans Sibelius, qui s'appelle "Part" (c'est peut etre plus explicite que "vue", je ne sais pas) Mais je ne connais pas le moyen de diviser en sous fenetres, comment fait on ? Cordialement |
|
|
J'en ai aucune idée, mais je peux demander, je vois mon collègue qui utilise ce logiciel demain. |
|
|
Bon, petit rappel pour les multi-fenêtres : on les crée et on les enlève en utilisant des petits bidules (verticaux ou horizontaux suivant la barre d'ascenseur utilisée), on click et on déplace, puis on relache. Je pense que si en multi-fenêtrage on demande d'afficher une vue, il faut mettre cette vue uniquement dans la fenêtre active, les autres restent intactes. |
|
|
Cela semble plus logique, mais nettement plus ardu, je vais plancher la dessus. Cordialement |
|
|
Peut-être peut-on définir que par défaut une vue est toujours en plein écran, et que le retour au mode fenêtré restaure l'aspect initial du conducteur multi-fenêtré, ou non selon le cas ? Cordialement |
|
|
Erratum sur post précédent |
Erratum ' le retour en arrière' au lieu de 'le retour au mode fenêtré' Avec mes excuses |
|
|
Dans l'élaboration d'un document et selon ma propre méthode de travail, il me semble que le travail sur les vues interviendrait à un moment où le multi-fenêtrage ne présente plus d'intérêt. Dans quelles circonstances auriez-vous un besoin simultané de ces deux fonctions ? (question sincère, n'y voyez aucune critique) |
|
|
Par exemple lorsque l'on souhaite copier les mise en pages d'une vue sur l'autre ... sinon je ne sais pas (peut-être pour ceux qui travaillent à plusieurs un morceau devant l'écran ) |
|
|
j'ai répondu pour une question de logique. Question pratique je n'utilise jamais le multi-fenêtrage. |
|
|
Je travaille en multi-fenêtrage soit avec une partition d'orchestre qui ne tient pas entièrement à l'écran, soit pour faire du copier-coller entre des endroits distants d'une même partition. Dans un cas comme dans l'autre, on peut être amené à utiliser le multi-fenêtrage pour faire des corrections sur le conducteur, bien après que les parties séparées ont été générées. Effectivement, si l'on n'a aucune correction à faire après la génération des parties séparées, ta remarque est vraie. Mais si l'on ne faisait jamais de correction a posteriori, on n'aurait pas vraiment besoin des vues... |
|
|
|
|
|