Il est temps de vous présenter Slint, un toolkit pour faire des interfaces graphiques pour desktop et embarqué.
Slint est open source et multi-plateformes. Le projet est développé sur GitHub: https://github.com/slint-ui/slint
Le principe est inspiré par QML (puisque j'ai travaillé dans cet écosystème précédemment).
Il y a un langage de description d'interface, et la logique se fait dans un autre langage de programmation.
Le code .slint ressemble à ça:
HelloWorld := Window {
property <string> name: "World";
callback button-clicked();
VerticalLayout {
Text { text: "Hello, " + name; }
Button {
text: "Click me";
clicked => { button-clicked(); }
}
}
}Le principe est que nous avons un compilateur qui génère du code vers le langage de programmation. Le développeur n'a plus qu'à changer la valeurs des propriétés ou modèles de données, et répondre a des callbacks.
Contrairement à QML qui est fait pour être utilisé en C++, (Même si existe bien des bindings Qt pour d'autre langages, ils sont de seconde classe, et la documentation et l'expérience n'est pas idéale), Slint peut être utilisé depuis plusieurs langages de programmation. En ce moment on supporte déjà 3 langages: Rust (qui est aussi le langage d'implémentation), C++ et Javascript (avec NodeJS). Ce choix de langages montre qu'il est possible de supporter de manière idiomatique à la fois des langages systèmes, et des langages dynamiques. Il est même possible d'utiliser Slint depuis bash.
Les expressions dans le code en .slint sont dans un langage minimaliste à typage fort. Cela permet de faciliter les outils, tel que un un serveur LSP (Language Server Protocol) pour les éditeur de texte qui fait auto-complétion et pré-visualisation, et un future outil graphique. Grâce à ça, le langage Slint est déjà intégré dans les éditeurs de textes
Il y a un style "natif" pour fonctionner sur les environnements de bureau (qui utilise QStyle pour le moment).
Il est possible de compiler pour WebAssembly. Voici des liens vers des démos compilées en WebAssembly qui fonctionne dans le navigateur: Printer - Puzzle - Plotter
Plus d'exemples: https://github.com/slint-ui/slint/tree/master/examples
Slint est aussi léger et performant. Nous ciblons aussi les micro-contrôleurs. Par exemple, comme vous pouvez voir sur cette image, la démo fonctionne sur un Raspberry Pi Pico (RP2040), c'est un CortexM0 avec seulement 264KB de RAM et 2MB de Flash qui coûte seulement 4€ (+ 15€ pour l'écran)
Et voici une capture d'écran d'un autre programme fait avec Slint qui utilise le style natif de la plateforme (KDE plasma en l’occurrence). Il s'agit de Cargo UI une interface graphique pour Cargo, le gestionnaires de packages de Rust.
Pour apprendre Slint, vous pouvez suivre le tutoriel (Rust, C++), ou commencer avec un template (Rust, C++).
Si vous avez des questions ou des rapports de bugs à faire, vous pouvez le faire dans les issues de GitHub ou dans les discussions.
Site web: https://slint-ui.com
# Backend GPU ?
Posté par Tangi Colin . Évalué à 3.
En terme de rendu graphique qu'est ce qui est supporté ? Surtout coté embarqué, coté QT on a leur backend EGLFS pour utiliser le GPU en direct sans avoir besoin d'un serveur X/Wayland. A-t-on quelque chose d'équivalent coté slint ou est-ce uniquement un rendu via CPU ?
[^] # Re: Backend GPU ?
Posté par nud . Évalué à 8.
À première vue il existe un backend pour GL, un autre pour Qt et un 3e pour le Marvel Cinematic Universe.
[^] # Re: Backend GPU ?
Posté par Gof (site web personnel) . Évalué à 8.
Il y a plusieurs backend de rendu. Pour le moment il existe :
- Un backend GL qui fait le rendu avec OpenGL ES2, mais utilise winit pour obtenir une "surface", qui utilise X ou Wayland sous Linux.
- Un backend Qt qui support ce que Qt supporte (mais j'imagine que tu ne veux pas utiliser Qt dans ce cas là)
- Un backend pour les MCU qui fait le rendu en software lignes par lignes et les transmets directement sur l'écran.
Il serait effectivement bien d'utiliser le backend GL sans serveur graphique, mais c'est pas encore implémenté.
[^] # Re: Backend GPU ?
Posté par Tangi Colin . Évalué à 4.
Merci pour la réponse, c'est claire pour moi. Joli projet en tout cas, j'espère que vous aurez du succès et que le business modèle suivra, ça fait du bien de voir un compétiteur à QML émerger.
# Et bah dis donc !
Posté par Aldebaran (site web personnel) . Évalué à 6.
Je regardais le projet de loin depuis un moment en me disant qu'il était extrêmement prometteur !
D'ailleurs ma proposition de nouveau nom n'avait pas été retenue, je proposais RQML ^
Mais Slint c'est très bien :)
Un petite question, j'ai toujours trouvé que Qt était un enfer au niveau des licences, en plus c'est pas donné en pro; Slint semble se positionner de la même façon, pourquoi ce choix ?
De plus sur votre site je suis un peu perdu au niveau des tarifs, je n'ai pas trouvé le prix des deux licences logicielles, ça se négocie ?
Si on reste dans du libre la licence n'est pas un problème. Ah, pour information, peut on commercialiser un logiciel bâtit avec Slint sans payer de licence si on publie les sources ?
Niveau rendu vous dites sur le repo utiliser opengl et Qt Style.
Sur Qt je vois pour les Widget et le QML mais je ne connais pas QStyle.
Comment ça fonctionne ? Est ce que vous utiliser QStyle comme un canvas ou bien quand on définit un TextArea ou un Label dans un .slint il va générer un Widget ?
En tout cas bonne chance pour la suite, c'est un superbe projet.
Et l'écosystème Rust manque encore d'un bon système d'UI (même si ce ne sont pas les candidats qui manquent).
Merci de l'avoir fait libre !
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 9.
Niveau prix, c'est gratuit pour ceux qui annoncent qu'ils utilisent Slint.
Sinon, C'est en prix qui fixe par application de bureau, ou qui dépend du nombre de d'appareils commercialisé.
Pas besoin de publier les sources, mais il faut accepter de nous permettre d'utiliser votre produit dans nos communication marketing. Plus d'info là: https://slint-ui.com/ambassador-program.html
La raison d'un tel choix de licence est que les entreprises qui font des produits pour lesquels on est compétitifs (les appareils avec des écran embarqués) ne voudront jamais communiquer sur les technologies utilisées pour leur développement. Alors que ce n'est en général pas un problème pour les plus petites entreprises.
En quelque sorte. On donne un canvas à QStyle où le widget est dessiné. Non, Slint ne génère pas de QWidget pour chaque widget.
[^] # Re: Et bah dis donc !
Posté par saltimbanque (site web personnel) . Évalué à 7.
c'est assez intéressant comme type de licence. Est-ce que ça a été inspiré d'autres produits ou une pure invention?
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 6.
Pure invention
[^] # Re: Et bah dis donc !
Posté par Aldebaran (site web personnel) . Évalué à 3.
Ah d'accord je n'avais pas compris ça comme ça, c'est le mode "Ambasador";
Je pensais que c'était plus select que ça :)
C'est pas bête pour créer un usage et s'attirer de la visibilité effectivement !
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 18 mars 2022 à 08:07.
Ta phrase fait penser que tu pense que libre et commercial sont incompatibles.
En plus de la réponse de Gof sur la licence ambassadeur ou l'achat de la licence dite "commerciale", il faut peut-être rappeler que faire du libre, même du GPL3, n’empêche absolument pas de commercialiser : le libre n'est pas incompatible avec commercialiser.
Il faudrait que tu précises ce que tu veux faire, car la licence "par défaut" du produit discuté, la GPL3, ne t'empêche aucunement de commercialiser ton logiciel (ne pas diffuser le code source à n'importe qui, mettre une barrière financière, etc) du moment où tu respectes la licence (qui t'oblige à fournir à celui qui reçoit, et cette obligation ne concerne personne d'autre, ton code sous une licence compatible GPL3, cette obligation ne faisant pas du tout obstacle à ta commercialisation).
PS : même si on se doute bien qu'en pratique la licence GPL3 pour une lib est faite pour vendre la licence non GPL3 comme MySQL, le libre vu comme un produit d'appel ;-).
[^] # Re: Et bah dis donc !
Posté par Aldebaran (site web personnel) . Évalué à 1.
Effectivement on peut penser ça, je me suis mal exprimé.
On peut tout à fait commercialiser un logiciel libre.
Mais comme je ne m'y connais pas plus que ça en licence, je voulais justement vérifier que c'était ok et sous qu'elles conditions :)
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 4.
Oui c'est vrai en théorie.
Mais en pratique, faire un programme libre ça empêche de commercialiser car personne ne veux payer pour quelque chose qui peut être téléchargé gratuitement ailleurs gratuitement (et légalement)
Pour une lib GPL c'est différent.
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 4.
Je suis donc de la théorie… Mes clients "pro" (logiciels spécialisés donc personne ne pense à mettre ailleurs) et "particuliers" (vente de produit très diffusé à 1 € via un processus de paiement très simple, ils ont la flemme d'aller chercher ailleurs et du coup personne ne met très visible ailleurs) sont pourtant dans la pratique.
Encore faut-il trouver.
Rappelons que le libre ne permet pas d'interdire d'interdire l'utilisation du nom, et que les clients n'ont pas forcément envie de diffuser.
Je voulais juste souligner que pour certains cas commercialiser un produit GPL n'est pas forcément viable mais que rien dans la licence n’empêche la chose, c'est juste de voir si une offre commerciale en GPL a un potentiel vis-à-vis des libertés fournies vs le gain financier, beaucoup de gens opposent libre à commercial alors que techniquement ce n'est pas incompatible (ça a des impacts qui font que ce n'est pas forcément viable financièrement, mais c'est un choix et non un empêchement légal).
Donc :
sous entendu "dans tous les cas" : non.
Dans le cas X : peut-être oui, peut-être non, ça dépend de plein de choses.
Faut arrêter de faire une généralisation d'un cas certes classique mais pas 100% des cas.
Note : de mon côté je vais même jusqu'à permettre de fermer via une licence copyfree et ça n’empêche pas les gens de payer quand même.
Oui on comprend bien que ici le libre n'est pas vu comme "positif" mais comme une contrainte "négative" pour vendre du non libre, rien de nouveau dans la méthode ;-). Mais je conçois qu'en libre montré comme "positif" ce n'est pas forcément viable, c'est votre liberté que de choisir un tel modèle.
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 3.
Je suis grosso-modo d'accord avec toi.
Peut-on vraiment parler de commercialiser le logiciel dans ce cas là, si tu fait juste répondre à une commande, c'est plutôt du service.
Il y a sans doute moyen de se faire un peu de fric comme ça effectivement, mais il faut vraiment avoir un logiciel très diffusé.
Est-ce que tu commercialise un de tes logiciels de cette façon ?
Moi je vois le libre comme "positif".
Ceux qui ne veulent pas faire de libre voient ça comme "négatif" mais ils n'ont qu'à payer alors.
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 2.
A partir de combien d'unités ça passe de "service" à "logiciel"?
Vendre à 100 personnes qui ne se connaissent pas et n'ont pas envie de diffuser, c'est un service ou de la vente de logiciel?
Tu réduis les possibilités alors que le libre peut être très inventif (sans pour autant avoir besoin d'aller jusqu'à vendre du non libre ;-) )
Oui.
Et pourtant tu n'as aucun problème à échanger des droits non libres contre des €. Pas de soucis à ce que vous vouliez ce business model mais je tique sur "positif" car la licence libre choisie est voulue pour faire chier afin de vendre la version non libre, pour moi (subjectif peut-être) le libre est affiché comme non viable (autant pour vous que pour les autres, pour vous vous vendez une version non libre et pour les autres tu dis explicitement que commercial et GPLv3 est non viable) donc pas vraiment positif…
Si le libre est positif, pourquoi avoir besoin de non libre pour remplir les caisses et/ou pourquoi faire vous-même du non libre?
En pratique je ne peux pas utiliser votre version libre car ça m'empercherait de diffuser mon logiciel libre sur le iOS AppStore, donc je dois vous prendre une version non libre, par exemple (oui, j'ai déjà titillé sur du CDDL mais ok cas très spécial, je vais sur le iOS AppStore car problème plus pratique qui casse un de mes business model en libre), et autres galères potentielles dans le futur (on ne peut pas forcément tout anticiper et on peut tomber plus facilement sur un problème quand il y a plein de restrictions, surtout quand l'entité fait des menaces, et pour le Mac App Store, un peu différent car on peut exécuter des versions modifiées, on est dans le flou donc dans le doute on évite).
Le débat avec les gens trouvant le libre "positif" mais échangeant des droits pas dans la GPL contre des € est loin d'être nouveau ;-).
Encore une fois, vous êtes tout à fait libres de choisir le business model que vous voulez, aucune critique en soit sur ça et que le meilleur gagne (si quelqu'un peut concurrencer en libre et seulement libre perso je pencherai vers eux car se financent sur du libre et non pas du non libre; mais dans l'UI même Qt n'y arrive pas et passe par le même style de double licence…), juste que perso je trouve dommage que qu'une licence libre soit vu comme un moyen de vendre du non libre, sans pour autant dire que ce n'est pas libre (vous proposez quand même du libre et ceux qui sont compatibles GPLv3, soit pas mal de monde, peuvent utiliser).
[^] # Re: Et bah dis donc !
Posté par Psychofox (Mastodon) . Évalué à 6.
On peut prendre le cas de Ardour qui est un logiciel libre, mais dont les binaires fournis upstream sont payant. Ce qui te laisse le choix entre payer le projet Ardour pour avoir les binaires, l'installer depuis le package manager d'une distro, installer le binaire d'une tierce-partie qui le compile pour toi, avec le problème de confiance que cela pose, ou l'acheter sous le nom Harrisson MixBus qui le commercialise sous sa marque. Si tu protège ta marque tu peux interdire les binaires compilés par des tiers utilisant la même marque/logo.
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 18 mars 2022 à 13:48.
Ou RHEL pour une distro complète. Pareil, il y a des versions sans la marque qui pullulent (gratuite) car il y a une demande, mais ça n’empêche pas l'entreprise d'être rentable sans pour autant faire du non libre (les binaires en soit sont certes non libres mais on peut tous recompiler et avoir en libre la même fonctionnalité, RH ne faisant pas de code lié à la distro en non libre à ma connaissance).
Il y a des exemples, ça veut dire que c'est possible, sans dire que c'est tout le temps possible : ça dépend. On ne peut pas généraliser que libre est forcément non commercial.
PS : pareillement que Ardour j'utilise le droit des marques pour calmer les "copies conformes", faut que les gens recompilent en enlevant la marque pour pouvoir redistribuer légalement; bon, en pratique les gens distribuent non légalement :-p, juste pas sur les stores (sauf aux US quand le distributeur sépare le rejet par pays car la marque a été refusée car trop générique, le "prix" d'avoir choisi un nom pratique) et ça n’empêche aucunement de vendre.
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . Évalué à 4.
Donc ils vendent du non libre au final et du support, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 3.
Peut-être ma sélectivité subjective mais le binaire qui est non libre me parait bien peu gênant par rapport au code, je m’intéresse à la liberté du code et pas du binaire, car le binaire peut difficilement être modifié et qui veut utiliser autre chose que "gratuit" dans les libertés du libre doit recompiler dans tous les cas. La où je trouve limite RH par rapport à Mozilla par exemple est que le rebranding est rendu volontairement complexe.
Et sinon vendre du support est un business model du libre, oui.
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . Évalué à 5.
Moi je m'en fou, mais certains se sentent concernés et j'en ai vu s'en plaindre entre autre pour vs code.
Ainsi que de prédater leurs alternatives en te demandant de pas mixer du alma/rocky avec du RHEL.
Mais il ne s'agit plus de « commercialiser du logiciel libre ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Ce qu'ils vendent est libre puisque les sources sont disponibles et que les quatre libertés ne sont pas empêchées. Mais le libre ne demande pas d'aller à l'encontre du trademark ; donc tout est okay !
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . Évalué à 2.
Les critiques de ce genre de démarche parlent du trust du build, de ce qui pourrait être ajouté ou non au binaire.
L'exemple le plus connu c'est vscode. Il y a du code libre accessible à tous, mais de ce que j'ai lu le binaire fourni par ms, ne contient pas que du code libre.
Encore une fois moi je m'en fous, mais c'est un choix personnel de ce que je considère acceptable ou pas et il peut varier selon d'autres critères (par exemple est-ce que le non libre des binaires autorise la décompilation pour étude).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par nud . Évalué à 5.
Si, beaucoup de gens (principalement des personnes morales j'imagine) sont prêts à payer pour pouvoir appeler quelqu'un et crier dessus quand ça ne fonctionne pas. Sinon RedHat serait sur la paille.
En plus, un logiciel peut être libre si tu files les sources à la personne qui l'achète, sans pour autant rendre les sources disponibles sur le grand ternet.
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 2.
Oui, on est bien d'accord. Mais dans ce cas on ne commercialise plus le logiciel, mais on vends du support/services.
(C'est un modèle qui tient la route, mais quand même assez risqué car n'importe qui d'autre peut aussi fournir du support sans avoir besoin d'investir dans le développement.)
Si on ne rends pas disponible ni les sources ni le binaire, alors oui, techniquement c'est « libre », mais ça perds un grand avantage à mes yeux qui est d'avoir une communauté derrière. (Ah, ça me rapelle un journal: https://linuxfr.org/users/gof/journaux/logiciel-libre-ou-communautaire-ma-d%C3%A9finition)
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 18 mars 2022 à 17:41.
Le libre s'intéresse à celui qui reçoit et n'a absolument rien à faire d'autres que celui qui reçoit, donc rien à faire d'une communauté.
On peut faire du libre non communautaire comme du non libre communautaire, c'est complètement orthogonal.
Après, qu'on trouve gênant de bloquer le communautaire, c'est un choix de priorité entre différentes options. Mais en tous cas du libre non communautaire est exactement pareil que du libre communautaire en terme de libre, donc c'est un critère supplémentaire et non pas une "définition".
Donc pas de guillemets dans "libre" à cet endroit, car communautaire ou pas sont exactement au même niveau par rapport au libre.
Ca a déjà été discuté dans le journal ;-), mais bref : si on met chacun ce qu'on veut dans la notion de libre, on ne va pas aller loin dans le débat, restons sur la définition du libre par les entités reconnues (OSI, FSF, Debian), le reste c'est du personnel. Et les 3 sont claires que le libre n'a rien à faire du communautaire (voire considèrent que du communautaire forcé est non libre, cf problème de l'île déserte).
PS : ma "définition" qui reste tout à fait personnelle est que quelqu'un qui utilise (comme vendre) des droits qu'il ne donne pas à celui qui reçoit le code libre n'est pas vraiment dans un esprit positif du libre vu qu'il profite de droits qu'il a lui tout seul et donc perte d'égalité, c'est donc "libre" entre guillemet, si on veut jouer à des guillemets…
[^] # Re: Et bah dis donc !
Posté par Thomas Douillard . Évalué à 3.
C’est plus compliqué de faire du proprio communautaire, par contre. En un sens, ça peut être une motivation forte pour faire du libre de fédérer une communauté. Donc même si tout est possible, si on calcule les corrélation sur l’axe libre/proprio avec le fait de faire du communautaire, on doit quand même trouver une corrélation. Interpréter la causalité est laissé en exercice /o\
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 18 mars 2022 à 19:30.
Pas vraiment :
- Ajout hors base de code "coeur" : système de plugins ou de thèmes ou de fichier de config pour tel équipement. Je suis vieux et ai surtout un souvenir de WinAmp qui était très très communautaire.
- Ajout dans le code "coeur" : PR acceptées dans un logiciel sous licence non libre mais code public. Exemple avec NumWorks (tiens, ils ont viré la licence CC… Ouvert, mais bon au fur et à mesure on limite les droits quand même. Mais le code est toujours visible et PR possibles).
Il y a un fort biais des gens aimant le libre communautaire à vouloir croire que c'est le seul libre possible et le seul long terme, mais la réalité est que tout est possible : le libre ne dit absolument rien sur le sujet de la communauté et la réalité a montré bon nombre d'exemples où c'est très différent de ce qu'on peut imaginer en premier lieu, et le non libre peut faire aussi bien voire parfois mieux que le libre (un avantage avancé est que l'interdiction de fork ne dilue pas le travail comme peut le faire le libre, quand on voit les 36000 distros Linux…).
Bref, un biais fait qu'on imagine son idée la meilleure, mais ça dépend : des fois ne libre ni le communautaire sont la meilleure réponse, des fois si, des fois l'un ou l'autre, et des fois même un mix libre et non libre peut être mieux. Beaucoup de possibilités, et le libre communautaire n'est pas forcément le moins compliqué, c'est une option possible parmi plein d'autres.
[^] # Re: Et bah dis donc !
Posté par Gof (site web personnel) . Évalué à 2.
D'où tu sort ça ?
Les gens qui aiment le libre communautaire (comme moi) connaissent très bien la différence.
Je pense que beaucoup de gens ici aiment le libre communautaire.
Mais évidemment il y a aussi du libre non-communautaire. Ça m'intéresse moins.
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 19 mars 2022 à 00:19.
Je n'aime pas le copyleft, mais le copyleft partagé est, il me semble, le moyen le plus fiable de garantir que le développement ne deviendra pas fermé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par Thomas Douillard . Évalué à 4.
J’ai pas dit que c’était impossible, mais que c’était plus compliqué. Et puis créer une communauté autour d’un système de thème c’est quand même assez différent de créer une communauté autour du cœur d’un logiciel.
Après il faut s’entendre sur ce que veut dire « communautaire » : est-ce que par exemple un OS comme Windows c’est communautaire parce que tout le monde peut l’étendre en développant des logiciels pour Windows ?
[^] # Re: Et bah dis donc !
Posté par Sébastien Burton . Évalué à 0.
Il me semble que tu regardes ces définitions sous un angle trop technique et en négligeant les aspects culturels qui les entourent. L'aspect communautaire est bien une fondation importante du mouvement libre (voir e.g. la Cathédrale et le Bazar, je suppose que tu l'as lu). J'aurais plutôt dit que le libre s'établit sur l'acte du don, négliger les aspects communautaires me semble une erreur.
[^] # Re: Et bah dis donc !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, mais parfois tu veux offrir sans vouloir gérer une communauté par exemple.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et bah dis donc !
Posté par Sébastien Burton . Évalué à 2.
Tout à fait d'accord. Je souhaitais simplement rappeler que les définitions en question se sont construites et propagées dans un contexte culturel particulier. Je pense que les points de vue exprimés ici ne sont pas aussi contradictoires qu'il y paraît en première lecture. Il faut juste prendre un peu de recul. :-)
[^] # Re: Et bah dis donc !
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 19 mars 2022 à 12:31.
Quand la réalité ne plaît pas, disons que la personne regarde trop la réalité mais qu'en fait il ne faut pas regarder la réalité…
La réalité est que :
La définition du libre n'a absolument rien à faire du communautaire, que ça te plaise ou pas. Que certains, dont ceux qui ont posé la définition, et encore ça reste à prouver car l'histoire de l'imprimante n'inclut absolument rien de communautaire, s’intéressent au communautaire ne dit rien sur le libre ne soit.
Le libre n'interdit pas de ne pas faire de communautaire, c'est la réalité, technique peut-être mais la réalité quand même.
Pareillement, le libre n'oblige aucunement à livrer gratuitement, le libre est neutre sur le prix, c'est la réalité.
Rappelons aussi que le libre n'interdit pas d'être utilisé comme support publicitaire : l'exemple du business model dans ce journal est explicite, un des fondateurs de l'entreprise dit lui-même que faire de la thune en GPLv3 est difficile, le libre est fait pour que tu fasses de la publicité gratuite tant que tu ne fais pas (trop) de thune avec mais pour la thune il faut passer par l'entreprise qui a fait le code, il n'y a aucune histoire, technique ou sur l'idée, de don. Li libre permet le don, mais ne se limite pas au don.
Et pourtant on peut faire du libre 0% communautaire. Car le libre ne dit rien dessus (il s’intéresse à celui qui reçoit et seulement lui, et il ne dit rien sur à comment il reçoit).
Pourquoi vouloir tant que ça limiter le libre à ses propres idées? On a l'impression que le libre fait chier à être trop libre… Perso c'est bien parce que le libre ne se limite pas au "non commercial communautaire" (par exemple), mais qu'il s’intéresse à mes droit en tant que personne qui reçoit, que je l'aime. J'aime aussi le communautaire et le gratuit mais c'est orthogonal au libre (et pour moi moins important que le principe du libre; et le communautaire et le gratuit est même pour moi moins important que de recevoir du code qui a encore plus de liberté que GPL, je préfère copyfree, mais je sais que c'est un choix perso et que GPL est 100% libre car je n'essaye pas de limiter le libre à ce qui me plaît).
# 60fps
Posté par Christie Poutrelle (site web personnel) . Évalué à 5.
Je regarde ce projet et lis leur "this week in…" régulièrement, c'est un projet qui à l'air super intéressant, je suis content de voir ce journal ici, je n'avais pas encore vu que le toolkit avait été renommé.
# Pas natif
Posté par David Demelier (site web personnel) . Évalué à 2.
Il y a écrit que c'est du natif en bureau mais en voyant la capture d'écran de la version macOS je constate immédiatement que ce n'est pas le cas. Aurais-je mal compris le terme natif ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas natif
Posté par Pinaraf . Évalué à 3.
Aujourd'hui c'est «look» natif, à base de Qt/QStyle, par opposition aux merdouilles HTML/CSS/JS (et du coup sous Linux c'est natif), mais «demain» ça pourrait être natif aussi sur OS X, cf https://github.com/slint-ui/slint/issues/44
[^] # Re: Pas natif
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Simple curiosité, ça se voit à quoi ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pas natif
Posté par David Demelier (site web personnel) . Évalué à 2.
Au style:
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas natif
Posté par Gof (site web personnel) . Évalué à 4.
Selon moi, « Natif » pour une application, a deux sens:
Ça veux dire que l'utilisateur n'est pas dépaysé par l'application et que le look and feel corresponds aux attentes de l'utilisateur et ressemble/s'intègre aux autre applications sur la plateforme.
L'application est compilée en en binaire qui tourne directement sur le processeur, et qui n'est pas réinterprété.
En gros, c'est souvent compris en étant mis par par opposition aux technologies Web.
Pour 2., Slint compile en code natif, donc c'est bon.
Pour 1., c'est l'objectif d'y arriver. Alors oui, Slint n'est pas encore parfait et il reste encore beaucoup à faire pour atteindre ce goal.
[^] # Re: Pas natif
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 18 mars 2022 à 12:19.
Quand on parle de lib UI, quasi tout le monde pense qu'à un seul sens (le point 1), surtout quand on parle de "style", le point 2 étant en réalité "évidement" disponible car considéré comme le minimum de nos jours (et ça peut râler quand un nouveau CPU arrive, car "natif" pour le vieux CPU ne veut pas forcément dire "natif" pour le nouveau CPU…).
Après, on peut débattre sur le "faux natif" (à la Qt qui fait ressembler sans utiliser le toolkit sous-jacent, ce qui fait toujours ressortir de complaintes des utilisateurs macOS :) ) vs "vrai natif" (à la Wx de tête, mais ça fait un moment que je n'ai pas regardé si ça s’intégrait bien sous macOS), votre objectif est du vrai ou faux natif?
[^] # Re: Pas natif
Posté par Gof (site web personnel) . Évalué à 2.
note objectif est du « faux natif ».
Ça dépends ce que tu veux dire par utiliser le toolkit sous-jacent.
Si veux dire que chacun de tes widget est un réel bouton du toolkit (chaque boutton est un NSButton*), alors effectivement non, c'est pas le but.
Mais Qt utilise le toolkit sous-jacent dessiner les widgets. Et là c'est bien le but oui.
Les utilisateur aiment se plaindre pour un tout et pour un rien.
Mais au final, le résultat avec Qt est pas trop mal. (Et je pense que un des problème avec Qt est que les plateformes de bureau sont un peu délaissées en ce moment.)
[^] # Re: Pas natif
Posté par barmic 🦦 . Évalué à 3.
Avec ce genre d'état d'esprit on va pas très loin, non ?
De mon expérience, les plateformes habituent ou pas à avoir des interfaces hétéroclites. Moi j'utilise awesome chez moi, i3 au boulot, je lance des applications en Qt, Gtk (différentes version), java swing ou tk j'm'en fou. Utilisateur qui a l'habitude (comme ça semble être le cas sur mac) d'avoir une cohérence bien plus forte, des détails vont être vu comme très désagréables. Ce n'est pas de la faute de l'utilisateur et le lui reprocher ne fait avancer personne.
Après à voir comment vous vous positionnez par rapport à ça. Est-ce que votre valeur est avant tout dans le multiplateforme ou un niveau d'intégration solide ? Etc Ça dépend de ce que vous voulais faire et de ce qui est demandé par votre cible d'utilisateurs.
Ou alors c'est que c'est pas si bien que ça. Perso j'en sais rien (et j'm'en fou en soit), c'est juste que tes remarques se valident entre elles dans un cycle que je voulais faire remarquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas natif
Posté par Gof (site web personnel) . Évalué à 2.
Je pense que c'est important d'être le plus intégrer et fidèle possible au moindre détail.
Ça inclus l'apparence, mais aussi le comportement (par exemple, qu'es-ce qui ce passe quand on fait en clic droit sur une bar de défilement)
Et je sais bien que les utilisateur se plaigne pour des détails et ils ont raisons. Chaque détail compte. Cela dit il me semble que dans l’ensemble, le résultat avec Qt est pas trop mal. Pourrait être mieux, oui, C'est toujours possible de faire mieux.
[^] # Re: Pas natif
Posté par David Demelier (site web personnel) . Évalué à 4.
Cela a changé avec Qt 6 alors, parce qu'avec Qt 5 on peut toujours « simuler » l'interface de n'importe quel système sur n'importe qu'elle plateforme (aka Windows sur Linux, macOS sur Windows).
Tiled, une application en Qt 5 par exemple sur macOS Big Sur est pas native et a un look-and-feel des anciennes versions de macOS (<= Catalina).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas natif
Posté par Gof (site web personnel) . Évalué à 2.
Non. C'était déjà le cas avec Qt5.
Par contre, le support des versions plus récentes de MacOs est mieux supportée avec Qt6.
[^] # Re: Pas natif
Posté par David Demelier (site web personnel) . Évalué à 3.
Baaaah alors je comprends pas pourquoi les applications Qt 5 n'ont pas du tout un look natif sur macOS.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas natif
Posté par Pinaraf . Évalué à 4.
Parce que ça dépend aussi de l'appli… Par exemple si ils mettent un bouton OK et un bouton Annuler sur un dialogue au lieu d'un ensemble «boutons standards» en y demandant «ok» et «annuler», Qt ne peut pas deviner l'ordre d'apparition des boutons. cf https://doc.qt.io/qt-5/qdialogbuttonbox.html pour ce cas.
Rien n'interdit aussi d'utiliser Qt et tout redessiner soi-même. Telegram fait ça par exemple.
Ou forcer un thème autre. Ou appliquer une CSS. etc etc
[^] # Re: Pas natif
Posté par David Demelier (site web personnel) . Évalué à 3.
C'est pas juste une position ou le respect des HIG de Apple, c'est clairement un autre style.
Exemple avec Terminal.app
Et avec Qt Creator (Qt 6)
La position des polices, la taille des polices, la couleurs du tab widget, la forme du selecteur de combobox. Rien ne va donc c'est pour ça que je ne comprends pas pourquoi si Qt 6 utilise les APIs native comme ça a été indiqué au dessus il y a autant de choses qui ne vont pas.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas natif
Posté par barmic 🦦 . Évalué à 3.
De ce que je comprends, ils utilisent les API de dessins bas niveau. Ça permet de faire des formes géométriques etc, mais pour tout ce qui est composant graphiques ils ont leur propre composants qui tentent de singer ceux du système. C'est un enfer à faire car chaque composant a un comportement bien à lui (je parle pas de mac en particulier tous les composants graphiques sont un trésor de complexité). Ajoute à ça que plus tu t'approche du composant que tu singe plus tu entre dans une uncanny valley.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas natif
Posté par Pinaraf . Évalué à 3.
D'après https://bugreports.qt.io/browse/QTBUG-86513 c'est implémenté correctement pour "big sur".
Résolu en juin 2021, donc Qt Creator 6 minimum si j'ai bien compris, et je crois que ce n'est pas la version de ta capture d'écran… (après je n'ai pas touché un mac depuis l'époque des Core 2 Duo donc je suis incapable de tester et comprendre les subtilités des choix d'apple)
[^] # Re: Pas natif
Posté par Gof (site web personnel) . Évalué à 5.
Qt6 (et Qt5) utilise certaines API native pour le rendu de certains trucs, mais pas tout, et pas complètement. Ensuite, vu que le style mac évolue lui aussi, il faut que Qt évolue aussi.
Après c'est une question de priorité de la part de Qt de faire évoluer le bureau.
Je pense que avec un peu d'effort, il n'est pas difficile de faire un thème vraiment natif. Disons une personne plein temps par exemple.
C'est mon avis que depuis pas mal d'année The Qt Company ne prioritise pas assez les plateformes desktop.
Donc on donc un total do 19 commits en 1 an sur le style mac (incluant des commits de maintenance général) ~400 lignes de code touchées. Pour donner une idée de combien d'effort est mis dessus.
Donc en conclusion, je pense que, moyennant un peu d'investissement, il est tout à fait possible de faire quelque chose de correct avec du « faux natif ».
Le fait que Qt n'est pas parfait est selon moi juste car Qt n’y met pas assez d'effort, et ne signifie donc pas que c'est impossible ou peine perdue.
# Quid de l’accessibilité ?
Posté par Space_e_man (site web personnel) . Évalué à 4. Dernière modification le 23 mars 2022 à 11:46.
Qt et GTK gère l’accessibilité, pour les personnes malvoyantes par exemple…
Qu’en est-il avec Slint ?
[^] # Re: Quid de l’accessibilité ?
Posté par Gof (site web personnel) . Évalué à 2.
On ne gère pas encore l'accessibilité, mais on prévoit bien sûr de le faire.
https://github.com/slint-ui/slint/issues/32
# les EFL, autre exemple de séparation code/UI
Posté par rogerwaters . Évalué à 2.
Les EFL (EnlightenmentFundation Libraries) proposent aussi une séparation de l'UI avec le code, et ce depuis le début des années 2000. Elles sont cross plateforme (linux, Bsd, Solaris, Mac, Windows). QML s'est inspiré des EFL avec Qedje en 2008 (Edje étant l'interpréteur de la description de l'UI dans les EFL), qui a évolué par la suite en QML. Un des plus jolis exemples d'utilisation des EFL avec cette séparation de code est calaos (le designer s'est occupé uniquement de l'UI, et le codeur uniquement de la partie C). En voici un résultat. Enlightenment lui-même est codé avec Edje, comme par exemple le sélecteur de background
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.