Donc, en résumé:
- Les fichiers "Ressouces" que nous utilisons contiennent des collections d'objets relatifs à l'interface graphique, classés par type.
- Chaque type (ou presque) peut être édité par le programme "Resedit", abandonné par Apple depuis belle lurette
- Il est quasi impossible d'ajouter un nouveau type pour gérer des types objets supplémentaires
- Extraire les textes sous forme lisible, par exemple pour les traduire, nécessite un travail compliqué de manipulation sur le fichier "ressource"
L'idée est donc la suivante:
Remplacer la structure du fichier ressource macOS par un répertoire, contenant des sous-dossier pour chaque type d'objet, et un fichier par objet.
Définir un standard de sauvegarde textuelle de chaque type d'objet afin de pouvoir facilement examiner le contenu
Et enfin utiliser des éditeurs dont nous disposons, comme l'éditeur de boîtes de dialogue de MyrScript pour éditer les objets complexes, et au besoin créer des éditeurs spécifiques
Ceci nous permettra d'étendre les types d'objets, mais aussi d'éditer les éléments de l'interface sur Windows, ce qui n'est pas le cas actuellement.
Bon week-end !
|
|
|
| by Olivier Guillion |  |
| |
|
L'intégralité des fichiers de "ressources" ont été convertis en un ensemble de dossiers et de fichiers. Pour l'instant, les fichiers sont des blocs binaires, mais ils seront transformés en fichiers éditables selon le type de données qu'ils contiennent.
Une première version (de développement) d'Harmony fonctionne donc sans aucun fichier "ressource" au format Mac.
Plus de précisions techniques sur le format et la méthode demain. |
|
|
| by Olivier Guillion | |
| |
|
Les premières extractions de données des fichiers ressources ont été effectuées. L'occasion de remarquer que Windows permet de créer sans problème des fichiers contenant des caractères invalides (p.ex "*"), ce qui les rend impossible à supprimer ou renommer. Pour l'instant, nous les avons transférés dans un répertoire à part, en attendant de trouver le moyen de s'en débarrasser, si un tel moyen existe.
Non lié directement à nos produits, les derniers cafouillages de notre serveur de mail semblent avoir été corrigés. L'utilisation de données DNS non à jour empêchaient un envoi correct des messages vers yahoo.fr. Décidément... |
|
|
| by Olivier Guillion | |
| |
|
Le changement de serveur de mail est terminé. Nous avons pu vérifier que nos e-mails à yahoo.fr étaient acheminés, grâce à la boîte aux lettres persos de quelqu'un chez notre hébergeur.
Mais nous n'avons pas eu les réponses des clients contactés. Aussi, si vous avez une boîte à yahoo.fr, .ca, ou toute autre extension que .com, n'hésitez pas à nous contacter, on vérifiera que tout passe
De notre coté, nous avions deux problèmes sur nos outils internes :
- le logiciel maison de filtrage de courrier (élimination des spams, marquage des mails envoyés en plusieurs exemplaires, etc) se trompait lorsqu'il acheminait un mail réadressé entre les membres de notre équipe. Cela a été corrigé (modification de la DLL personnalisée)
- Une erreur dans le script d'envoi de mail permettant de commander les extensions de licence pouvait avoir pour conséquence la perte momentanée de l'espace MUSL. Si vous avez acquis l'extension de licence pour Harmony Assistant 64 bit, et que lorsque vous gérez voter espace MUSL depuis le logiciel, il vous demande de le créer, ne le créez pas, contactez-nous immédiatement |
|
|
| by Olivier Guillion | |
| |
|
Ceci nous concerne tous, en tant que consommateurs. À partir du 14 septembre 2019, l'utilisation du contrôle 3DSecure sera obligatoire pour tous les achats sur Internet en Europe et probablement ailleurs aussi.
Le 3DSecure, c'est cette étape supplémentaire qui vous demande de rentrer après chaque achat un code que vous recevez par SMS, ou d'aller chercher un numéro dans une grille donnée par votre banque, etc.
Ne croyez pas qu'il s'agisse de vous offrir une meilleure protection à vous, consommateur : la validation de ce contrôle vaut signature, ce qui signifie que vous ne pourrez pas contester l'opération (ou tout au moins, vous aurez plus de difficulté à obtenir gain de cause si vous le faites)
Au début, tout ceci a été un peu anarchique, chaque banque faisant à peu ce qu'elle voulait. Certaines, d'ailleurs, ne font rien, et la mise en place des contrôles 3DSecure sur notre boutique, actif depuis la semaine dernière, a des résultats extrêmement négatifs. Un nombre non négligeable d'achats n'aboutissent pas, le client ne sachant ou ne pouvant pas passer le contrôle 3DS.
Nous n'avons pas encore pu faire de statistiques, c'est un peu trop récent, mais le pourcentage de ventes "ratées" à cause de la mise en place du système est très probablement à 2 chiffres.
On se dit que ça va aller en s'améliorant, puisque les consommateurs seront obligés de s'y mettre lorsque tous les sites marchands auront été obligés de l'adopter, mais en attendant, ça pique, et ça ne facilite pas la vie de nos clients potentiels.
Mais on n'a pas encore tout vu, car la mise en place de ce système avec un contrôle simple (SMS, etc) n'est qu'une première étape, avant d'imposer le 3DSecure 2 (3DS 2), avec un contrôle renforcé pour chaque achat, incluant des systèmes de reconnaissance de la personne (empreinte digitale, etc)
Pour pallier à un taux de fraude d'environ 0.1 à 0.2%, les banques ont imposé un système, qui, à son lancement, a fait perdre près de 40% de ventes aux premiers vendeurs qui l'ont mis en place. Les choses se sont améliorées depuis, mais le bilan reste, pour nous, franchement négatif. Mais malgré notre volonté d'assumer les fraudes pour ne pas perdre des ventes, nous sommes obligés de nous plier à la règlementation.
|
|
|
| by Olivier Guillion | |
| |
|
Il y a des jours comme ça...
Intrigués par certains clients qui nous envoyaient des courriers électroniques mais ne recevaient pas de réponse, nous nous sommes aperçus qu'ils avaient tous des adresses à yahoo.fr.
En remontant les fils de conversation, nous nous sommes rendu compte que le problème était là depuis des semaines, voire des mois. Ces personnes n'avaient jamais reçu les codes d'enregistrement qu'elles avaient acheté, ou nos réponses à leurs question. À l'étranger, les utilisateurs de btinternet.com semblaient aussi affectés, dans une moindre mesure.
On a donc commencé à réexpédier tous les mails destinés à ces personnes à partir d'une adresse alternative et un webmail.
En parallèle, nous avons contacté notre hébergeur qui a confirmé que notre serveur d'envoi de mail utilisait une technologie trop ancienne, incompatible avec les attentes de certains serveurs en matière de sécurité.
Il a donc fallu en urgence changer de système, ce qui a coupé les mails automatiques (rapports de problème, envoi de codes perdus, prise en compte des commandes de produits) pendant quelque temps.
Heureusement, notre hébergeur a été très efficace et la situation a été rétablie sans trop de pertes, a priori.
Maintenant le nouveau système mis en place, il nous faut l'utiliser pour nos envois de mails "classiques" et vérifier qu'il fonctionne. Ensuite, vérifier que les clients @yahoo.fr reçoivent maintenant nos courriers. |
|
|
| by Olivier Guillion | |
|
| |
|
Les fichiers "ressource" du Macintosh, petit à petit, ont commencé à montrer leurs limites.
D'abord, il n'était pas possible d'étendre facilement le lot de types de données proposées. Par exemple, les pointeurs souris étaient limités à des motifs de 16x16 pixels, d'abord en noir et blanc, puis étendus à la couleur avec MacOS 7 (de mémoire)
Inutile de penser à des pointeurs plus grands, ou avec des masques de transparence qui ne soient pas en tout ou rien.
Alors petit à petit, nous avons commencé à sortir les icônes, les pointeurs, etc des fichiers ressource pour les gérer nous-même, en les fournissant séparément dans des sous-dossiers.
De plus, Apple lui-même, avec Cocoa, a abandonné le système de fichiers ressources d'origine. Il continuait à le prendre en compte en lecture, dans les applications utilisant la couche de compatibilité "Carbon", mais l'éditeur de ressources lui-même, "Resedit", ne fonctionnait plus sur les nouvelles versions du système.
Et malgré les supplications des développeurs, Apple a préféré laisser le produit mourir plutôt que de le proposer en Open Source.
Pour éditer les boîtes de dialogue, les textes, etc, il fallait donc passer par Sheepshaver, un émulateur MacOS 9. Tout ça commençait à devenir un peu compliqué...
- À suivre - |
|
|
| by Olivier Guillion | |
| |
|
Au commencement du Macintosh, la question s'est posée de pouvoir stocker à part les informations liées à l'interface graphique du programme.
Les applications n'étaient plus des lignes de commande, mais présentaient des boîtes, des alertes, des icônes...
Apple a alors décidé que tous les fichiers pouvaient être divisés en deux parties distinctes. À partir d'un même nom de fichier, on pouvait ouvrir le "Data fork", qui contenait le code machine et les données de fonctionnement du programme, ou bien le "Resource fork", qui contenait l'ensemble des données de l'interface graphique : menus, boîtes, textes, icônes, pointeurs souris et bien d'autres choses.
Lorsque dans les années 90 nous avons créé la bibliothèque ACAM, qui nous permettait d'avoir une interface commune entre Mac et PC (à l'époque sous Windows 3.1), nous avons conservé le format défini par Apple.
Les fichiers sur PC n'ayant pas de "resource fork", nous avons créé des convertisseurs qui récupéraient toutes les données du resource fork sur Macintosh et les transformaient en un bloc de données lisibles sur PC.
Ensuite, pour l'ensemble des types de ressources, nous avons écrit, dans ACAM, les fonctions qui en extrayaient les informations utilisables par le programme
Nous travaillions alors comme ceci:
- Les éléments de l'interface étaient édités sur Macintosh exclusivement, à l'aide de l'utilitaire dédié d'Apple appelé "Resedit"
- Ils étaient stockés dans un fichier ressource Mac (un fichier sans data fork, avec exclusivement un resource fork contenant toutes ces données)
- Sur Mac, ce fichier était utilisé tel quel par le système, qui y retrouvait les éléments graphiques et autres dont il avait besoin
- Le fichier ressource Mac était ensuite converti en fichier de données lisibles sur PC, et transféré
- Sur PC, nous avions réécrit dans la bibliothèque ACAM toutes les entrées du système Mac qui lisaient les ressources. Le code source de nos programme ne "s'apercevait" donc pas qu'il était sur PC, la structure du code, les appels et les résultats étant identiques au système Mac.
-- À suivre -- |
|
|
| by Olivier Guillion | |
| |
|
PDFtoMusic: en version non-pro, les options du menu "Interprétation" sont décalées, empêchant d'utiliser la première option. Ce sera corrigé dans la prochaine mise à jour.
Nous avons entamé une grosse restructuration des fichiers de données d'interface du programme, qui contiennent les textes, icônes, boîtes, etc.
Le format utilisé jusqu'ici date des toutes premières versions du Macintosh (peut-être même du Lisa), et mérite d'être rafraîchi. Plus d'infos techniques demain. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, reprise après un très long week-end, donc journée passée à dépanner, conseiller, répondre aux e-mails (et ce n'est pas encore fini)
Beaucoup de clients perdent régulièrement les codes d'enregistrement de leur logiciel. Les mails d'enregistrement (que nous demandons à ne pas conserver sur le Webmail) se perdent, les feuilles imprimées se retrouvent dans la mauvaise chemise, etc
Alors, on n'a pas l'habitude de faire de la pub, mais on conseille à tous Keepass, petit coffre-fort électronique personnel qui conservera en sécurité vos codes d'enregistrement, mais aussi la totalité de vos mots de passe, pour tous les sites Web sur lesquels vous avez un compte.
Il vous restera à retenir un seul et unique mot de passe qui permettra d'ouvrir le coffre-fort et y piocher ensuite librement les informations dont vous avez besoin.
Beaucoup plus efficace que le carnet répertoire physique, et plus sécurisé que le fichier texte "passwords.txt" sur le bureau électronique 
|
|
|
| by Olivier Guillion | |
| |
|
Meilleures polices en envoie de mail.
Mac : Gestion de la palette systèmes "Visualiseur de clavier"
Mac : Tentative de connection avec la palette "Emoji et symbole" sans succés. |
|
|
| by Didier Guillion |  |
| |
|
Le dernier CD-R contenant nos produits en version non enregistrée a été expédié ce matin.
Avec le 64 bit (et le maintien des versions 32 bits), la taille des exécutables a été multipliée par plus de deux. La quantité de données à graver est d'1 Go, largement au-dessus des capacités d'un CD-R.
Passer au DVD ou au Blu-Ray ne valait pas le coup, pour des raisons financières, de stockage, de manutention, d'expédition et de durée de fabrication. Nous sommes donc restés jusqu'au bout au bon vieux CD-R de 700Mo, malgré les difficultés croissantes pour tout caser dessus, les versions macOS, Windows et Linux.
Donc, désormais, le seul support physique que nous continuerons à proposer est la clé USB, bien plus pratique, et qui fonctionne sur beaucoup plus de machines, les lecteurs CD/DVD/BluRay n'étant pas toujours fournis en standard. Le "CD Myriad" a disparu de nos bons de commande et de notre site.
Reste plus maintenant qu'à passer une annonce pour écouler notre stock de CD vierges 😅
|
|
|
| by Olivier Guillion | |
| |
|
Ajout de la commande d'export des listes du Jukebox en texte dans Melody Assistant
Mac : Les raccourcis clavier sur les menus font maintenant pulser les élément de la barre de menu. |
|
|
| by Didier Guillion | |
|
| |
|
Harmony Assistant / MyrScript : correction de problèmes dans le lancement d'un script depuis un autre script.
Bon week-end ! |
|
|
| by Olivier Guillion | |
| |
|
La version 'i' a été publiée.
Les disques images sur Mac sont maintenant un peu plus présentables :
A noter que de nombreux sites web expliquent comment générer ce genre de présentation et que cela fourmille d'erreurs.
La seule vraie référence que nous avons trouvé est celle de M Andy Maloney :
https://asmaloney.com/2013/07/howto/packaging-a-mac-os-x-application-usi ng-a-dmg/ |
|
|
| by Didier Guillion | |
| |
|
Amélioration des effets numériques de sortie (réverb & surround globaux): à certains volumes élevés, des craquements pouvaient se faire entendre
Dorénavant, la touche majuscules ne change l'échelle du contenu de la fenêtre que lors du redimensionnement de la fenêtre principale, et non celui de ses sous-fenêtres
Crash lors du chargement d'anciens fichiers utilisant un type particulier d'images incluses.
Linux : crash lors de la saisie temps réel avec le clavier de l'ordinateur.
Note: cette partie n'est toujours pas implémentée sur Linux mais ne crashe plus
Melody Player: lors de la sortie de l'application, des fichiers temporaires pouvaient demeurer, et finir par saturer l'espace
Nous préparons les versions HA 9.9.0i / MA 7.9.0i / P2M 1.7.0i / MP 6.6.0i et essaierons de les sortir demain |
|
|
| by Olivier Guillion | |
| |
|
Mac : gestion d'une erreur retournée par le gestionnaire de police.
Rétablissement du copier/coller de textes associés à la portée.
Mac : prise en compte de l'échelle définie dans la mise en page
Mac : mémorisation de la configuration de l'imprimante
Adaptation du grand mixeur au mode sombre. |
|
|
| by Didier Guillion | |
| |
|
Windows : épluchage des rapports de crash du week-end. Pour l'instant, pas de problème pouvant être reproduit. |
|
|
| by Olivier Guillion | |
| |
|
Mac : gestion de la touche Alt dans certains cas.
Mac : meilleure précision à l'impression
Mac : correction d'un problème empêchant les polices spéciales d'êtres embarquées en SVG et PDF
Bon week-end ! |
|
|
| by Didier Guillion | |
| |
|
PDFtoMusic: un clic sur le "tiroir" (aperçu des pages à droite de la fenêtre) amène la fenêtre à l'avant-plan
PDFtoMusic: l'export SVG/Myrweb affichait certaines lignes horizontales (ex: ligatures) en blanc au lieu de noir
|
|
|
| by Olivier Guillion | |
| |
|
|
