Tarnyko a écrit 404 commentaires

Tu es au taquet :).

Le but de .NET 5 (et le futur .NET 6) est de laisser tomber netstandard et le fait d'avoir plusieurs implémentations de .NET (.NET Framework, .NET Core, Mono, CoreRT, .NET Native, …)

Effectivement, ça commençait à être un peu le boxon ; on se serait cru chez Java ;).

Alors j'ai regardé le SDK .NET 5.0 ; et en téléchargeant les versions Linux/Mac, je constate que le sous-répertoire "shared/Microsoft.WindowsDesktop.App", contenant entre autres "System.Windows.Forms.dll" en est absent.

C'est donc un pas dans la bonne direction, si tout le monde peut avoir la même organisation de binaires provenant de la même source, il reste la couverture d'API qui est différente.
Une possibilité serait donc de fournir des implés UNIX de WPF/WinForms sur cettte 5.0.x, encouragé par l'idée de prendre le "best of Mono", et en commençant par ici.
Ça reste un taf conséquent, l'implé Mono historique tourne (quoique basée sur cette vieille carne de X11), et perso aucun client ne me le demande (du .NET plus récent).
Je laisse quand même ça ici au cas où ;).

Utiliser WinForms ou WPF en fait forcément un projet lié à Windows

En fait, et comme marqué ci-dessus, Mono fournit une implémentation multi-plateforme de WinForms.
Ce n'est par contre pas le cas pour WPF, d'où ma question. J'avais cherché sans succès à l'époque, tu m'apprends que ça n'a pas bougé.
Parmi les frameworks que tu cites, cela exclut mécaniquement ModernWpf/AdonisUI sous Nunux ; la chose est moins claire pour DarkUI (WinForms), où le dév a pris la peine de créer une section "win32", mais sans la rendre optionnelle dans le Makefile (un taf faisable, en tenant compte des spécificités de mono-winforms ?)

Dans tous les cas, je t'accorde que j'ai cité ci-dessus ne marche qu'avec Mono ; peut-on porter vers .NET Core ? La réponse est sûrement "mais oui, avec un taf conséquent" ;).

Bref, si on veut du vrai multiplateforme (et toujours en .NET Core), il y a AvaloniaUI qui est la meilleure option pour le desktop.
Le backend sous Windows est justement WPF.
Pour Linux, c'est GTK 3.

C'est ce que je retiens ; j'ai été voir AvaloniaUI, c'est plutôt joli et dans l'air du temps.

la suite de Xamarin Forms un truc bof orienté mobile au départ

Ne parlons surtout pas de Xamarin Forms ;).

En tout cas, je te remercie d'avoir pris le temps d'écrire tout ça ! Il est clair que tu suis le sujet de près, je me permettrai de te piquer les réfs si je bois rebosser avec :).

Alors ça, c'est intéressant !
Tes projets WPF étaient-ils cross-platform et si oui, quel implé WPF utilisais-tu sur macOS/Nunux (j'ai pas regardé depuis Mono 3.10) ?

Ah ouais, on découvre vraiment, à ce que je vois ;) ?

mono <fichier>.exe


Pas sûr que je pige bien, alors je fais un double shot:
- L'outil se builde en ligne de commande (Makefile/monoc) sans MonoDevelop. De mémoire, il était chatouilleux sur la version de Mono présente, il lui fallait pas forcément la dernière ;
- MonoDevelop lui-même, j'ai toujours installé son paquet, jamais compilé.

Pour t'épargner une prise de tête, je te file l'outil précompilé.

Mono le fournit bien depuis longtemps (c'est les paquets mono-winforms ou libmono-winforms).

J'ai retrouvé l'outil dont je parlais ; il s'agit de WinForms Designer que j'ai retrouvé dans mes archives sous le nom de mono-mwf-designer . De mémoire, il est compliqué à builder ; fais-moi savoir si tu n'y arrives pas et je t'enverrai une version.

Les signaux UNIX et exceptions C++ sont deux notions différentes.

Le bloc try/catch te permet de gérer les exceptions C++ runtime sur tous les OS, comme une division par zéro ou un cast invalide.

Cas typique : tu chopes l'élément d'une collection par retour de fonction, tu essaies de le caster dans un type connu, ça pète, tu essaies de le caster dans un autre, etc…

Les signaux UNIX (dont le SIGSEGV correspond aux erreurs de segmentation) sont une notion plus bas niveau, propre à l'OS, et le code sera forcément propre à ces systèmes
(il existe bien un namespace std::signal mais j'ignore comment il se comporte sur d'autres OS).

Maintenant, il me faut passer à des applications graphiques avec boutons, zones de texte, tout ça…

Tu ne précises pas quel framework tu veux utiliser pour ce faire.

Il y a en plusieurs en fonction de ton look/cible:
- WinForms (look historique "Windows 9x") présent depuis .NET Framework 2.0/Mono 2 ;
- WPF (look "Office 2007") présent depuis .NET Framework 3.0 ;
- GTK# (utilise GTK+2) ;
- …

Quand j'étais actif dans le domaine, Mono supportait WinForms et GTK# mais pas WPF, et MonoDevelop n'avait aucun designer GUI viable (il fallait un outil externe).
Anecdote : MonoDevelop lui-même est en GTK#.
J'ignore totalement ce qu'il en est de .NET Core.

(oui, je m'auto-réponds, c't'un cas légal)
Hébé, vu! Ça faisait longtemps, ce genre de… divertissement. J'ai beau avoir perdu facile 2 points de Q.I., je regrette pas de l'avoir fait -mais juste une fois hein, pour la science, comme Gary et Wyatt.

Nom d'un Bitcoin, j'ignorais !
C'est pour ce genre d'info ultra-pointue que je viens sur LinuxFR !
/me va feuilleter sa filmothèque

Un AZERTY évidemment… bon j'admets, l'exemple était le plus mal choisi des points d'investissement envers Objective-C -qui n'étaient pas forcément "payés" en terme de productivité et résultats.

Alors écoute, à l'époque je développais sur Nunux ; mais effectivement je viens d'essayer sur un clavier MacBook, et le fait qu'[] s'obtienne avec [Alt]+[Shift]+() n'aide VRAIMENT pas.
C'est un détail hein, je suppose qu'un dév régulier aura son layout sur mesure ; mais ça fait partie des points notés à la 1ère tentative.

Article daté du

22/08/2006 à 19h11

?????

Tu vas être au milieu des insultes anonymes et séquences AZERTYUIOP balancées d'un doigt rageur ;).

Bon, j'ai réussi à laisser un commentaire à ta place. En voici le texte :

Je veux acheter un billet de train Lyon Part-Dieu vers Couzon-Au-Mont-d'Or ; avec une correspondance par Albigny-Neuville. Le trajet existe, mais Lyon Part-Dieu est toujours remplacé par Lyon Vaise.

Ma vision d'informaticien : il n'a pas aimé un caractère spécial (le ">" ?).
Bon après, l'absence de champ "contact", qui ne permet pas de revenir vers toi, fait vraiment ressembler ça à une bouteille à la mer. Yapukattendre!

Ah oui, effectivement… Ca me rappelle les heures les plus sombres du site de l'URSSAF…

Quand tu arrives sur la page "Votre trajet n'a pas été trouvé" (par exemple, en essayant de forcer la correspondance avec Albigny-Neuville) ; il y a sur la même ligne un lien menant vers une FAQ, et en bas de la FAQ une section "Votre cas ne correspond pas" où tu peux laisser un commentaire.
Tu devrais essayer cette manière d'ouvrir un bug !

Bon pas vraiment aujourd'hui, mais il y a 3 ans ; à titre d'exercice rigolo, j'avais essayé de créer un outil IHM multi-plateforme (Mac/Linux/Windoze) avec Objective-C/GNUstep.

Passons sur les bugs Winwin, compréhensibles pour un projet aussi peu backé.

Passé le côté rigolo d'utiliser une nouvelle syntaxe ET des classes Cocoa, il en ressort que :
- les gimmicks d'Objective-C ([:]-+) ne sont pas pratiques à enchaîner au clavier ;
- les définitions d'IHM sont ultra-verbeuses et répétitives. Tu sens le truc qui n'a pas été pensé pour être écrit en code, mais plutôt auto-généré dans des fichiers .nib via un IDE genre XCode (bien plus qu'en GTK+/Qt, où tu peux avoir une IHM fonctionnelle en une 10aine de lignes) ;
- les facilités "objet" d'Objective-C sont très en retard comparé à C#/C++. Tu sens le langage qui n'a pas bougé pendant 15 ans (ce que rappelle d'ailleurs l'article). Et comme elles sont peu mélangeables avec C++, tu finis par te demander si ce serait pas mieux d'écrire l'essentiel en C++ et reléguer l'Objective-C à des unités purement "IHM".

Donc voilà, marrant à essayer, mais je ne le recommanderais pas à un dév en 2021.
Pis de toute façon il est mort le gaillard, Swift l'a remplacé ;).

On m'a dit qu'Étoilé, déçu par le peu d'utilisation d'Objective-C, envisageait de forker. Malheureusement rien sur Freshmeat ni SourceForge pour l'instant.

Dino - Dommage que ce soit du Vala car c'est pas trop mal

/me aiguise son glaive
Tu as quoi contre Vala, l'élégance du C# avec la performance du natif ^{^} ?

Ne pouvant modifier/supprimer mon commentaire, je remarque que ma traduction rapide "trial" peut aussi être remplacée par "évaluation", auquel cas il s'agirait simplement de promouvoir NeXT par étude comparative avant/après. Il n'empêche, ça reste croustillant.
(le texte précise bien qu'il le fait à condition que NeXt résolve une ancienne affaire de royalties où ils lui doivent de l'argent)

Merci pour le document, c'est passionnant. On y trouve des perles :

Tom Love, now a managing director at Morgan Stanley, was approached by Steve Jobs about purchasing NeXT workstations, and Love started a trial comparing Morgan Stanley’s existing development tools with NeXT’s.

Ma traduction tombée du camion : "Tom Love, devenu cadre chez Morgan Stanley, fut approché par Steve Jobs pour promouvoir l'achat de stations NeXT. Love instigua un litige notant des similitudes entre les outils de développement existant chez Morgan Stanley et ceux de NeXT."

Si ça c'est pas des techniques de corsaire ! Un bon petit cheval de troie en interne qui travaille pour M.iPod en loucedé (moyennant commission, sans doute). Bien sûr Morgan Stanley c'est pas la startup du coin, y a un budget litiges toussa, mais les méthodes de barbouze quoi !

Il y a deux écoles : d'une part Yabasanshiro

Merci pour la citation, j'ignorais l'existence de celui-ci (me limitant à SSF pour une compat' maximale).

suite à la perte du code source de l’auteur, lui‑même finalement piégé par sa propre politique en la matière

Commentaire un peu H.S. ; mais pour avoir 4 exemples en tête (2 sur un logiciel "public", 2 dans un contexte professionnel), je suis toujours stupéfait quand ce genre de choses se produit.

Le code source d'un logiciel de cette envergure, si EN PLUS il n'est pas hébergé à l'extérieur, tu prends les précautions nécessaires pour pas le perdre. Au même titre que le rendre fonctionnel (je parle même pas de sa qualité), c'est le critère n°1 du sérieux d'un développeur !

À deux semaines près ; je vais bientôt être l'heureux possesseur d'un Acorn Archimedes A3010.
C'est une machine qui m'a toujours fasciné, par son exotisme mais aussi sa parenté architecturale avec nos smartphones modernes.

On peut installer un Linux 2.0.31 dessus ; dans ce cas, l'ABI est la même que sur un Linux 2.x ARM "classique". Les binaires sont donc transférables. Par exemple, ce code une fois "assemblé" marchera à la fois sur Archimedes et une autre carte ARM :

    message:
     .ascii "Salut !\n"

    .global main

    main:
      mov r0,#1        /* put 1 in R0 : stdout */
      ldr r1,=message  /* put buffer address in R1 : string */
      mov r2,#8        /* put 8 in R2 : string length */

      /* OABI : write() syscall */
      swi #9437188

Sur un Linux plus récent, non seulement l'alignement change (on passe de l'architecture "arm" à "armel" par défaut sur Debian), ce qui fait que le binaire ne se transfère plus; mais en plus on passe de l'OABI historique à l'EABI, ce qui implique de changer le syscall à la fin:

      /* EABI : write() syscall 4 */
      mov r7,#4 */
      swi #0

(ce qui, par ailleurs, marchera aussi sur Android).

RiscOS, lui, intègre carrément un éditeur pour exécuter de l'assembleur directement. Le format est bien sûr différent, et depuis le vieil Archimedes jusqu'à la récente Raspberry Pi, reste constant grâce à des genres de macros :

           SWI "OS_Write0"  ; display registry 0 content on console

C'est vraiment un excellent OS pour s'initier au bas niveau sur ARM ; un truc d'étudiant. Niveau écosystème soft, on est bien sûr bien loin derrière Tutux…