Posté par xcomcmdr .
En réponse à la dépêche Sortie de Plasma 5.21 .
Évalué à 6.
Dernière modification le 17 février 2021 à 14:39.
Et c'est pareil sur Xfce ou tout autre environnement avec son propre ensemble d'applis. Or, de base j'ai toujours eu KDE qui consommait bien plus que Xfce (sauf si on parle de Xubuntu).
D'où ma question de départ.
KDE propose mille fois plus que Xfce. Xfce propose aussi ses propres bibliothèques et applications qui les réutilise, mais propose mille fois moins d'options et de fonctionnalités que KDE. A partir de là, qu'il nettement moins que Xfce me semble très peu probable.
On va pas mettre KDE sur un ordinosaure, mais plutôt Xfce ou LXQt…
Bref, c'est pas net ces impressions…
Si on veut être sérieux, on compare d'abord à nu, et ensuite avec des applis (en détaillant quelles applis, quelles versions, …).
Bah oui je défend Xfce.
Et puis ça me surprend énormément.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
(en fait, après avoir lancé quelques applis, avec la réutilisation des libs, il est dans bien des cas plus léger que XFCE!).
Ah ?
Un Xfce tout nu, c'est entre 50 et 70 Mo de RAM au démarrage (ça dépend ce qu'on met dans son/ses tableau(x) de bord(s)). Tu confonds pas avec Xubuntu-desktop ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Si Mono fourni une implémentation compatible de WinForms, ça devrait fonctionner je pense. Mais je n'ai pas testé.
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, …) et de réunir tout le monde sur une seule implémentation (.NET 5, 6, 7, …). Et il y arrive.
Ça porte déjà ses fruits en termes de perfs et de fiabilité pour Blazor WASM (qui en .NET Core 3.X utilisait Mono).
Donc je ne sais pas si à l'avenir Mono sera toujours maintenu.
Par contre, le port Mono de WPF est au point mort depuis toujours.
J'ai oublié de citer quelques petits projets qui tentent aussi de proposer un SDK multiplateforme pour les UI (surtout parce qu'ils sont très méconnus ou en version alpha) - liste non exhaustive: ImGui.NET (a l'air pas mal mais très réduit) Modern.Forms - version pré alpha d'un 'sucesseur' à WinForms en .NET Core, pour ceux qui veulent contribuer uniquement…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Pardon, j'ai cliqué sur inutile ! Je voulais cliquer sur pertinent !
Un modo peut-il passer réparer cela svp ?
Utiliser WinForms ou WPF en fait forcément un projet lié à Windows, même si WinForms et WPF sont désormais libres et open-source (en tant qu'add-on pour Windows à la base multiplateforme Linux/Mac/Windows qu'est .NET Core 3.1, désormais nommé .NET 5 pour la dernière release à ce jour).
Ils sont très liés aux APIs natives Win32, Direct3D9, WISP (API pour les écrans tactiles), Direct2D, GDI+, etc. …
C'est vrai pour mes projets, c'est vrai aussi pour les projets apportant des thèmes graphiques tels que ModernWpf ou AdonisUI ou DarkUI.
A la limite, on peut dire multiplateforme Windows pour certains (vu que j'utilise le support de Windows 10 pour les thèmes - pour déterminer si je m'affiche en thème Light ou Dark - s'il existe dans certains projets. Mais si ça n'existe pas (Windows 8 et antérieur), je m'affiche quand même).
Évidemment, le support des plateformes Windows antérieurs à Windows 10 reste propre à l'historique .NET Framework et ses implémentations propriétaires de WinForms et WPF.
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.
Mais dans tous les cas, le rendu est le même.
Le look de WinForms peut-être changé radicalement, bien que ça prenne beaucoup d'efforts.
Voir le projet DarkUI sur GitHub.
Quant au look de WPF, il est fait pour être changé facilement.
Des projets tels que ModernWpf ou AdonisUI lui font passer de son look 'Vista' à un look d'application ModernUI (Windows 10).
J'ai fait perso l'inverse, un projet WPF qui avait un look 'Windows 95' juste pour le fun (c'est un des thèmes présents nativement avec WPF, mais il faut l'activer 'à la main').
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Pour faire des GUI, tu as le choix entre AvaloniaUI, Uno, Blazor, et pas mal d'autres.
Tu n'as pas à t'embêter avec WinForms (et son clone linux 'compatible' mais moche MonoForms), c'est clairement dépassé et rétrograde (et le rendu par rapport à Windows est juste caca)
Pour le SDK, .NET Core 3.1 ou .NET 5 (voire .NET 6, la prochaine LTS en Décembre), s'impose clairement !
Moi je prendrais AvaloniaUI pour faire du desktop Linux/Mac/Windows. C'est le meilleur, et ça utilise .NET Core.
Sinon, pour développer VSCodium est très bien (fork de VSCode sans la télémétrie), mais pour faire des interfaces graphiques, rien ne vaut Visual Studio (tout court). Après, j'entends que du bien de Rider, mais je n'ai jamais testé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
C'est juste du natif sans toutes les emmerdes du C, et plus haut-niveau.
Ce n'est pas le premier, ni le dernier à le proposer. C'est juste que pour une fois, ça a l'air de tenir ses promesses.
Ce n'est pas parce que je peux créer des fuites mémoire en C#, Rust, ou autre, malgré toutes les protections et en un tour de main que je vais aller dire que c'est de la merde.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 3.
C'est pas le premier langage 'safe' et natif je crois, D et Pascal sont passés par là si je ne m'abuse…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 2.
Euh vous confondez pas simple et simpliste ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 3.
Oui je sais c'est pareil en dotnet, mais je voulais pas me faire moinsser par les haïsseurs de Rust.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi Rust ?
Posté par xcomcmdr . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 6.
Ben faut dire que résumer Rust à la memory safety, c'est comprendre 20% des garanties du bidule.
Évidemment dans ce cas là moi aussi j'en aurais marre.
Si y'a que la memory safety qui t'intéresse, y'a même pas besoin de sortir Rust. Java suffit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bof
Posté par xcomcmdr . En réponse au journal C'est foutu pour LibreOffice. Évalué à 3.
Pourquoi 'dommage' ?
CSharp / dotnet c'est libre depuis longtemps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toujours mieux ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à 6. Dernière modification le 17 février 2021 à 14:39.
Et c'est pareil sur Xfce ou tout autre environnement avec son propre ensemble d'applis. Or, de base j'ai toujours eu KDE qui consommait bien plus que Xfce (sauf si on parle de Xubuntu).
D'où ma question de départ.
KDE propose mille fois plus que Xfce. Xfce propose aussi ses propres bibliothèques et applications qui les réutilise, mais propose mille fois moins d'options et de fonctionnalités que KDE. A partir de là, qu'il nettement moins que Xfce me semble très peu probable.
On va pas mettre KDE sur un ordinosaure, mais plutôt Xfce ou LXQt…
Bref, c'est pas net ces impressions…
Si on veut être sérieux, on compare d'abord à nu, et ensuite avec des applis (en détaillant quelles applis, quelles versions, …).
Bah oui je défend Xfce.
Et puis ça me surprend énormément.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toujours mieux ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à -5.
Quels applis exactement ? Quelles mesures ?
Ben oui je pars de quelque chose de nu, car c'est pour établir d'abord une base.
Bref, ce que tu dis n'a aucune forme d'objectivité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Toujours mieux ?
Posté par xcomcmdr . En réponse à la dépêche Sortie de Plasma 5.21 . Évalué à -5.
Ah ?
Un Xfce tout nu, c'est entre 50 et 70 Mo de RAM au démarrage (ça dépend ce qu'on met dans son/ses tableau(x) de bord(s)). Tu confonds pas avec Xubuntu-desktop ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Framework
Posté par xcomcmdr . En réponse au message Environnement de développement pour C#. Évalué à 3. Dernière modification le 11 février 2021 à 17:24.
Si Mono fourni une implémentation compatible de WinForms, ça devrait fonctionner je pense. Mais je n'ai pas testé.
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, …) et de réunir tout le monde sur une seule implémentation (.NET 5, 6, 7, …). Et il y arrive.
Ça porte déjà ses fruits en termes de perfs et de fiabilité pour Blazor WASM (qui en .NET Core 3.X utilisait Mono).
Donc je ne sais pas si à l'avenir Mono sera toujours maintenu.
Par contre, le port Mono de WPF est au point mort depuis toujours.
J'ai oublié de citer quelques petits projets qui tentent aussi de proposer un SDK multiplateforme pour les UI (surtout parce qu'ils sont très méconnus ou en version alpha) - liste non exhaustive:
ImGui.NET (a l'air pas mal mais très réduit)
Modern.Forms - version pré alpha d'un 'sucesseur' à WinForms en .NET Core, pour ceux qui veulent contribuer uniquement…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: La faille entre la chaise et le clavier
Posté par xcomcmdr . En réponse au lien Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies. Évalué à 7.
[référence nécessaire]
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Framework
Posté par xcomcmdr . En réponse au message Environnement de développement pour C#. Évalué à 3. Dernière modification le 10 février 2021 à 22:30.
Pardon, j'ai cliqué sur inutile ! Je voulais cliquer sur pertinent !
Un modo peut-il passer réparer cela svp ?
Utiliser WinForms ou WPF en fait forcément un projet lié à Windows, même si WinForms et WPF sont désormais libres et open-source (en tant qu'add-on pour Windows à la base multiplateforme Linux/Mac/Windows qu'est .NET Core 3.1, désormais nommé .NET 5 pour la dernière release à ce jour).
Ils sont très liés aux APIs natives Win32, Direct3D9, WISP (API pour les écrans tactiles), Direct2D, GDI+, etc. …
C'est vrai pour mes projets, c'est vrai aussi pour les projets apportant des thèmes graphiques tels que ModernWpf ou AdonisUI ou DarkUI.
A la limite, on peut dire multiplateforme Windows pour certains (vu que j'utilise le support de Windows 10 pour les thèmes - pour déterminer si je m'affiche en thème Light ou Dark - s'il existe dans certains projets. Mais si ça n'existe pas (Windows 8 et antérieur), je m'affiche quand même).
Évidemment, le support des plateformes Windows antérieurs à Windows 10 reste propre à l'historique .NET Framework et ses implémentations propriétaires de WinForms et WPF.
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.
Mais dans tous les cas, le rendu est le même.
Il y a d'autres options (Bientôt .NET MAUI, mais le support Linux sera 'communautaire', et c'est la suite de Xamarin Forms un truc bof orienté mobile au départ), ou Uno (pas testé), ou Blazor (on peut faire des apps PWA avec par exemple, ou hoster Blazor WASM au sein de WebWindow2 mais c'est expérimental).
Bref, y'a l'embarras du choix : AvaloniaUI ou des trucs expérimentaux. :)
(Quant à faire fonctionner .NET Core sous FreeBSD ou autre, c'est une question de bras)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Framework
Posté par xcomcmdr . En réponse au message Environnement de développement pour C#. Évalué à 3.
Le look de WinForms peut-être changé radicalement, bien que ça prenne beaucoup d'efforts.
Voir le projet DarkUI sur GitHub.
Quant au look de WPF, il est fait pour être changé facilement.
Des projets tels que ModernWpf ou AdonisUI lui font passer de son look 'Vista' à un look d'application ModernUI (Windows 10).
J'ai fait perso l'inverse, un projet WPF qui avait un look 'Windows 95' juste pour le fun (c'est un des thèmes présents nativement avec WPF, mais il faut l'activer 'à la main').
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .Net Core
Posté par xcomcmdr . En réponse au message Environnement de développement pour C#. Évalué à 2.
Au bon endroit dans mon expérience sous linux avec Mono c'est pas le cas du tout (rendu très différent d'un projet WinForms par rapport à Windows).
Mais peut être que ça a changé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .Net Core
Posté par xcomcmdr . En réponse au message Environnement de développement pour C#. Évalué à 3. Dernière modification le 09 février 2021 à 20:28.
Il y a Rider : https://www.jetbrains.com/fr-fr/rider/
Pour faire des GUI, tu as le choix entre AvaloniaUI, Uno, Blazor, et pas mal d'autres.
Tu n'as pas à t'embêter avec WinForms (et son clone linux 'compatible' mais moche MonoForms), c'est clairement dépassé et rétrograde (et le rendu par rapport à Windows est juste caca)
Pour le SDK, .NET Core 3.1 ou .NET 5 (voire .NET 6, la prochaine LTS en Décembre), s'impose clairement !
Moi je prendrais AvaloniaUI pour faire du desktop Linux/Mac/Windows. C'est le meilleur, et ça utilise .NET Core.
Sinon, pour développer VSCodium est très bien (fork de VSCode sans la télémétrie), mais pour faire des interfaces graphiques, rien ne vaut Visual Studio (tout court). Après, j'entends que du bien de Rider, mais je n'ai jamais testé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: lolinpact
Posté par xcomcmdr . En réponse au lien Cookies et pistage des internautes : dernier coup de semonce de la CNIL, qui publie un observatoire. Évalué à 8.
Euh si c'est purement pour le fonctionnement du site, y'a rien à demander.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Documentaire sur Arte
Posté par xcomcmdr . En réponse à la dépêche Wikipédia : vingt ans déjà !. Évalué à 1.
AJA que l'Homme Blanc est une ethnie………
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Spoilers!
Posté par xcomcmdr . En réponse à la dépêche Logiciel libre : le Premier ministre se montrera-t-il à la hauteur du rapport Bothorel ?. Évalué à 5.
Non.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: classe BPM
Posté par xcomcmdr . En réponse au journal Port complet de TapTempo en C# 9. Évalué à 2.
Pierre Tramo approuve ! :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Liens manquants...
Posté par xcomcmdr . En réponse au journal Port complet de TapTempo en C# 9. Évalué à 5. Dernière modification le 11 janvier 2021 à 00:07.
Extension methods:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods
Top Level Statements :
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/exploration/top-level-statements
Un modérateur pourrait le rajouter, svp ?
Et un typo:
guuere/guerre
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tout nouveau projet de Lennart Poettering de réécriture de quelque chose d’existant
Posté par xcomcmdr . En réponse à la dépêche Bonne année 2021 !. Évalué à 3. Dernière modification le 03 janvier 2021 à 23:03.
20 ans après DirectShow. :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Jeu amusant : deviner à quoi correspondent les icones
Posté par xcomcmdr . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 6. Dernière modification le 03 janvier 2021 à 18:16.
Eh beh non pour moi. Le flat est illisible, me fait perdre du temps. Qui plus est, il est invariablement moche, sans saveur.
Et son existence n'a aucune justification à part l'effet de mode. La preuve, on vivait très bien sans lui.
A mort le flat.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Des fuites mémoires en Rust ?
Posté par xcomcmdr . En réponse au journal Sortie de Redox OS 0.6.0. Évalué à 4.
C'est juste du natif sans toutes les emmerdes du C, et plus haut-niveau.
Ce n'est pas le premier, ni le dernier à le proposer. C'est juste que pour une fois, ça a l'air de tenir ses promesses.
Ce n'est pas parce que je peux créer des fuites mémoire en C#, Rust, ou autre, malgré toutes les protections et en un tour de main que je vais aller dire que c'est de la merde.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: B-bye, Xfce
Posté par xcomcmdr . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 9.
Ça ne concerne que les outils propres au Gestionnaire de paramètres de Xfce.
Thunar ni xfce4-terminal n'en font pas partie.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Le lecteur multimédia de Xfce (nommé Parole) 4.16 arrive bient̂ôt
Posté par xcomcmdr . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 5.
Parole 4.15 (version de développement il y a quelques heures) vient d'être annoncé.
Au menu:
* Une bien meilleure compatibilité avec les DVD Video (notamment les menus)
* Une playlist améliorée
* des dialogues revisités
Source:
https://fossbytes.com/xfces-parole-media-player-4-15-0-released-with-improved-dvd-support/
Parole est toujours basé sur GStreamer.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi le choix GAFAM ?
Posté par xcomcmdr . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 1.
Il n'y pas de traçage sur GitHub.
Troll confirmé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)