EX-TRA-OR-DI-NAIRE...

Mettre en avant comme cela le format SVG (mais pourquoi donc ce truc-là n’est-il pas plus magnifié ?) comme Framasoft le fait est plus qu’à son honneur : c’est GÉ-NIAL.

Pour mon métier, je travaille sur le SVG que je crois, depuis toujours, extrêmement prometteur et pas que pour de « simples » dessins vectoriels mais aussi pour des plans à l’échelle, éventuellement basculés sur du PDF pour une impression rigoureuse. Même si l’OpenDWG semble prometteur, tous ces formats vectoriels mettent des lustres à se propager dans le grand public et là encore, il faut remercier Framasoft de faire ce boulot.

J’avais déjà fait une démonstration SVG pour dessiner une façade d’orgue (disposition des tuyaux) à partir de relevés métiers que nous faisons, en tant que restaurateurs, particulièrement dès qu’il s’agit de « monuments historiques ».
http://hydraule.org/bureau/ordi/fac...
C’est évidemment très spécifique mais ça donne une idée de ce que l’on peut faire à partir de données numériques. Le SVG n’est pas hyper standardisé... Par exemple, si je donne à manger mes dégradés programmés « presqu’à la main » à l’ami LibreOffice-Draw, il ne les traitera pas correctement. C’est très dommage parce qu’on aimerait évidemment bien jouer avec par le truchement des macros de la bête qui possède l’avantage d’un tableur... Pour l’heure, j’ai repris le code produit par mon petit utilitaire de dessin de tuyaux d’orgues et collé dans « svg-editor » que Framablog me fait découvrir aujourd’hui. Et là c’est l’extase : il n’y a pas la moindre faute de transcription...

Tout de même, c’est dingue ce qu’on peut faire et ce que cela ouvre comme possibilités...

Se pose alors effectivement la question du stockage des données. Pour moi, il faut être très clair là-dessus : le cloud doit permettre de stocker ses données PUBLIQUES en ligne et ELLES-SEULES. C’est la raison pour laquelle il y a une évolution à apporter aussi pour la production de données stockées localement mais, plus encore, pour l’installation du logiciel lui-même en local. Je sais bien que c’est déjà parfaitement possible dans les deux cas et que la moindre distribution GNU-Linux possède bien entendu un LAMP. Mais il faut être encore sacrément « branché » pour faire une installation en en maîtrisant tous les domaines. Il faut du temps pour démocratiser tout cela ; les « WebApps » de la « Framakey » sont en version beta depuis 2009 et encore, elles fonctionnent généralement bien !

Donc ce n’est pas uniquement parce que « le fait est que les usages changent » que c’est une raison de suivre l’usage comme un mouton de panurge ; il est des usages empruntés par la masse qui sont détestables et, parmi eux, celui de pousser les gens à placer leur données hors de leur stricte responsabilité (en les crétinisant au maximum dans la mesure du possible) est une chose parfaitement condamnable et que l’on paiera très cher en matière de Liberté alors qu’on nous prétend évidemment le contraire. De même, installer des applications ou télécharger des logiciels, c’est exactement la même chose, même si ça ne se fait pas sur le même type de machine. Donc il me semble nécessaire de donner plus d’arguments pour étayer l’avantage du navigateur.

L’interface Web, déjà utilisée pour un traitement de texte ou pour un tableur prouve ici sa puissance ; et c’est proprement hallucinant de se rendre compte qu’à terme, on peut imaginer l’évolution des navigateurs faisant presque complètement fi des systèmes d’exploitation (mais pas des systèmes de fichier locaux, hein !). Et là, c’est un grand « ouf » pour le programmeur, à fortiori s’il n’est, comme moi, que juste dilettante. Bien entendu, les « contrôles » autant que leurs propriétés doivent sans doute être complétés de fonctionnalités qu’ils n’ont pas à ce jour. Mais tout de même, savoir qu’un formulaire métier aussi spécifique que celui-ci :
http://hydraule.org/bureau/ordi/ple...
avec une grille (composition) de lignes / colonnes variables, avec des cellules qui doivent être uniquement remplies de données spécifiques extrêmement formatées, sachant que le DOM permet de modifier la page elle-même sans avoir à la recharger, que ce support déroulant permet de contenir tout et n’importe quoi, actif ou inactif, relié, par exemple, par de l’hyperlien qui permet tous les didactismes possibles, tout cela sans vraiment se poser la question de la portabilité, c’est quand même, croyez-moi, une option non négligeable, et pas seulement pour se trouver dans une niche métier ! Plus j’avance dans ma découverte de la programmation, plus je me dirige vers cela, sachant que je n’ai pas (ou très peu) à me poser la question de savoir si mon programme va fonctionner sur Mac, sachant qu’il est autant hors de question que je touche à ce machin comme je sais parfaitement certains collègues en être inconditionnels !

Donc ces applications Web peuvent AUSSI faire figure de sorte de « bibliothèque » dans le cadres d’applications de plus grande envergure ou, pour mon cas, spécifiques à un métier. Fabriquer du SVG spécifique d’un côté c’est une chose ; mais savoir qu’on peut adjoindre tout un pan de retouche sans avoir à pondre la moindre ligne de code, c’est pour le moins encourageant... Enfin, (et cela ne s’applique pas ici à « svg editor » dont la disposition est très classique), une application Web peut se payer le luxe de sortir du sempiternel modèle écran / barre de menu / barre d’icône. On a peu réfléchi sur le sujet, influencés que nous sommes par des interfaces homme/machine de plus en plus standardisées. Il n’empêche : il me semble que ce sont là des domaines qui n’ont pas finis d’être explorés.