Slint 1.0 est enfin sorti ! Il s'agit d'une boîte à outils (toolkit) open-source permettant de créer des interfaces utilisateur natives pour les applications de bureau et les écrans embarqués, implémenté en Rust. Cette sortie est le fruit de trois années de travail et a été aidée par 50 contributeurs sur GitHub.
Développement d'interface utilisateur simplifié
Slint utilise un langage déclaratif pour simplifier le développement de l'interface utilisateur. Cette approche permet d'optimiser le développement d'applications et les performances :
- L'interface utilisateur est décrite dans un langage déclaratif facile à lire, à écrire et à apprendre, avec une syntaxe détaillée pour décrire les différents éléments graphiques.
- Le compilateur Slint optimise et traduit la description de l'interface utilisateur en code natif.
- La logique métier peut être écrite dans un langage de programmation et est connectée à l'interface utilisateur à l'aide des API fournies par Slint.
Pour accélérer le processus de développement de l'interface utilisateur, Slint est accompagné d'un support pour les éditeurs utilisant le LSP (Language Server Protocol) pour l'autocomplétion, la navigation, le refactoring et la coloration syntaxique. Une des fonctionnalités intéressante est la "Live Preview" : une prévisualisation en temps réel. Si vous utilisez Visual Studio Code, vous pouvez installer l'extension Slint depuis le market officiel, ou openvsx. (L'extension fonctionne également dans le navigateur via https://vscode.dev ou https://github.dev).
Vous pouvez également essayer "SlintPad" : un éditeur et en ligne / playground dans votre navigateur.
Bien que Slint soit implémenté en Rust, il offre des API pour d'autres langages donc pas besoin de connaître le Rust. Il a des API en Rust, C++20 et JavaScript pour le moment et l'ambition de supporter plus de langages.
Interface native sur plusieurs plateformes
Slint est prévu pour fonctionner quasiment partout, quel que soit le système d'exploitation (OS) ou même pas d'OS du tout (bare-metal).
En effet, Slint fonctionne sur des micro-controleurs connectés à un écran qui ont moins de 300KB de mémoire (kilo, pas méga).
Pour les applications ordinateur de bureau, on utilise le style de la plateforme.
Buisness Modèle Open Source
La société derrière Slint s'engage envers l'Open Source.
Le projet est entièrement développé sur GitHub, où les rapport de bugs, les pull requests ou autres contributions sont acceptés.
Pour financer le développement, un modèle économique durable basé sur une double licence est utilisé. Slint est disponible sous licence open-source GPLv3 et sous licence propriétaire (la licence propriétaire est même gratuite sous la licence Ambassadeur).
Aller plus loin
- Blog d'Announce de Slint 1.0 (160 clics)
- Repository github (144 clics)
- Démos en ligne (337 clics)
- Documentation (70 clics)
- Journal précédent (32 clics)
# Ce n'est pas du natif
Posté par xryl669 . Évalué à 10. Dernière modification le 06 avril 2023 à 09:53.
Contrairement à ce qui est écrit, l'interface est tout sauf native. C'est du dessiné, comme GTK, QT et autre.
Par exemple, faîtes un click droit sur une zone texte, et vous n'aurez pas le menu classique de copier/coller des zones de texte.
Il émule l'UI native, pour ressembler à l'interface de l'hôte. Mais ça foire complètement sur les hôtes qui ne sont un minimum customisés. Donc sous Linux avec ses 10000 environnements graphiques, vous aurez du pseudo GTK, thème de base. Sous windows, faut pas avoir choisi un thème sombre, etc…
Sur le web, les zones textes ne supportent pas le copier/coller, les IME, etc..
Sur la version mobile de la démo web (et que sur celle-ci, pourquoi?) il utilise un truc pas kocher du tout: il met un < input > caché sous le canvas de dessin. Il donne le focus à l'input lorsqu'une zone de texte est sélectionné, pour faire apparaître le clavier virtuel.
Sauf que c'est toujours le même input quelque soit la zone de texte dans l'interface, donc exit tous les automatismes, genre gestionnaire de mots de passe, autofill, etc…
En gros, sauf pour l'embarqué, c'est assez inutile. Et pour l'embarqué, il y a LVGL qui est quand même LA référence.
[^] # Re: Ce n'est pas du natif
Posté par xoddark . Évalué à 1.
Merci pour les précisions.
M'intéressant un peu aux librairies/outils de GUI utilisable en Rust, je l'avais vu passer mais pas encore pris le temps de regarder plus en détails.
J'avais déjà des doutes sur le fait qu'il serait adapté à mon usage. Je vise plutôt l'édition de données, la création de contenu, que l'affichage de données.
[^] # Re: Ce n'est pas du natif
Posté par Aldebaran (site web personnel) . Évalué à 2.
De ce que j'ai lu on a le choix entre un backend graphique basé sur femtovg, skia, cpu et 'natif'; mais le backend natif est en fait le backend Qt, donc on hérite de ce que Qt sait faire et ne sait pas faire. Ceci dit, c'est souvent bien suffisant.
Surtout qu'en vrai, souvent quand on dit 'natif' c'est pour faire le distinguo entre ui web et ui classique; Le moteur de rendu de windows 'dessine' aussi ces widgets, tout comme Qt et GTK, ce ne sont juste pas exactement les mêmes.
Y a bien wxwidgets qui reprend les vrai composants dit natifs, mais c'est autre chose.
J'imagine qu'on pourrait développer un backend pour slint en wxwidgets, ou bien un backend par plateforme exploitant le toolkit natif.
Ceci dit, je suis plus intéressé par les possibilités de style non natives que propose Slint, Qml et le Web en ce moment. Moi pour le coup je m'en tamponne un peu que ce soit du vrai natif ou pas; Le grand avantage de ce framework c'est de proposer un langage d'IHM proche du QML avec les avantages du Rust pour la partie métier.
[^] # Re: Ce n'est pas du natif
Posté par Gof (site web personnel) . Évalué à 6.
Merci d'avoir passé du temps à regarder les détails.
Comme ce qui a été dit plus haut, par "natif", je fais l'opposition à "web" qui tourne dans un browser.
En effet, ce n'est pas encore implémenter. Il y encore beaucoup de travail à faire pour avoir tout les détails correct. Mais l'idée c'est qu'il est possible de l'implémenter.
Sous Linux ça utilise Qt, mais il faudra en effet utiliser un style GTK.
Par contre, Windows avec un thème sombre devrait fonctionner sans problèmes
La démo web est juste une démo, il fallait bien faire un truc qui marche.
Oui, en principe on pourrait rendre le tout avec le DOM plutôt que d'utiliser un canvas. Mais on ne fait pas ça pour le moment car le but de la démo web est just de montrer à quoi ça ressemble quad ça tourne en natif.
Oui, mais LVGL force à programmer l'interface en C de manière impérative est ça c'est pas idéal. L'idée est qu'avec Slint et son langage déclaratif il est bien plus facile et rapide de développer l'UI
[^] # Re: Ce n'est pas du natif
Posté par Zenitram (site web personnel) . Évalué à -1.
En redéfinissant les mots pour que ça fasse classe, c'est certes facile…
Ce n'est pas natif, c'est tout, il n'y a pas de mal à dire ce que vous faites en vrai sans y mettre du "web".
"Web", "dessiné", "natif", si on comprend bien ici c'est "dessiné" à la Qt, un peu mieux que "web" mais pas "natif".
Et la différence est importante surtout sous macOS où c'est très important d'utiliser l'API qui va bien car sinon on n'a toujours un truc qui ne passera pas pour plein d'utilisateurs, surtout quand l'UI change avec une nouvelle version de l'OS et que le "dessiné" se voit du coup (perso on lâché Qt pour ça sous macOS, malgré leur tentative de simuler l'UI macOS ça reste que ça se voit que ce n'est pas du natif).
[^] # Re: Ce n'est pas du natif
Posté par Gof (site web personnel) . Évalué à 4.
Ma définition de natif est aussi bonne que la tienne.
Ce qui est important c'est que ça aie le look&feel de la plateforme. La manière dont c'est implémenté importe peu.
(Tu pourrais critiquer que la ressemblance n'est pas parfaite, mais c'est une question d'effort et de souci du détail)
[^] # Re: Ce n'est pas du natif
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Plutôt que de parler de dessiné/natif, il faudrait parler de toolkit portable et toolkit fourni par l'OS.
A ma connaissance aucun toolkit portable n'a réussi à suivre les évolutions des toolkits fournis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ce n'est pas du natif
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 07 avril 2023 à 00:12.
Il manque d'après toi beaucoup à WxWidgets (qui marque "unlike other cross-platform toolkits, wxWidgets gives applications a truly native look", ils sont obligés de rajouter "truly" pour se différencier des "natif mais dessiné en fait")?
Je n'ai pas suivi après que j'ai lâché suite à retards mais d'après le dernier changelog ça a l'air d'essayer de rattraper ce retard (et surtout on a accès au handle natif et du coup on peut essayer de compenser quand il y a du retard et qu'on a le courage).
[^] # Re: Ce n'est pas du natif
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
J'ignorais de savoir qu'il était encore en vie !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ce n'est pas du natif
Posté par Philippe F (site web personnel) . Évalué à 10.
Le problème de WxWidget, outre le fait que le projet s'est quand même pris une bonne claque de vétusté, il traine pas mal de bug qui sont spécifiques à la plate-forme.
En fait, les toolkits natifs sont sans surprise hyper spécifique à leur plate-forme. Et les unifier derrière une interface unique, ça marche pas complètement. Tu tombes très vite sur des comportements spécifiques à une plate-forme, qui sont buggés sous une autre et très pénible à débugger car le chemin emprunté par le code n'est pas identique. Surtout que l'idée d'avoir une interface unique, c'est justement de moins passer de temps sur les spécificités des plateformes.
En fait, ce concept de toolkit d'interface graphique universelle est un problème très difficile à résoudre alors qu'il parait simple au départ. Pour un bouton, on croit déjà être capable de résoudre le problème alors que déjà c'est difficile: thèmes de l'OS, placement des boutons dans un dialogue (MacOs X et Windows ont des conventions opposés pour l'ordre du OK/Cancel), etc. Par exemple, sous Windows, j'ai activé l'option "placer le pointeur automatiquement sur le bouton par défaut". Il y a bien la moitié des applications qui ne le font pas (dont Qt si je me souviens bien) parce qu'ils n'utilisent pas les API de l'OS. Mais même sur des dialogues système de Windows, ça ne marche pas bien car ceux-là aussi sont à moitié customisés.
Qt s'en sort pas trop mal bien qu'il soit régulièrement critiqué pour cela.
Il faut voir aussi que pour les fournisseurs d'OS graphiques payant (la Poire croquée et la Porte fermée, je crois que c'est leur nom ?), l'interface graphique, c'est le lien direct avec l'utilisateur. Donc quand ils font une version majeure de leur OS, ils ont évidemment envie de montrer que c'est plus cool, plus fluide, plus joli, plus dans l'air du temps et ils vont a minima refaire un style pour leurs contrôles graphiques, et/ou refaire des API pour utiliser les dernières fonctionnalités de l'OS.
C'est un travail assez colossal de suivre ces évolutions dans un toolkit qui n'utilise pas l'API natif de l'OS. Et même pour un toolkit qui les utilise car il y a des nouvelles API qui apparraissent. D'autant que chaque OS a plusieurs API et styles graphiques, donc tu as à peine fini de polir le style précédent pour qu'il ressemble bien au natif qu'il faut reprendre le travail pour la nouvelle version.
Qt a maintenant des ressources plus conséquentes et arrive mieux que par le passé à suivre ce type d'évolutions. Mais il y a toujours un décalage.
Pour un toolkit qui repart de zéro comme Slint, je suis extrêmement confiant qu'ils n'arriveront pas à suivre les styles natifs des OS dans le temps. Ça n'enlève rien à la valeur du projet, il faut juste pas imaginer que ce sera facile ou réalisable d'être "comme le toolkit natif".
[^] # Re: Ce n'est pas du natif
Posté par Moonz . Évalué à 8. Dernière modification le 07 avril 2023 à 09:12.
Non, l’intérêt du natif c’est justement d’aller au delà d'un look & feel superficiel.
Intégration avec l’IME (je peux taper du chinois/japonais avec mon IME favori sous Linux ?), des spécificités du clipboard (il comprend la distinction primary/secondary clipboard sous Linux ?), etc. Y compris dans des configurations ésotériques.
[^] # Re: Ce n'est pas du natif
Posté par xryl669 . Évalué à 5. Dernière modification le 07 avril 2023 à 10:54.
Exactement. La vrai différence entre le natif et le pas natif, c'est que le natif utilisant les fonctions du système, s'intègre parfaitement avec toutes les fonctions du système, comme le lecteur audio TTS pour ceux qui ont des soucis à la lecture (et STT pour les inputs), l'IME, les gestionnaires de mots de passe, le presse papier, le bon skin quelque soit le thème choisi, le dictionnaire et la correction automatique, le ClearView dépendant de l'écran choisi, les bonnes fontes, etc…
Et là, je ne parle que des zones de texte, mais le même problème s'applique au checkbox, les progress bars, qui peuvent et sont automatisées (il y a des utilitaires qui surveillent les progress bars et peuvent éteindre l'ordi lorsqu'elle est arrivé à complétion sous Windows).
Le pire, c'est que le web comme vous dîtes, est super bien intégré avec les widgets natifs, justement et que quasiment tout ce que j'ai cité là au dessus fonctionne dans un navigateur, et sous Electron / Tauri et autre.
Bref, pour faire un soft cross platform qui fonctionne le mieux pour tous, la solution Electron ou Tauri, ou, à la limite, iced sous Rust qui utilise tous le modèle DOM (qui est donc super connu, débuggé, sans surprises et facile à recruter pour les développeurs).
Je pense donc qu'un nouvel entrant dans ce but, c'est mort né (sauf peut être si basé sur Servo histoire d'avoir une taille de binaire non délirante et de pas avoir 10 versions de webkit installé sur une machine).
Il reste donc l'interface graphique pour l'embarqué (où LVGL existe avec Squareline comme éditeur graphique et générateur de code), et l'immediate mode type egui sous Rust (qui présente les mêmes défauts que Slint, mais c'est plus ancien et mieux intégré, la plupart des bugs sont résolus)
[^] # Re: Ce n'est pas du natif
Posté par Aldebaran (site web personnel) . Évalué à 3.
Je suis tout à fait d'accord avec votre analyse, sauf avec la conclusion.
Car vous mettez de côté une chose essentielle : Le langage d'IHM déclaratif.
C'est du qml en rust quand même, moi ça me botte bien !
Un langage clair, simple (comme dans KISS) et surtout qui ne se trimbale pas 30 ans d'historique chaotique comme le web.
Pas que je dénigre les technos web (les types qui développent servo, svelte, ou react sont certainement monstrueux), c'est juste pas ma tasse de thé. Si je devais en faire je regarderai du côté de Tauri effectivement.
Actuellement dans l'écosystème Rust, de très nombreux frameworks, crates et autres libs se confrontent pour essayer de proposer des choses différentes. Je ne pense pas que tous soit du même niveau ou visent les même buts, mais dire que c'est mort né parce qu'il existe déjà des solution c'est un peu fort. À ce compte là on aurait jamais eu le Rust, ou bien Linux.
J'attends surtout de voir comment va évoluer Slint, j'aimerai bien voir ce que ça donne sur mobile aussi. Mais rien que pour son langage d'ihm il va creuser son trou.
[^] # Re: Ce n'est pas du natif
Posté par xryl669 . Évalué à 2.
Moi aussi, un langage descriptif de l'interface (type QML) ça me botte.
Jusqu'à ce que l'on réalise qu'il n'est pas dynamique, il faut le compiler sur l'hôte pour que ça donne l'UI (contrairement à QtQuick/QML).
Du coup, pour moi, ça perd pas mal d'intérêt.
Pourquoi ne pas faire un éditeur graphique (c'est quand même beaucoup plus simple à utiliser) s'il faut compiler de toutes façons ?
Là où ça aurait vraiment été super classe, c'est une description de l'UI (en JSON, ou même comme ils ont fait), que l'on peut changer au runtime, avec un lien entre les widgets et les signaux générés (et gérés dans le code compilé, lui). Histoire de pouvoir, par exemple, modifier le fichier, l'uploader sur la cible et zou le nouvel UI apparaît.
Sur un processeur embarqué, c'est gagner un temps fou de développement, car il suffit simplement d'avoir un système de fichier et un serveur web (très simple sur ESP32, Pi et autre) au lieu d'avoir à générer un binaire monstrueux, faire un OTA et attendre que ça reboote pour voir le résultat.
Après, il y a la solution demo "web", c'est pas mal, mais moins pratique qu'un éditeur graphique au final.
J'ai aussi un peu de mal avec le rust et l'embarqué, le support de rust dans l'embarqué, c'est quand même pas trop top en ce moment, mais ça s'améliore… C'est surtout le manque de bibliothèques qui m'empêche d'utiliser rust et si le système en dépend, ça fait un langage de programmation en plus à gérer dans la chaîne de compilation déjà complexe d'un projet embarqué.
[^] # Re: Ce n'est pas du natif
Posté par Gof (site web personnel) . Évalué à 3.
L'étape de compilation est facultative, il est aussi possible d'interpréter dynamiquement.
Et pour ce qui est de l'éditeur graphique, on y travaille.
[^] # Re: Ce n'est pas du natif
Posté par Gof (site web personnel) . Évalué à 2.
Bien que on dessine les widgets, on utilise des API native au final pour certaines fonctions d'intégration comme les IME, le presse papier, le style de couleur, l'accessibilité, et autres. Donc il y a un minimum d'intégration quand même et le but est améliorer l'intégration au fil des versions.
Il y a une raison pour laquelle quasiment personne ne fait du natif en utilisant les fonctions du système : personnes n'a envie de réécrire l'interface X fois pour X plateformes.
Ensuite nous voyons une valeur dans la facilité de conception de l'interface.
Et puis le DOM qui est soit disant si connu et facile. Pourquoi est-ce que tout le monde utilise un framework JavaScript different qui ajoute une couche d'abstraction avec une DOM virtuelle ?
[^] # Re: Ce n'est pas du natif
Posté par collinm (site web personnel) . Évalué à 2.
je dirais pas tous le monde… mais ce n'est pas par ce beaucoup le font que c'est mieux.
d'ailleurs le développement web s'est complexifié grandement
quand je compare ce qui était possible de faire en 2007 avec smartclient, Sencha GXT et aujourd'hui le gain est plutôt nul
ou bien aujourd'hui avec thymeleaf et htmx et le gain de temps d'utiliser justement ce genre de framekwork…..
une mode qui ne sert à rien pour la majorité des applications
www.solutions-norenda.com
# Super !
Posté par bux (site web personnel, Mastodon) . Évalué à 4.
Ça fait quelque mois que je suis à deux doigts d'utiliser slint. Cette nouvelle d'une version stable va me faire pencher pour l'utiliser je crois !
Merci pour cette news !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
# Ben plutôt le contraire
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 06 avril 2023 à 20:50.
Ben justement non : c'est clairement un modèle pas open source : la version open source est pour la pub en empêchant même du libre (par exemple du code GPLv2) d'utiliser la version open source, et la thune se fait sur vendre la possibilité d'enlever des limites de la licence open source.
Au final, l'open source est vu comme une contrainte qu'on propose de lever avec du non open source, l'affichage est que l'open source est nul et que la valeur est le non open source.
C'est légal, aucun soucis la dessus, il y a une version libre utilisable si vous aimez la GPLv3, c'est vrai, faut juste savoir ce que les gens derrière ont comme valorisation de l'open source.
J'imagine en signant un contrat disant qu'ils peuvent faire du non libre pour leur seule rémunération… Attention donc, pas que ce soit horrible mais sachez où vous mettez les pieds (pas dans le libre)…
[^] # Re: Ben plutôt le contraire
Posté par orfenor . Évalué à 6.
Ça devait arriver, à force de gratouiller la petite bête, tu t'empêtres dans tes contradictions.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 8.
Donc si je comprends bien ton message, tu prétends que la GPLv3 n'est pas open-source ?
Si on aimait pas l'Open Source, on aurait tout notre code propriétaire, ou des extensions proprio. Mais tout ce qu'on fait est sous license libre.
[^] # Re: Ben plutôt le contraire
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 06 avril 2023 à 22:57.
Je n'ai jamais dit ça.
La GPLv3 est open source, et vous utilisez ses fortes limitations pour vendre une version sans ses limitations, donc vous partez du principe que ce qui est bankable c'est de vendre une levée de limitation de la licence libre choisie.
Je dis juste que votre business n'est pas du tout l'open source, c'est le non open source.
chiche ce contredire ça factuellement? Quelle part de vos ventes sont en open source, donc?
Et le business sous licence non libre, c'est tout ce que j'ai dit.
Bizarrement vous gardez la partie "bankable" sans compétition possible.
Si vous aimiez l'Open-Source, vous auriez votre business en open source.
C'est un vieux truc classique de limiter en open source pour vendre la version on open source, style Oracle avec MySQL, pas de soucis, c'est juste que vous croyez tellement en l'open source que vous misez sur le non open source pour le business et surtout refusez que quelqu'un d'autre vous concurrence avec les mêmes droits.
Mais si tu aimes tant l'open source et la GPLv3, tu ne verras aucun problème à accepter un patch de ma part dans votre produit, en GPLv3 et pas autre chose, n'est-ce pas? Ou ça va coincer car incompatible avec votre version on open source qui est plus importante que l'open source?
La valeur de votre business est dans la différence de valeur entre open source et non open source, avec l'open source comme valeur moindre que non open source. Désolé, j'ai quand même du mal à considérer ça comme aimer l'open source que d'en mettre une valeur moindre que le non open source.
Je ne dit pas que c'est mal, juste dommage de valoriser l'open source comme "négatif".
Perso je n'ai rien contre, ça m'arrive de vendre du non open source, juste que je ne dis pas dans ce cas que mon business est orienté open source (mon business doit avoir 95% d'open source, je pense, en moyenne, pas orienté 100% open source mais pas loin quand même, et vous?).
Le tout est que les gens en soient conscient, après ils font en connaissance de cause.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 5.
Le modèle de dual-license est un modèle établi et supporté par la FSF: https://www.gnu.org/philosophy/selling-exceptions.en.html
Parce que tu acceptes les patches en GPL pour MediaInfo?
Même problème.
[^] # Re: Ben plutôt le contraire
Posté par Julien Jorge (site web personnel) . Évalué à 3.
Je crois que ce que Zenitram veut dire avec sa remarque sur le patch en GPLv3 est qu'il y a un petit truc qui coince sur la double licence et les contributions externes (mais pas pour slint, j'y reviens plus bas).
Si je soumets du code en GPL car j'adhère à l'idée que je donne parce que le receveur donne aussi en échange, c'est à dire que personne ne s'approprie le travail des autres et qu'on contribue ensemble à créer quelque chose pour tout le monde ; alors je ne vois pas comment ce code que j'ai écrit et partagé peut se retrouver dans un produit fermé. Ça va à l'encontre de l'intention initiale.
Pour slint c'est un poil différent car il est bien indiqué dans le contributor license agreement que le contributeur cède des droits de redistribution sous les termes d'autres licences :
À partir de là peu importe l'intention du contributeur.
[^] # Re: Ben plutôt le contraire
Posté par xryl669 . Évalué à -4. Dernière modification le 07 avril 2023 à 11:01.
Je ne vois aucun lien vers le code source pour MediaInfo. La page dit bien que c'est open source, mais ça doit être une licence en open source si tu les trouves, ou un truc comme ça.
[^] # Re: Ben plutôt le contraire
Posté par Olivier Abad . Évalué à 4.
Tu n'as pas dû beaucoup chercher.
https://mediaarea.net/en/MediaInfo/Download/Source
[^] # Re: Ben plutôt le contraire
Posté par phroy (site web personnel) . Évalué à -3.
Je trouve étrange de présenter votre logiciel avec une capture écran avec un logiciel qui n'est pas open source (VS machin).
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 7.
C'est une capture d'écran de Firefox. (Qui montre la version web de visual studio code, qui est open source)
[^] # Re: Ben plutôt le contraire
Posté par phroy (site web personnel) . Évalué à -7.
une "partie" est open source … la démonstration est faite.
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 10.
Des fois tu dis que la licence c'est le libre et que le libre c'est le licence et que tout le reste que des gens mettent derrière n'est pas du libre. Des fois tu dis qu'il est important de regarder la philosophie.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Il y a une licence opensource. Mais le business n'est pas fait sur l'Open Source : ils vendent du propriétaire. C'est si compliqué que ça à comprendre ?
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Ça me gonfle ce sujet car tout le monde tombe dans le panneau. Vendre une version propriétaire, c'est pas un business opensource. C'est éventuellement de l'opencore, mais en aucun cas de l'opensource.
Et l'opencore c'est encore pire que le propriétaire : ça joue sur l'image de marque sympa du logiciel libre, mais ça vend tout simplement du propriétaire.
Sans en dire le nom.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 5.
C'est un business open-source parce que la version vendue est exactement la même que la version libre.
Si c'est pas un business open-source, qu'est-ce qu'un business open source selon-toi ?
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
C'est quoi que la boîte vend ? Des licences propriétaires, non ?
Que la boîte contribue en publiant une version opensource est une chose, que son modèle économique soit opensource en est une autre.
Vous avez choisi une licence GPLv3 pour le code sous licence libre. Si je fais une proposition de fonctionnalité qui s'appuie sur des dépendances GPLv3 sur lesquelles je n'ai pas la main, elles seront refusées car en désaccord avec la clause de session des droits pour faire une version propriétaire.
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 08 avril 2023 à 10:35.
Un business opensource c'est une activité économique où tu vends des services qui ont vocation à produire du logiciel libre. J'achète par exemple des prestations de support et maintenance sur un logiciel libre, des prestations de développement pour contribuer et faire évoluer un logiciel libre.
Ce qu'on fait avec Algoo, ce que fait Open-DSI, ce que fait XWiki etc.
C'est tout le contraire de ce que propose mattermost, gitlab par exemple.
Je vais te donner un exemple concret : dans Tracim on utilise tinymce. Il est impossible d'acheter des services support/maintenance sur la version libre. Si je deviens client c'est pour la version propriétaire. Contractuellement, rien ne garantit que ce que je remonte sera fixé dans la version libre, et notamment des évolutions fonctionnelles. Donc si je paie, aucune garantie que cet investissement que je fait sera définitivement dans le produit libre.
Si j'achète un dev ou une correction de bug à Open-DSI sur Dolibarr, ça sera forcément intégré dans le produit libre puisqu'ils ne maintiennent pas leur propre dolibarr sous une forme non libre.
Tes clients sont ils clients pour produire du libre ou du propriétaire ?
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 4.
Mes client eux-même font du propriétaire. Mais pas moi.
Si mes clients payent pour une licence, le développement qu'on fait pour le produit avec cet argent sera 100% libre.
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Je comprends ; ma question n'aurait pas dû être "tes clients font ils du logiciel libre" mais "tes clients peuvent ils publier leur logiciel sous licence libre". C'est cet aspect qui est important à mon sens.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 5.
Je rajoute que tu pinailles avec les définitions, mais d'après Wikipedia, la double licence est bien un modèle économique open-source
https://fr.wikipedia.org/wiki/Mod%C3%A8les_%C3%A9conomiques_des_logiciels_open_source
Alors il y a bel et bien plusieurs type de modèle, et celui que tu as choisis est différent du notre, mais cela reste néanmoins un modèle "open-source".
C'est comme si un pilote d'avion engueulais un pilote de formule1 parce que il dit qu'il est « pilote » et ça le gonfle qu'il joue sur « l'image de marque » du métier de « pilote » alors que son véhicule ne vole même pas.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 3.
Elle ne sera pas forcément refusée. Tout dépends de si c'est optionnel ou pas.
Mais effectivement nous n'accepterons pas de PR qui tuerais notre business.
Mais je suis sûr que c'est pareil pour quasiment tout les logiciel libre auquel tu penses, non?
Mais vu que nous ne faisons pas d'open-core, ça veux dire que on a pas de raison de refuser une fonctionnalité qui existe déjà dans notre offre payante (puisque qu'il n'y a pas de fonctionnalités extra dans l'offre payante)
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 6.
Il ne s'agit pas d'opencore. Tu as tout le code complet sous gplv3 accessible sans même avoir à leur demander. Ce que tu paie c'est le changement de licence.
Je comprends bien que cet usage de la gpl comme une arme par destination n'est pas du goût de Zenitram, mais affirmer que ce n'est pas libre c'est mettre autre chose que les 4 libertés derrière le mot libre. Quand d'autres mettent d'autres notions derrière la notion de libre comme communautaire, il leur rappele bien que le libre c'est le code et uniquement le code et que tout le reste c'est du bullshit.
Selon la sensibilité de chacun les gens ont envi d'ajouter quelque chose à la notion de libre pour la faire coller à l'idéal qu'il aime bien.
Il aurait peut être fallu être un peu moins sûr de soit et s'intéresser à ce dont il est question avant de s'énerver et ne prendre les gens de haut.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Ce qui est vendu est une licence propriétaire, pas un service quelconque sur du logiciel libre.
C'est donc un business propriétaire qui contribue au libre. Cf mon commentaire ci-dessous
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 1.
Ah du business propriétaire. Tu as un truc plus que ton avis pour définir ce que c'est ? Tu semble rentrer complètement dans la case "je réutilise des mots au quels j'associe des valeurs pour y mettre autre chose que j'aime bien". Tout à l'heure tu réutilisais le mot opencore pour quelque chose que ça n'est pas. Du business opensource je ne sais pas ce que c'est. Plus haut il a était montré que l'organisation créatrice de la GPL et qui a formalisée les 4 libertés trouve ce business acceptable1. Ça n'en fait pas un business libre puisque ça n'a aucun sens, mais on est apparemment pas dans le dévoiement de la philosophie de la licence qu'ils utilisent.
Que ça ne te plaise pas pour toutes les raisons du monde, je l'entends, mais diffamer et tenter de jeter l’opprobre sur leur rapport au libre c'est pas terrible.
https://www.gnu.org/philosophy/selling-exceptions.fr.html ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 08 avril 2023 à 12:16.
Tu lis en diagonale ce que j'ai écrit.
J'ai pas dit que c'était de l'opencore mais que c'était du propriétaire. Éventuellement de l'opencore (puisque comme tu le dis, je n'ai pas creusé et c'est tout l'intérêt d'un mot comme éventuellement).
Et oui, vendre des licences, c'est du logiciel propriétaire. Ya pas besoin de sortir de Saint-Cyr pour le comprendre.
J'ai pas de problème avec le fait de vendre du logiciel propriétaire. Tu veux que je te dise : on en fait, même, pour certains clients. Mais je ne dis pas que je fais du libre quand je vends des licences.
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 4.
Tu as préféré supputer et t'énerver que t'informer.
Non. Tu amalgame des choses différentes encore.
Vendre ça n'est pas libre ou pas, c'est juste vendre. Tu peux coder un logiciel libre, ça peut être ça "faire du libre" au sens de "produire du code libre", mais l'action de vendre ne produit pas de code, jamais.
La totalité du code produit est libre et vous êtes pas content que la dépêche dit :
C'est factuel. Ils n'écrivent que du code libre et acceptent les contributions et permettent de virer le copyleft si tu passe à la caisse.
Faut redescendre un peu
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 08 avril 2023 à 11:11.
Personne n'a dit que ce n'est pas libre.
Rigolo cette façon de supprimer un mot pour ne pas parler du sujet, et d'inventer.
Tu me dit que je parle philosophie quand ça m'arrange, mais en réalité j'en parle quand c'est le sujet.
Le produit (un livrable) est 100% open source (100% du code est dispo avec une licence libre).
Le business (la philosophie) est 0% open source (0% du CA est fait avec une licence libre).
Absolument pas, c'est juste l'analyse des faits.
Mais si je me trompe, Gof nous dira sans aucun problème quel pourcentage de CA il fait sur le business en open source.
En attendant, certes on ne se salit pas les mains sur l'open core, mais on ne fait que déléguer : la vente est sur permettre à d'autres de faire de l'open core (dont le principe est que la version open source ne te permette pas de concurrencer, oui pour de l'open source mais on fait le nécessaire pour garder un avantage qui empêche une concurrence effective).
Aucun besoin de prendre les gens par le haut, il suffit de faire remarquer la réalité et voir la "défense" pour faire croire que le business est open source. Mais pourquoi donc (se) cacher faire du business basé sur la valorisation de la version non open source en considérant la version open source comme produit d'appel au même titre que l'échantillon gratuit dans le monde réel?
Ici, j'ai juste dit que la version open source n'est pas le business, et parlé de business car Gof a parlé de business.
Gof pourrait très bien expliquer en quoi la version open source a une valeur, un truc bankable, ou juste expliquer que oui, c'est bien la vente de version non open source qui est bankable, pas de mal, plein de gens pensent qu'on ne peut pas faire de business avec de l'open source, il suffit juste d'assumer que ce n'est pas un business open source sans que ça enlève la disponibilité d'une version 100% open source, pas la peine de travestir la réalité si on assume.
Il n'y a rien de mal à faire du business non libre, perso je ne fais que nommer pour que les gens sachent où ils vont et utilisent (ou payent) en connaissance de cause, et ok aussi pour le plaisir de cacher les jolis affichages trompeurs.
Passons donc, rien de nouveau (ce business model date de MySQL, la c'est "juste" mis en plus bourrin car MySQL ne limite pas la licence du code appelant en SQL, ici c'est une lib donc juste impossible "par design" de la licence d'utiliser du non compatible GPLv3, et ce n'est pas non plus la première fois qu'il y a une présentation "libriste" sur du business proprio complet juste parce que la version produit d'appel pour vendre le non libre est libre).
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 6.
Il y a une définition partagée de ça ? Parce qu'open source c'est 4 libertés, rien d'autre. Tenter d'associer tout et n'importe quoi avec pour tenter de faire une sorte d'amalgame/entrisme c'est aussi problématique quand les gens veulent amalgamer libre et communautaire et libre et business.
C'est comme associer républicaine à tout et n'importe quoi.
Ah mais tu découvre ? Ça fait 25 ans que c'est toujours les même questions. Tout ton thread n'est que du trolling.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 7.
100% du CA est pour vendre des licenses de logiciels qu'on a développé et ce code est 100% libre.
Tu veux que j'appelle ça comment ?
[^] # Re: Ben plutôt le contraire
Posté par nud . Évalué à 4.
En fait tu devrais juste dire que tu fais une double licence MIT pour les gens qui paient pour pouvoir utiliser slint dans leur produit propriétaire 🤷
Après tout on peut tout à fait faire du libre sans le distribuer. La GPL impose de garantir les 4 libertés aux clients, pas de distribuer sur internet pour des gens tiers qui n'ont pas payé.
[^] # Re: Ben plutôt le contraire
Posté par Gof (site web personnel) . Évalué à 3.
On y a pensé, mais le problème c'est que alors ils pourraient redistribuer leur copie en MIT, et nous on aurait plus rien a vendre.
[^] # Re: Ben plutôt le contraire
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 08 avril 2023 à 07:37.
J'ajouterai que ça vaut toujours le coup je trouve de se renseigner plus lorsque quelque chose énerve. Produire un effet énervant est une technique pour pousser à réagir ce qui plaît aux algo de plate-forme, ce qui pousse au clique, etc. Je trouve personnellement que c'est une bonne autodéfense de soit retarder son jugement si on ne veut pas aller plus loin dans ses recherches sur le sujet soit se renseigner (ce qui permettra d'être un énervé érudit).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ben plutôt le contraire
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Je ne sais pas quel est ton métier. Moi je gère une boîte qui fait et vend du logiciel libre et le discours est complètement biaisé à cause des boîtes qui confondent contribuer et commercialiser.
Gitlab contribue : t'as une version libre. Très bien. Google aussi. Mais ni l'un ni l'autre n'a un modèle économique qui repose sur le logiciel libre.
Le modèle de développement de ces entreprises repose effectivement sur le logiciel libre, mais pas le modèle économique. Je peux t'en citer un paquet ; tu vas à OSXP, par exemple et tu vois la stratégie des boîtes "opensource".
Que vend la société ? C'est ça qui fait que le business est opensource ou pas, il me semble.
Après tu as raison sur le fait qu'il faut généralement éviter de s'énerver et plutôt poser des questions calmement, mais quand tu passes ton temps à expliquer aux prospects que non ce n'est pas du logiciel libre qu'ils achètent parce qu'en face tu as des commerciaux qui soient filoutent soit ne comprennent même pas le modèle de licencing de ce qu'ils proposent (coucou passbolt), ça devient fatiguant.
Le pire dans tout ça, c'est que les principaux intéressés sont bien souvent les premiers ambassadeurs de faire du commerce propriétaire.
[^] # Re: Ben plutôt le contraire
Posté par Faya . Évalué à 10.
Donc au final vous êtes 3 contributeurs du libre à vous écharper parce que la dépêche contient 3 mots "Buisness (sic) Modèle Open Source". Chacun des 3 produisant du code 100% libre mais l'un des 3 vend le même code 100% libre sous une autre licence. C'est beau…
On a du code ? oui. Il est libre ? oui. Entièrement (pas juste le core) ? oui.
Vu de l'extérieur, la manière dont c'est "vendu" à côté m'importe peu au final. Si on veut pinailler jusqu'au bout on peut remonter à l'étymologie de "business : equivalent to busy + -ness" = la manière dont on s'occupe. L'occupation en question comprend du libre, donc le business comprend aussi la version libre ;-)
[^] # Re: Ben plutôt le contraire
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Vous vous souvenez qu'on pouvait acheter les boîtes (tous les CD + manuel + support) de Mandriva Linux chez Surcouf et Fnac ? Donc ces boîtes auraient pu claironner qu'elles faisaient du « business open source » alors que les GAFAM qui elles produisent du code libre (et dont on connait la pas si grande honnêteté) n'ont pas cette revendication ?
P.S. L'exemple, encore actuel, de Gitlab a été donné ; mais bizarrement on élude pour répondre à côté du point soulevé ;-(
P.P.S. The original sense is obsolete, as is the Middle English sense of "state of being much occupied or engaged" (mid-14c.), the latter replaced by busyness.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Wayland / HiDPI / fractional scaling
Posté par nlgranger . Évalué à 2.
Merci pour le partage. Je n'avais pas vu ce projet lors d'une brève recherche sur les toolkits graphiques en rust, donc c'est une bonne idée de le mentionner sur linuxfr.
Qu'en est-il du support de wayland et du support de la mise à l'échelle pour les écrans haute définition? Vous utilisez quoi pour le rendu des polices d'écriture?
[^] # Re: Wayland / HiDPI / fractional scaling
Posté par Gof (site web personnel) . Évalué à 5.
Wayland est supporté, ainsi que la haute définition.
Pour le rendu des police, ça dépend si backend. Soit on utilise femtovg (une lib en Rust), soit skia, soit Qt.
[^] # Re: Wayland / HiDPI / fractional scaling
Posté par nud . Évalué à 2.
T'as pas envie de corriger les ombres (ou l'absence de) avec Qt5 sous wayland tant que tu y es? :-D
# ô équipe modératrice, voici quelques fautes pas vues
Posté par orfenor . Évalué à 5. Dernière modification le 06 avril 2023 à 21:36.
quel que soit l'OS
qui ont moins de 300KB de mémoire
[^] # Re: ô équipe modératrice, voici quelques fautes pas vues
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Pourquoi passer de Qt à Slint ?
Posté par porki . Évalué à 2.
Je vois que 2 fondateurs sont des anciens de Trolltech, que Qt est utilisé pour les couches basses, que l'on peut faire du Javascript ou du C++ pour développer son interface graphique … je me demande alors comment Slint se distingue-t-il de Qt/QML ? Mis à part la possibilité d'utiliser Rust, quels sont les arguments qui ferait passer qqcun de Qt vers Slint ?
[^] # Re: Pourquoi passer de Qt à Slint ?
Posté par Aldebaran (site web personnel) . Évalué à 3.
De ce que j'ai compris, essentiellement le fait que la lib elle même soit en Rust.
Tu n'es pas tenu d'utiliser Qt si tu passes par un autre backend. Donc si tu code ton app en Rust aussi tu te retrouve avec 100% de code en Rust.
Et si on compare à Qt, c'est moins complet mais c'est aussi plus léger, il y a moins de technos différentes pour la même chose (Qt est quand même gargantuesque) et de facto beaucoup moins de code historique (cela étant dit sans dénigrer Qt).
[^] # Re: Pourquoi passer de Qt à Slint ?
Posté par Gof (site web personnel) . Évalué à 4.
En effet.
On a voulu faire un truc inspiré de QML mais plus moderne.
Pas de forçage de C++ que nous estimons en décroissance.
Se concentrer sur L'UI et laisser les autres choses aux bibliothèques spécifiques du language.
Une bonne séparation entre l'UI et la logique. Avec un language static qui permetra de faire un éditeur graphique et d'autres outils. Sans avoir besoin d'un ramasse miettes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.