Gof a écrit 2210 commentaires

Ce que j'ai fait c'est juste implémenter le générateur moi même avec un simple script qui remplace des expressions régulières dans les pages. Chaque entrée de blog est une page HTML et il y a des commentaires dedans pour les métadonnées que le script parse pour assembler le tout.

Ma question par contre:
Qu'utilisez vous pour les commentaires et les statistiques ?

Ils en parlent in peu dans une sous-page comme un des multiples exemples qui font que faire évoluer le C++ est difficile.

Le problème c'est que ton journal laisse penser que le maintien de l'ABI est la principale raison qui a poussé Google pour créé ce langage. Et c'est loin d'être le cas.

Ils veulent juste un langage plus sûr, plus facile a apprendre et utiliser, tout en gardant les même performances que C++ et interopérabilité avec le code c++ existant.

Bref, c'est même pas la performance qui est la motivation, puisqu'il disent qu'ils veulent les mêmes performances que C++, pas de meilleures.

« évolution climatique » ?

Le journal parle beaucoup d'ABI, mais c'est pas du tout la raison derrière Carbon. Si tu lis la description de la motivation sur leur GitHub, l'ABI n'est même pas mentionnée.

Alors déjà non, certaines distributions ne recompile pas le monde a chaque mise a jour du compilateur.

Ensuite le C++ est vachement utilisé dans l'industrie du propriétaire, là où il n'est pas rare d'avoir des binaires précompilés propriétaires dont on a pas les sources.

Et puis les SONAME ne marche pas avec des dépenses transitives. (libQt depends the libstdcpp.so.42, mais ton application veux être compilé avec un nouveau compilo qui utilise libstdcpp.so.43, et tu ne peux pas mélanger les deux)

Mais dans ce cas, il n'y a pas besoin de changer la représentation interne de std::thread. Si j'ai bien compris la différence c'est juste l'appel a join() dans le destructeur. Donc c'est un changement d'API, pas d'ABI.

(Les changements d'ABI dont on parle sont ceux qui cassent les applications qui mélangent des objets compilé avec des versions différentes du compilateur, mais qui ne cassent pas les ancien programmes tant qu'on recompile le tout)

Le problème c'est que c'est souvent pas si simple.

Par exemple, la fonction "à éviter" est parfaitement lisible pour moi.
En pratique, les fonction sont bien plus longues et donc plus dur à diviser

bool readTemperature(Sensor * sensor, Field field; const char *filename) {
    SensorHandle *sensor_handle = connectToSensor(sensor, NULL, true);
    Value *v = readSensorValue(sensor_handle, field);

    FILE *fp = fopen(filename, "w");
    if (fp) {
        fwrite(... v ... field ...);
        fclose(fp)
    }

    freeSensorValue(v);
    freeSensorHandle(sensor_handle)
    return fp != NULL;
}

Alors bon, tu dois passer plein d'arguments

bool readTemperature(Sensor * sensor, Field field, const char *filename) {
    SensorHandle *sensor_handle = connectToSensor(sensor, NULL, true);
    Value *v = readSensorValue(sensor_handle, field);

    bool ret = writeSensorValue(v, field, filename);

    freeSensorValue(v);
    freeSensorHandle(sensor_handle)
    return ret;
}

void writeSensorValue(Value *v, Field field, const char *filename) {
    FILE *fp = fopen(filename, "w");
    if (fp) {
        fwrite(... v ... field ...);
        fclose(fp);
        return true;
    }
    return false;
}

Ok, dans cet exemple c'est encore correcte mais il y a des cas ou séparer en différente fonction demande de passer tellement de paramètre que le boiler plate rends le code plus difficile à lire, surtout si l'ordre des trucs est changer.
Et il y a plein de question comme quelle fonction dois libérer les ressources.

Enfin soit.. qui écrit encore en C de toute façon?
Perso, j'écrirais plutôt le code comme ça:

bool readTemperature(Sensor &sensor, Field field, sting_view filename) {
  auto sensor_handle = sensor.connectSensor();
  auto v = sensor_handle.readValue(field);

  if (auto file = File::create(filename)) {
     file.write(... v .. field);
     return true;
  };
  return false;

}

Comment tu expliques dans un modèle géocentrique : […]

Avec des epicycles.

L'éloignement des étoiles était justement la réponse de Galilée

Oui, il faut supposer plein de choses. C'est plus du domaine de la croyance que de la science.

Comme je l'ai dit, c'est comme la théorie MOND ou d'onde pilote

Ces théories sont attrayantes car elles expliquent certaines observations et simplifient certains modèles, mais il y a aussi des trucs qui cloche.
Elles sont intéressantes, mais reste considérées comme théories alternative.

Il n'a pas pu démontrer que son modèle était bon, mais il a largement contribué à le rendre meilleur

On est bien d'accord. Il était un scientifique exceptionnel qui a fait avancer la science dans plein de domaine.
C'est juste dommage qu'il est retenu pour son combat contre la méchante Église alors que c'est pas si blanc et noir.

A l'opposé, les arguments expliquant que la Terre était au centre de l'univers, c"était "parce que !" et "la théorie de l'héliocentrisme n'est pas parfaite !".

Non, c'était le consensus scientifique de l'époque.

Quand Galilée publie le 13 mars 1610 son ouvrage Sidereus nuncius qui confirme entre autre la théorie héliocentrique

En fait non, les observations de Galilée ne confirme pas l'héliocentrisme.

Toutes ses observations peuvent être expliquées dans un système géocentrique.
Un système héliocentrisme simplifie un peu le modèle du mouvement des planètes (pas besoin d'épicycles), mais ce n'est pas une raison suffisante pour confirmer le modèle. Au contraire, l’héliocentrisme laissait pas mal d'observation non expliquée. Pourquoi n'observe t'on pas d'effet de paralaxe avec les étoiles ? (car en fait les étoiles sont bien plus lointaine que ce que les gens de l'époque ne pensait.) Pourquoi est-ce que nous somme attiré vers le centre de la terre si ce n'est pas le centre de l'univers ? (Newton et sa théorie de la gravité arrivent bien plus tard). Ne sentirions nous pas la terre bouger ? (En fait Galilée prétendais que c'est ce qui cause les marées, alors que pas du tout)

Bref, pour les scientifiques de l'époque, il n'y avais pas de raison de croire que Galilée avait raison. C'est juste un modèle intéressant comme l'une des multiple théories des cordes aujourd'hui ou les théories qui explique la dark matter (MOND et autre théories "alternatives").

La persistance de Galilée n'était pas justifiée. Même si au final il avait raison, il avait raison pour des mauvaises raisons. Et l'Église dans l'histoire n'est pas les méchant-contre-la-science qu'on aime peindre aujourd'hui.

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

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.

➜  qtbase ✗ git log --oneline --since "one year ago" -- src/plugins/styles/mac | wc -l
19
➜  qtbase ✗ git diff HEAD "HEAD@{one year ago}" --stat  -- src/plugins/styles/mac 
 src/plugins/styles/mac/.prev_CMakeLists.txt |  23 +++++
 src/plugins/styles/mac/CMakeLists.txt       |   3 +-
 src/plugins/styles/mac/mac.pro              |  19 ++++
 src/plugins/styles/mac/qmacstyle_mac.mm     | 409 +++++++++++++++++++++++++++++++--------------------------------------------------
 4 files changed, 201 insertions(+), 253 deletions(-)

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.

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.

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

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.

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