En musique, la vélocité fait référence à la capacité d'un interprète à exécuter une œuvre à grande vitesse.
En informatique musicale (notamment dans le cadre de la norme MIDI), la vélocité fait référence à la vitesse (donc indirectement à la force) à laquelle une touche d'un clavier est enfoncée. Généralement, le générateur produit un son d'autant plus fort (en fonction d'une courbe prédéfinie) que la touche est enfoncée rapidement. Selon le degré de sophistication du générateur, le volume sonore n'est souvent pas le seul paramètre modifié ; il peut y avoir également, entre autres, modification du timbre.
Parler de dynamique me paraît plus approprié. C'est l'un des principaux apports du piano, d'où son nom originel, le piano-forte.
Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.
Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !
Comme retour d'expérience, je peux évoquer un logiciel de gestion documentaire que j'ai développé (et sur lequel je travaille encore pour apporter des améliorations), et qui est déployé chez plusieurs clients.
Ce logiciel est composé de 2 parties. Une partie prenant en charge le traitement (appelé 'backend'), et une partie prenant en charge l'interface (appelée 'frontend').
Le 'backend' est développé en C/C++ (j’entends par là en utilisant le langage C++, mais avec uniquement les bibliothèques systèmes et les bibliothèques C standards ; pas de bibliothèques C++). Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne, mais n'a pas été déployé (faute ce client en faisant la demande), également sous MacOS.
Le 'frontend' avec interface graphique native s’appuie sur XULRunner et est également développé en C/C++, avec mise en œuvre de XML, XSLT, XUL et XPCOM. Il tourne et est déployé chez des clients sous Windows. Il tourne également, sans avoir été déployé, faute de client en ayant fait la demande, sous Linux. Quand à MacOS, il y a une version en cours de développement. En fait, ça tourne, sauf qu'il n'y a pas de menus, à cause d'une particularité de MacOS (problème d'installation, qui devrait être résolu dés que j'aurais le temps de m'en occuper).
La particularité de ce logiciel, c'est qu'il a également un 'frontend' web, développé en natif (eh oui, ce n'est pas contradictoire). Ce 'frontend', qui prend la forme d'une CGI, a également été développé en C/C++, avec mise en œuvre de XML, XSLT et HTML . L'articulation des fonctionnalités étant identique pour le frontend web (CGI) et natif (XULRunner), une grosse partie du code est commun aux deux. Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne également sous MacOS, sans avoir été déployé, toujours faute de demande de la part des clients.
Concernant les plateformes mobiles, j'ai réussis à compiler et faire tourner l'application ('backend' ET 'frontend's) sous Maemo sur un Nokia N900, mais cela n'a évidemment jamais été déployé chez des clients :-> !
Pour résumer, on a donc là une application multiplateforme (Windows, Linux et MacOS) développée en C/C++, dont la partie interface graphique native s’appuie sous XULRunner. En étant discipliné et organisé, faire du développement multiplateforme en C/C++ ne pose absolument aucune difficulté. Concrètement, grâce à un framework maison, je développe mes logiciels sous Windows avec Visual C++, et, pour les faire tourner sous Linux ou MacOS, il me suffit de les recompiler sur la plateforme en question.
Petit réserve concernant 'rsync'.
Il m'arrive de faire une sauvegarde complète de fichiers sous 'Windows', en utilisant 'rsync' sous 'Cygwin', à destination de la carte mémoire de mon smartphone branché via USB, en mode UMS donc. Je réalise ensuite régulièrement des sauvegardes incrémentales, toujours en utilisant 'rsync' sous 'Cygwin', mais en me connectant au smartphone (qui est sous 'GNU/Linux') par Wi-Fi.
J'ai dû écrire un script qui recule l'horodatage de modification des fichiers de 1 ou 2 heures, selon que l'on soit en heure d'hiver ou d'été, que je dois lancer immédiatement après la sauvegarde complète, sinon la première sauvegarde incrémentale transfère l’ensemble des fichiers, et non pas seulement ceux qui ont été modifiés depuis la sauvegarde complète.
J'ai cherché dans les options de 'rsync', mais je n’ai rien trouvé qui permette de me passer de mon script. Si quelqu'un à une idée…
Il m'arrive de développer des applications WEB, et, bien que j'utilise également C++ dans ce cas (ça va encore me valoir des remarques des pro-JavaScript, ça), je n'utilise pas XULRunner pour ces dernières.
Pour faire des applications WEB, le couple XULRunner + C++ n'est peut-être pas pas le plus adapté, puisqu'il faudrait fournir le code C++ compilé pour chaque plate-forme cible, alors que si l'application n'utilise que JavaScript, elle tournera d'office sur tout les plate-formes sur lesquelles tourne XULRunner.
XULRunner, je ne l'utilise donc que pour des applications pour lesquelles je veux fournir une interface native. Et j'en n'utilise que les éléments relatifs à la gestion de l'interface graphique. Pour tout le reste (gestion des fichiers, du réseau, du multitâche...), j'ai mes propres outils. Donc, que XULRunner, Qt ou autres technologies aient de supers outils pour gérer ces éléments, ça m'importe peu...
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.
En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...
XULRunner est écrit en C++. Son SDK fournit une API C++. Je crois que, de ce fait, on peut le qualifier de toolkit 100% C++. Il ne manque que la documentation adéquate pour l'utiliser en tant que tel, et ce sans un contournement d'aucune sorte.
d'autant plus si l'on n'a aucune affinité avec JavaScript...
Oui donc tu t'es trompé de plateforme à mon sens...
Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...
C'est clair que, avec la démocratisation des technologies WEB, c'est effectivement ce coté WEB qui a été mis en avant, car susceptible de toucher le plus grand nombre de personnes. Il n'en demeure pas moins que XULRunner, de par sa conception, est parfaitement adapté pour une utilisation avec C++ en lieu et place de JavaScript, n'était ce manque de documentation.
Tu ne nous dis pas en quoi XUL t'apporte quelque chose que ne pourrait pas t'apporter Qt avec Quick par exemple, qui permet de décrire de façon très puissante des interfaces dans un format de fichier.
Parce que c'est hors sujet et que je ne saurais répondre à cette question, ne connaissant que très peu ces technologies !
Je ne veux, par ce journal, pousser personne à préférer XULRunner à d'autres technologies, mais s'il se trouve quelqu'un qui, quelles qu’en soient les raisons, décide d'utiliser XULRunner en combinaison avec C++, ce journal l'informe simplement de l'existence d'une source d'informations, que j'espère pertinentes, sur le sujet.
Accessoirement, pour ce que j'en ai lu, Qt Quick n'existait pas lorsque j'ai été amené à choisir XULRunner.
Quel est l'avantage de XUL sur GtkBuilder ou QML si c'est pour faire une application en C++ à 100% ?
Pour ma part, ne ne connaissant guère ces deux technologies, je ne saurais répondre. Je laisserais donc aux connaisseurs le soin de répondre à cette question, si tel est leur bon plaisir...
Soit dit en passant, mon intention, à travers ce journal, n'a jamais été de laisser entendre que XUL(Runner), avec ou sans C++, puisse, ou non, être supérieur à d'autres technologies similaires ...
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
Sans entrer dans un débat JavaScript vs C++, il se trouve que je dispose d'outils, qui sont d'ailleurs utilisés dans l'application citée dans ce journal, grâce auxquels je mets nettement moins de temps à implémenter un 'truc' en C++ qu'en JavaScript, et que je ne suis probablement pas le seul, d'où ce journal.
disclamer : je fais du xpcom c++ depuis des années...
Moi aussi. Et ?
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Ça apporte peut-être peu, mais certainement pas rien en terme de performances, vu qu'on évite la surcouche JavaScript. Néanmoins, les performances ne sont pas, à mon avis, le critère déterminant. Il se trouve que, pour moi (et certainement pour d'autres, d'où ce journal), la productivité, la facilité de développement et de maintenance sont nettement plus élevés en C++ qu'en JavaScript.
Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement'
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Sauf que cette page est résolument orientée JavaScript, avec des exemples, alors que pour C++, il faut procéder par déduction en fouillant également dans les fichiers d'entête C++ fournis avec le SDK XULRunner.
Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
(Je vais m'abstenir de répondre à ce propos, d'une part parce qu'il est hors-sujet, et, d'autre part, parce que ma précédente intervention sur le sujet ayant été prise au pied de la lettre).
M'enfin chacun utilise ce qu'il veut :-)
On est bien d'accord, c'est pour cela que j'utilise C++ à la place de JavaScript, et si d'autres préfère JavaScript, grand bien leur fasse :-) !
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
Comme dit dans un précédent commentaire, étant donné que l'API JavaScript de XULRunner n'est qu'une surcouche à des objets C++, cela ne me semble totalement dénué de sens de court-circuiter JavaScript pour accéder à ces objets directement en C++, d'autant plus si l'on n'a aucune affinité avec JavaScript...
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++. Comme en JavaScript, on a toujours un gestionnaire d'évènement à implémenter, mais il sera implémenté en C++. Et tout le code de l’application est effectivement dans une bibliothèque externe.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
Je connais cette documentation (XPCOM), et l'ai abondamment utilisée. Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement', et que pour avoir l'index de l’élément sélectionné dans ce 'tree', il fallait d'abord faire un 'GetView(...)', sur le résultat duquel il faut ensuite faire un 'GetSelection(...)', sur le résultat duquel il faut faire 'GetCurrentIndex(...)'. Quand à 'js-ctypes', c'est apparemment essentiellement pour faire du C...
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
(Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?)
expp est conçu pour réaliser des transformations beaucoup moins importantes que XSLT (que j'utilise par ailleurs quotidiennement, mais dans un tout autre contexte d'utilisation).
Typiquement, je m'en sert pour gérer un jeu de fichiers de configurations ayant peu de différences entre eux, différences essentiellement dues au fait qu'ils sont destinés à un même logiciel, mais installé sur des systèmes d'exploitation différents. Grâce à la gestion des macros et des variables proposée par expp, je n'ai qu'un seul fichier de configuration à maintenir, à partir duquel je génère les variantes propres à chaque système d'exploitation.
Le fait que les différentes directives sont situées directement dans le fichier à transformer, à l'endroit même où elles vont agir (contrairement à XSLT où elles doivent être situées dans un fichier distinct), permet d'un simple coup d'œil de voir leurs effets.
Les timecodes sont des indicateurs que l'on retrouve dans les logiciels (et appareils) qui manipulent des données audio (comme Audacity) ou vidéo (comme VirtualDub). Ils permettent d'identifier et de marquer temporellement chaque image d'une séquence vidéo, ou chaque échantillon d'une séquence sonore.
Si l'on veut, par exemple, synchroniser un feu d'artifice avec une bande sonore, on affectera à chaque évènement du feu d'artifice (lancement des différentes fusées) un timecode de la bande sonore. Plus précisement, sachant qu'une fusée explose X s aprés sont lancement, et que l'on veut faire correspondre cette explosion avec l'échantillon de timecode Y correspondant à un coup de cymbale, on utilisera un calculateur de timecode comme etmccalc pour savoir à quel timecode (donc à quel moment) il faudra lancer la fusée (résultat de Y-X).
Pour l'instant, etmccalc ne permet que d'additionner des timecodes et de convertir des timecodes d'un format à l'autre. A terme, on pourra faire des calculs plus complexes.
En outre, on n'est pas obligé d'utiliser le logiciel en tant que tel. Les sources fournies comprennent également celles de la bibliothèque de manipulation des timecodes (mthtmc), que l'on peut utiliser pour développer ses propres logiciels ...
A propos des DRM, Microsoft veut les étendre à tout type de document. Ainsi, une entreprise pourra envoyer un e-mail à ses clients avec une date limite de lecture, et impossibilité d'imprimer ou de dupliquer. De la sorte, si l'entreprise augmente ses tarifs, elle pourra toujours le nier face à un client s'en plaignant, vu que le client en question ne sera plus en mesure de produire le moindre document pour appuyer ses dires ...
A propos de Windows 2008 Server, j'ai eu l'occasion d'entendre hier un employé de Microsoft en parler. Il y a, paraît-il, deux modes de fonctionnement de Windows 2008 Server, mode que l'on choisit à l'installation (impossible de passer d'un mode à l'autre sans tout réinstaller) : le mode classique et, ... le mode sans GUI (enfin presque). Comme quoi, il arrive même à Microsoft de faire parfois preuve d'un peu bon sens :-) !
Pour rester avec les allemands, on peut aussi citer Richard STRAUSS, dont tout le monde connait l'introduction de son 'Ainsi parla Zarathustra', popularisé pas le film '2001, odyssée de l'espace', (dans lequel on peut également entendre 'Le beau danude bleu', de son homonyme autrichien). Outre donc son 'Ainsi parla Zarathustra', j'aime bien son 'Mort et transfiguration', ou encore sa 'symphonie alpestre' ...
[^] # Re: Il y a Bach sans Gould et Bach avec Gould...
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 7.
Pas tout à fait.
En musique, la vélocité fait référence à la capacité d'un interprète à exécuter une œuvre à grande vitesse.
En informatique musicale (notamment dans le cadre de la norme MIDI), la vélocité fait référence à la vitesse (donc indirectement à la force) à laquelle une touche d'un clavier est enfoncée. Généralement, le générateur produit un son d'autant plus fort (en fonction d'une courbe prédéfinie) que la touche est enfoncée rapidement. Selon le degré de sophistication du générateur, le volume sonore n'est souvent pas le seul paramètre modifié ; il peut y avoir également, entre autres, modification du timbre.
Parler de dynamique me paraît plus approprié. C'est l'un des principaux apports du piano, d'où son nom originel, le piano-forte.
Zelbinium, la programmation ludique
# Compiler pour le Nokia N900 (ARMv7)
Posté par Claude SIMON (site web personnel) . En réponse au journal Chaine(s) de compilation ARM. Évalué à 6.
Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.
Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !
Zelbinium, la programmation ludique
# Logiciel de gestion documentaire mutiplateforme
Posté par Claude SIMON (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 10.
Comme retour d'expérience, je peux évoquer un logiciel de gestion documentaire que j'ai développé (et sur lequel je travaille encore pour apporter des améliorations), et qui est déployé chez plusieurs clients.
Ce logiciel est composé de 2 parties. Une partie prenant en charge le traitement (appelé 'backend'), et une partie prenant en charge l'interface (appelée 'frontend').
Le 'backend' est développé en C/C++ (j’entends par là en utilisant le langage C++, mais avec uniquement les bibliothèques systèmes et les bibliothèques C standards ; pas de bibliothèques C++). Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne, mais n'a pas été déployé (faute ce client en faisant la demande), également sous MacOS.
Le 'frontend' avec interface graphique native s’appuie sur XULRunner et est également développé en C/C++, avec mise en œuvre de XML, XSLT, XUL et XPCOM. Il tourne et est déployé chez des clients sous Windows. Il tourne également, sans avoir été déployé, faute de client en ayant fait la demande, sous Linux. Quand à MacOS, il y a une version en cours de développement. En fait, ça tourne, sauf qu'il n'y a pas de menus, à cause d'une particularité de MacOS (problème d'installation, qui devrait être résolu dés que j'aurais le temps de m'en occuper).
La particularité de ce logiciel, c'est qu'il a également un 'frontend' web, développé en natif (eh oui, ce n'est pas contradictoire). Ce 'frontend', qui prend la forme d'une CGI, a également été développé en C/C++, avec mise en œuvre de XML, XSLT et HTML . L'articulation des fonctionnalités étant identique pour le frontend web (CGI) et natif (XULRunner), une grosse partie du code est commun aux deux. Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne également sous MacOS, sans avoir été déployé, toujours faute de demande de la part des clients.
Concernant les plateformes mobiles, j'ai réussis à compiler et faire tourner l'application ('backend' ET 'frontend's) sous Maemo sur un Nokia N900, mais cela n'a évidemment jamais été déployé chez des clients :-> !
Pour résumer, on a donc là une application multiplateforme (Windows, Linux et MacOS) développée en C/C++, dont la partie interface graphique native s’appuie sous XULRunner. En étant discipliné et organisé, faire du développement multiplateforme en C/C++ ne pose absolument aucune difficulté. Concrètement, grâce à un framework maison, je développe mes logiciels sous Windows avec Visual C++, et, pour les faire tourner sous Linux ou MacOS, il me suffit de les recompiler sur la plateforme en question.
Pour avoir plus de détails concernant la mise en œuvre de XULRunner, je renvoie à un de mes précédents journaux (http://linuxfr.org/users/epeios/journaux/xulrunner-et-c).
Zelbinium, la programmation ludique
[^] # Re: Quand Windows change d'heure, les fichiers aussi
Posté par Claude SIMON (site web personnel) . En réponse au journal Bug de sauvegarde.. Évalué à 1.
Petit réserve concernant 'rsync'.
Il m'arrive de faire une sauvegarde complète de fichiers sous 'Windows', en utilisant 'rsync' sous 'Cygwin', à destination de la carte mémoire de mon smartphone branché via USB, en mode UMS donc. Je réalise ensuite régulièrement des sauvegardes incrémentales, toujours en utilisant 'rsync' sous 'Cygwin', mais en me connectant au smartphone (qui est sous 'GNU/Linux') par Wi-Fi.
J'ai dû écrire un script qui recule l'horodatage de modification des fichiers de 1 ou 2 heures, selon que l'on soit en heure d'hiver ou d'été, que je dois lancer immédiatement après la sauvegarde complète, sinon la première sauvegarde incrémentale transfère l’ensemble des fichiers, et non pas seulement ceux qui ont été modifiés depuis la sauvegarde complète.
J'ai cherché dans les options de 'rsync', mais je n’ai rien trouvé qui permette de me passer de mon script. Si quelqu'un à une idée…
Zelbinium, la programmation ludique
# Essai avec '<'
Posté par Claude SIMON (site web personnel) . En réponse à l’entrée du suivi caractère < qui coupe les commentaires. Évalué à 1 (+0/-0).
<fonctionne, du moins en prévisualisation. Par contre, le commentaire après<disparaît même en prévisualisation.Essai avec
<: avant < après.Essai avec
<: avantZelbinium, la programmation ludique
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 2.
Me voici ! :-)
Il m'arrive de développer des applications WEB, et, bien que j'utilise également C++ dans ce cas (ça va encore me valoir des remarques des pro-JavaScript, ça), je n'utilise pas XULRunner pour ces dernières.
Pour faire des applications WEB, le couple XULRunner + C++ n'est peut-être pas pas le plus adapté, puisqu'il faudrait fournir le code C++ compilé pour chaque plate-forme cible, alors que si l'application n'utilise que JavaScript, elle tournera d'office sur tout les plate-formes sur lesquelles tourne XULRunner.
XULRunner, je ne l'utilise donc que pour des applications pour lesquelles je veux fournir une interface native. Et j'en n'utilise que les éléments relatifs à la gestion de l'interface graphique. Pour tout le reste (gestion des fichiers, du réseau, du multitâche...), j'ai mes propres outils. Donc, que XULRunner, Qt ou autres technologies aient de supers outils pour gérer ces éléments, ça m'importe peu...
Zelbinium, la programmation ludique
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 4.
Cf. précédent commentaire.
XULRunner est écrit en C++. Son SDK fournit une API C++. Je crois que, de ce fait, on peut le qualifier de toolkit 100% C++. Il ne manque que la documentation adéquate pour l'utiliser en tant que tel, et ce sans un contournement d'aucune sorte.
C'est clair que, avec la démocratisation des technologies WEB, c'est effectivement ce coté WEB qui a été mis en avant, car susceptible de toucher le plus grand nombre de personnes. Il n'en demeure pas moins que XULRunner, de par sa conception, est parfaitement adapté pour une utilisation avec C++ en lieu et place de JavaScript, n'était ce manque de documentation.
Zelbinium, la programmation ludique
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 5.
Parce que c'est hors sujet et que je ne saurais répondre à cette question, ne connaissant que très peu ces technologies !
Je ne veux, par ce journal, pousser personne à préférer XULRunner à d'autres technologies, mais s'il se trouve quelqu'un qui, quelles qu’en soient les raisons, décide d'utiliser XULRunner en combinaison avec C++, ce journal l'informe simplement de l'existence d'une source d'informations, que j'espère pertinentes, sur le sujet.
Accessoirement, pour ce que j'en ai lu, Qt Quick n'existait pas lorsque j'ai été amené à choisir XULRunner.
Zelbinium, la programmation ludique
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 3.
Pour ma part, ne ne connaissant guère ces deux technologies, je ne saurais répondre. Je laisserais donc aux connaisseurs le soin de répondre à cette question, si tel est leur bon plaisir...
Soit dit en passant, mon intention, à travers ce journal, n'a jamais été de laisser entendre que XUL(Runner), avec ou sans C++, puisse, ou non, être supérieur à d'autres technologies similaires ...
Zelbinium, la programmation ludique
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 2.
Voir mon précédent commentaire.
Zelbinium, la programmation ludique
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 3.
Sans entrer dans un débat JavaScript vs C++, il se trouve que je dispose d'outils, qui sont d'ailleurs utilisés dans l'application citée dans ce journal, grâce auxquels je mets nettement moins de temps à implémenter un 'truc' en C++ qu'en JavaScript, et que je ne suis probablement pas le seul, d'où ce journal.
Moi aussi. Et ?
Ça apporte peut-être peu, mais certainement pas rien en terme de performances, vu qu'on évite la surcouche JavaScript. Néanmoins, les performances ne sont pas, à mon avis, le critère déterminant. Il se trouve que, pour moi (et certainement pour d'autres, d'où ce journal), la productivité, la facilité de développement et de maintenance sont nettement plus élevés en C++ qu'en JavaScript.
Sauf que cette page est résolument orientée JavaScript, avec des exemples, alors que pour C++, il faut procéder par déduction en fouillant également dans les fichiers d'entête C++ fournis avec le SDK XULRunner.
(Je vais m'abstenir de répondre à ce propos, d'une part parce qu'il est hors-sujet, et, d'autre part, parce que ma précédente intervention sur le sujet ayant été prise au pied de la lettre).
On est bien d'accord, c'est pour cela que j'utilise C++ à la place de JavaScript, et si d'autres préfère JavaScript, grand bien leur fasse :-) !
Zelbinium, la programmation ludique
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 1.
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Comme dit dans un précédent commentaire, étant donné que l'API JavaScript de XULRunner n'est qu'une surcouche à des objets C++, cela ne me semble totalement dénué de sens de court-circuiter JavaScript pour accéder à ces objets directement en C++, d'autant plus si l'on n'a aucune affinité avec JavaScript...
Zelbinium, la programmation ludique
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 7.
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++. Comme en JavaScript, on a toujours un gestionnaire d'évènement à implémenter, mais il sera implémenté en C++. Et tout le code de l’application est effectivement dans une bibliothèque externe.
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
Je connais cette documentation (XPCOM), et l'ai abondamment utilisée. Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement', et que pour avoir l'index de l’élément sélectionné dans ce 'tree', il fallait d'abord faire un 'GetView(...)', sur le résultat duquel il faut ensuite faire un 'GetSelection(...)', sur le résultat duquel il faut faire 'GetCurrentIndex(...)'. Quand à 'js-ctypes', c'est apparemment essentiellement pour faire du C...
(Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?)
Zelbinium, la programmation ludique
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 3.
C++ n'est employé qu'en lieu et place de JavaScript. Toute la partie description de l'interface reste en XUL...
Zelbinium, la programmation ludique
[^] # Re: XSLT?
Posté par Claude SIMON (site web personnel) . En réponse au journal Nouvelle version du préprocesseur XML 'expp'. Évalué à 4.
expp est conçu pour réaliser des transformations beaucoup moins importantes que XSLT (que j'utilise par ailleurs quotidiennement, mais dans un tout autre contexte d'utilisation).
Typiquement, je m'en sert pour gérer un jeu de fichiers de configurations ayant peu de différences entre eux, différences essentiellement dues au fait qu'ils sont destinés à un même logiciel, mais installé sur des systèmes d'exploitation différents. Grâce à la gestion des macros et des variables proposée par expp, je n'ai qu'un seul fichier de configuration à maintenir, à partir duquel je génère les variantes propres à chaque système d'exploitation.
Le fait que les différentes directives sont situées directement dans le fichier à transformer, à l'endroit même où elles vont agir (contrairement à XSLT où elles doivent être situées dans un fichier distinct), permet d'un simple coup d'œil de voir leurs effets.
Zelbinium, la programmation ludique
[^] # (Rien à voir ...)
Posté par Claude SIMON (site web personnel) . En réponse au journal Suite bureautique : microsoft passe au gratuit. Évalué à 6.
(Désolé ...)
Zelbinium, la programmation ludique
[^] # Re: Honte
Posté par Claude SIMON (site web personnel) . En réponse au journal La flamme olympique : éteinte. Évalué à 3.
N'était-ce pas plutôt "C dans l'air" ?
Zelbinium, la programmation ludique
[^] # \<em\>
Posté par Claude SIMON (site web personnel) . En réponse au journal Sortie de etmccalc 0.7.0. Évalué à 2.
Zelbinium, la programmation ludique
[^] # Re: Kamoulox ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Sortie de etmccalc 0.7.0. Évalué à 3.
Si l'on veut, par exemple, synchroniser un feu d'artifice avec une bande sonore, on affectera à chaque évènement du feu d'artifice (lancement des différentes fusées) un timecode de la bande sonore. Plus précisement, sachant qu'une fusée explose X s aprés sont lancement, et que l'on veut faire correspondre cette explosion avec l'échantillon de timecode Y correspondant à un coup de cymbale, on utilisera un calculateur de timecode comme etmccalc pour savoir à quel timecode (donc à quel moment) il faudra lancer la fusée (résultat de Y-X).
Pour l'instant, etmccalc ne permet que d'additionner des timecodes et de convertir des timecodes d'un format à l'autre. A terme, on pourra faire des calculs plus complexes.
En outre, on n'est pas obligé d'utiliser le logiciel en tant que tel. Les sources fournies comprennent également celles de la bibliothèque de manipulation des timecodes (mthtmc), que l'on peut utiliser pour développer ses propres logiciels ...
Zelbinium, la programmation ludique
[^] # Re: Un article juste ?
Posté par Claude SIMON (site web personnel) . En réponse au journal C'est la guerre. Évalué à 1.
Zelbinium, la programmation ludique
[^] # Re: Un article juste ?
Posté par Claude SIMON (site web personnel) . En réponse au journal C'est la guerre. Évalué à 2.
Zelbinium, la programmation ludique
[^] # Re: encore des manquants
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel sont selon vous les meilleurs morceaux de musique classique ?. Évalué à 2.
Zelbinium, la programmation ludique
[^] # Re: Moi j'aime bien...
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel sont selon vous les meilleurs morceaux de musique classique ?. Évalué à 4.
Ça me fait penser à un certain Torvalds et son Linux :-) !
Zelbinium, la programmation ludique
[^] # Re: Compositeurs français
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel sont selon vous les meilleurs morceaux de musique classique ?. Évalué à 1.
Zelbinium, la programmation ludique
[^] # Re: Chostakovitch ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel sont selon vous les meilleurs morceaux de musique classique ?. Évalué à 3.
Zelbinium, la programmation ludique