Gof a écrit 2222 commentaires

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.

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.)

sans pour autant rendre les sources disponibles sur le grand ternet.

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)

Je suis grosso-modo d'accord avec toi.

logiciels spécialisés

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.

vente de produit très diffusé à 1 €

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 ?

ici le libre n'est pas vu comme "positif" mais comme une contrainte "négative" pour vendre du non libre

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.

note objectif est du « faux natif ».

ressembler sans utiliser le toolkit sous-jacent

Ç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.

ce qui fait toujours ressortir de complaintes des utilisateurs macOS

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.)

Selon moi, « Natif » pour une application, a deux sens:

1. Ç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.

2. 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.

faire du libre, même du GPL3, n’empêche absolument pas de commercialiser

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.

Sauf quand j'installe, pas réinstalle

Via les MàJ uniquement, sauf quand je change de PC.

17 ans déjà… https://linuxfr.org/users/gof/journaux/archlinux-07-vient-de-sortir
(et toujours utilisateur)

Pure invention

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é.

peut on commercialiser un logiciel bâtit avec Slint sans payer de licence si on publie les sources ?

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.

Comment ça fonctionne ? Est ce que vous utiliser QStyle comme un canvas

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.

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é.

utiliser des templates est moins capilo-tracté que manipuler le TokenStream

Tu peux utiliser des templates dans une macro, et simplement convertir la le résultat avec TokenStream::parse a la fin

L'aventage de la macro comparé a apeller rust toi même c'est que ça s'intègre avec cargo qui gère les flag compliqué pour toi comme la cross compilation, le compilation incrementale, et que sais-je.

J'ai pas compris l'exemple, ce code irait dans le main.rs du projet ?

L'idée est qu'il n'y a pas de main.rs. Uniquement un Cargo.toml qui dit a cargo d'ouvrir lui même (a cause du path = "Cargo.toml") et de simplement apeller ta macro qui fait le reste.

Mais pas sur que ce soit idéal en pratique.

Tant qu'a générer du Rust, tu peux aussi utiliser des macro procédurale.

Donc l'utilisateur devra juste avoir un Cargo.toml et un main.rs avec

letlang::compile_file!("main.letlang");

Et la macro se charge de produire le code en rust.

Pour les erreurs, je suggère codemap-diagnostic

Prendre des p'tits bouts d'trucs, et les assembler ensemble

Et compiler le résultat tranquilles dans ta chambre ?

Ceci est juste une idée à la con, mais si tu pourrait avoir un self-contained Cargo.toml (qui est à la fois valid toml et rust) comme fichier pour le build système:

#[letlang::letlang] load_file!("main.letlang"); /*

[package]
name = "my_letlang_app"
version = "0.1.0"
edition = "2021"

[[bin]]
name = "my_letlang_app"
path = "Cargo.toml"

[dependencies]
letlang = "*"

# */

Je n'ai pas lu tout le journal, mais en le parcourant rapidement, j'ai appercu un troll sur les languages de programmation et je n'ai pas pu m'empêcher d'y mordre.

Pourquoi utiliser C et pas un autre langage de programmation ?
[…]

Donc si je comprends ton argumentation, c'est du même style qu'un auteur qui a écrit tout un livre avec notepad.exe à qui on demande pourquoi il n'a pas utilisé un éditeur plus moderne comme vim, emacs, ou LibreOffice.
Sa réponse est qu'il n'a pas encore utilisé beaucoup ces programmes mais que notepad c'est mieux car il est plus habitué, préfère avoir contrôle de chaque caractère et que c'est plus simple, d'ailleurs Bill Gates lui-même connaîtrait moins que 60% des raccourcis clavier de Microsoft Word. Même s'il n'y a pas de correcteur orthographique ou grammatical sur notepad, le clavier virtuel de son écran tactile détecte déjà pas mal d'erreurs de toute façon.

C'est vrai qu'il aurait pu aussi écrire le livre avec un éditeur hexadécimal à la place, mais il est une grosse bouse en hexadécimal. Et puis ce n'est pas portable à cause des différents encodage.

C'est a cause de gens comme toi que nonante pourcent des gens dans les hôpitaux ne font pas de backups

Et les raisins ? Est il nécessaire qu'il soit de Corinthe ?

En fait la spec dit que les race condition sont des "undefined behaviour". Donc ils respectent bien la spec, et ce qui est considéré comme une faille de sécurité en rust est juste un truc normal en C++

Je confirme, c'est bien précisé dans la doc

La documentation des anciennes versions de rust aussi

This function does not follow symbolic links and it will simply remove the symbolic link itself.

Mais bon, il y a une race condition qui existait dans l'implémentation, et qui existe aussi, dans la plupart des fonctions équivalentes dans diverses bibliothèques.

Par exemple dans libc++:
https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b50122a161b91f59f19c9bd0d19/src/filesystem/operations.cpp#L1145
Si la directory p deviens un lien symbolique entre la ligne 1144 et 1145, il va suivre le lien symbolique.

Mais il faut que user1 soit capable de créer un dossier et de le remplacer par un lien symbolique en boucle pendent la suppression du compte.

Je rappelle que rust ne suis pas les lien symbolique quand il supprime récursivement. Mais le code fait comme ça.

1. Est-ce que le répertoire $X est un lien symbolique.
2. Sinon, alors ouvre le répertoire $X et supprime le contenu.

Il n'y a un problème que si quelqu'un a changer le répertoire $X pour devenir en lien symbolique entre l'étape 1. et 2.

Par ailleurs, le problème existe dans quasiment tout les langages. Il semblerait que les implémentations de std:: filesystem::remove_all de GCC et clang ont exactement le même problème. Pareil pour la fonction équivalente dans Qt.
Et les languages qui ne proposent pas de fonction équivalente laisse l'implémentation au développeur qui a 99% de chance de faire la même erreur.

Bref, ça montre juste que la barre pour les annonce de sécurité de Rust est assez haute.

Le fait que ça puisse être réalisé par un programme privilégié est la cerise sur le gâteau, mais déjà en soi c'est assez grave.

En quoi est-ce grave pour un programme non privilégié ?
Un attaquer qui a déjà les même privilèges que le programme pourrait tout simplement supprimer les fichiers directement.

Le bug ne se manifeste que si un attaqueur essaye activement de produire une race condition en remplacent un répertoire par un lien symbolique en countinu.

L'idée c'est d'avoir un nouveau language qui, bien que inspiré très fort par QML, corrige certains défauts.
Le but étant d'avoir un language qui peut être modifié par un éditeur graphique (qui reste encore à écrire). Mais aussi être compilé pour fonctionner avec du matériel très limité.

Par exemple, les expressions dans le language ne sont pas en JavaScript, mais juste de simple expression. La logique va dans le code dans un language de programmation. Chaque fichier est self-contained donc on peut facilement visualiser un composant.
Tout est typé ce qui permet d'optimiser mieux.

C'est l'esprit de la GPL: de promouvoir son usage.
La GPLv3 promeut son usage eu détriment de la GPLv2 qui est dépassée.

Alors oui, je suis au courant des incompatibilités si on veut utiliser une libraries GPLv2 avec, comme entre perf et libbfd [https://eighty-twenty.org/2021/09/09/perf-addr2line-speed-improvement] et c'est dommage qu'il n'y ait pas de solution pour ça.

Mais bon, de nos jour, les nouveaux trucs GPL sont fait en GPLv3.

Les liens sont un peu datés.