Je suis assez d'accord avec Zenitram: je pensais qu'on allait "bêtement" me proposer de télécharger une VM, mais non il faut se coltiner ownCloud/nextCloud. Dans ces conditions, je suis limite plus tenté par compiler une version moi-même, mais qui fera cet effort ?
Après je comprends le dilemme de la boîte qui a fait le dév en 100% FOSS, mais veut quand même tirer ses marrons du feu. Ce n'est pas un business model déconnant, mais ça explique le peu de publicité de la solution.
J'en déduis que tu n'as jamais compilé avec Mono, ce qui me dérange moins que tu n'aies pas saisi l'indice laissé en police code ;).
Les exécutables produits par Mono portent l'extension .exe, les bibliothèques .dll ; ce n'en sont pas pour autant des exécutables Windows (=PE), ni même Linux (=ELF) ; mais .NET CIL, çàd cross-platform.
Tu pourrais retirer l'extension, qui est surtout utile pour l'association MIME avec l'interpréteur Mono -utilisée au double-clic ou via le lanceur GNOME/KDE, à la manière du .jar de Java :
java -jar <fichier>.jar
et maintenant je pense que tu as saisi l'indice ;).
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) ?
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.
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.
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!
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.
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)
[^] # Re: bizarre
Posté par Tarnyko (site web personnel) . En réponse au message Plus de GTK2 dans Xubuntu 20.04. Évalué à 0.
Je l'aurais parié !
[^] # Re: Bof
Posté par Tarnyko (site web personnel) . En réponse au journal C'est foutu pour LibreOffice. Évalué à 3. Dernière modification le 17 février 2021 à 17:35.
Je suis assez d'accord avec Zenitram: je pensais qu'on allait "bêtement" me proposer de télécharger une VM, mais non il faut se coltiner ownCloud/nextCloud. Dans ces conditions, je suis limite plus tenté par compiler une version moi-même, mais qui fera cet effort ?
Après je comprends le dilemme de la boîte qui a fait le dév en 100% FOSS, mais veut quand même tirer ses marrons du feu. Ce n'est pas un business model déconnant, mais ça explique le peu de publicité de la solution.
[^] # Re: C'est pas faux
Posté par Tarnyko (site web personnel) . En réponse au journal C'est foutu pour LibreOffice. Évalué à 7.
Donc en fait, tu veux qu'on soit d'accord avec toi pour apaiser ta mauvaise conscience ;) ?
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 0.
J'en déduis que tu n'as jamais compilé avec Mono, ce qui me dérange moins que tu n'aies pas saisi l'indice laissé en police code ;).
Les exécutables produits par Mono portent l'extension .exe, les bibliothèques .dll ; ce n'en sont pas pour autant des exécutables Windows (=PE), ni même Linux (=ELF) ; mais .NET CIL, çàd cross-platform.
Tu pourrais retirer l'extension, qui est surtout utile pour l'association MIME avec l'interpréteur Mono -utilisée au double-clic ou via le lanceur GNOME/KDE, à la manière du .jar de Java :
java -jar <fichier>.jar
et maintenant je pense que tu as saisi l'indice ;).
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 1.
Tu es au taquet :).
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ù ;).
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 0. Dernière modification le 11 février 2021 à 11:31.
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" ;).
C'est ce que je retiens ; j'ai été voir AvaloniaUI, c'est plutôt joli et dans l'air du temps.
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 :).
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 1.
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) ?
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 1. Dernière modification le 10 février 2021 à 11:49.
Ah ouais, on découvre vraiment, à ce que je vois ;) ?
mono <fichier>.exe
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 1. Dernière modification le 09 février 2021 à 18:42.
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é.
[^] # Re: Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 0. Dernière modification le 09 février 2021 à 16:52.
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.
# Différent
Posté par Tarnyko (site web personnel) . En réponse au message try catch et sigsegv. Évalué à 0. Dernière modification le 09 février 2021 à 12:20.
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).
# Framework
Posté par Tarnyko (site web personnel) . En réponse au message Environnement de développement pour C#. Évalué à 1. Dernière modification le 09 février 2021 à 12:04.
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.
[^] # Re: Le dernier ?
Posté par Tarnyko (site web personnel) . En réponse au journal Screech bronsonnisé. Évalué à 0.
(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.
[^] # Re: Le dernier ?
Posté par Tarnyko (site web personnel) . En réponse au journal Screech bronsonnisé. Évalué à 1.
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
[^] # Re: Objective-C aujourd'hui
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 0.
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.
[^] # Re: Objective-C aujourd'hui
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 0.
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.
# Un peu tard
Posté par Tarnyko (site web personnel) . En réponse au journal Assembleur de PC en France. Évalué à 7.
Article daté du
?????
[^] # Re: Laisser un commentaire
Posté par Tarnyko (site web personnel) . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 2.
Tu vas être au milieu des insultes anonymes et séquences AZERTYUIOP balancées d'un doigt rageur ;).
[^] # Re: Laisser un commentaire
Posté par Tarnyko (site web personnel) . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 1.
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!
[^] # Re: Laisser un commentaire
Posté par Tarnyko (site web personnel) . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 4.
Ah oui, effectivement… Ca me rappelle les heures les plus sombres du site de l'URSSAF…
# Laisser un commentaire
Posté par Tarnyko (site web personnel) . En réponse au message Où acheter des trajets SNCF courts que la SNCF refuse de vendre ?. Évalué à 5.
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 !
# Objective-C aujourd'hui
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 2.
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é ;).
[^] # Re: GNUstep
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 2.
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.
# Vala
Posté par Tarnyko (site web personnel) . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 2.
/me aiguise son glaive
Tu as quoi contre Vala, l'élégance du C# avec la performance du natif ^ ?
[^] # Re: Au business comme à la guerre
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 2. Dernière modification le 27 janvier 2021 à 23:08.
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)