Gof a écrit 2222 commentaires

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.

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)

Merci d'avoir passé du temps à regarder les détails.

Contrairement à ce qui est écrit, l'interface est tout sauf native. C'est du dessiné

Comme ce qui a été dit plus haut, par "natif", je fais l'opposition à "web" qui tourne dans un browser.

faîtes un click droit sur une zone texte, et vous n'aurez pas le menu classique de copier/coller

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.

Mais ça foire complètement sur les hôtes qui ne sont un minimum customisés.

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

Sur la version mobile de la démo web […] il met un < input > caché sous le canvas de dessin.

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.

Et pour l'embarqué, il y a LVGL qui est quand même LA référence.

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

Ma série d'espionnage favorite: Deutschland 83 (première saison uniquement)

Tu peux laisser TrSync en MIT tout en utilisant Slint car la MIT est compatible avec la GPL.

Autrement dit, le code de TrSync peut être en MIT. So quelqu'un veux forker ton code pour faire du propriétaire, il peut, s'il utilise la licence propriétaire de Slint (qui a une variante gratuite)

Pour l'interface graphique, as tu envisagé Slint?

Ah, même pas 20 ans!

Donc le problème était que j'utilisais un navigateur mobile sur mon téléphone, et cette date n'est pas sur cette page.
J'ai ouvert la page sur mon ordinateur et là je vois bien la date.

Bizarre, je ne trouve pas cette information pour mon compte. Je dois être aveugle

Donc par curiosité, j'ai regardé dans le code du client nextcloud, et ils ont mis cette fonctionnalité de confirmation optionnelles en 2016 [1] et ils l'ont même désactivée par défaut en 2019 [2].

Je pense que le message ennuiyait les utilisateurs qui supprimaient vraiment tout les fichiers. Mais quand même, quand on sait que ce genre de problème arrive fréquemment, je trouve qu'il est préférable de demander avant de tout supprimer. Mieux vaut prévenir que guérir.

[1] https://github.com/nextcloud/desktop/commit/74a8c4aae8fcfa09c4d0374c8fe72579ba3ccc44

[2] https://github.com/nextcloud/desktop/pull/1201

Je contribuais au client ownCloud il y a bien longtemps (avant le fork) et on avait implementé une sécurité qui détecte se cas où tout les fichiers ont changés qui signifie que le server a changé, et qui affiche un message de confirmation avant de synchroniser, ou de ré-uploader tout les fichier.

Je ne sais pas pourquoi ça n'a pas marché dans ton cas. Peut être que le client nextcloud a supprimé cette fonctionnalité ? Où il y a eu un bug et ça n'a pas marché ?

Après avoir créé une branche, il faut aussi y passer.
Pour ça il y a git switch. Et cette commande peut même être utilisée à le place de git branch pour créé une branche.

Et sinon, indispensable pour faire le ménage dans sa branche avent de faire une pull request: git rebase -i

La plupart des chaines présentées ci-dessus se regardent très bien à x1,5.

Et le reste en x2 ?

Perso c'est la vitesse a laquelle je regarde la plupart des enregistrements de conférences.
Avec l'habitude ça devient quasiment une vitesse normale et le reste semble lent.

C'est toujours compréhensible comparé à écouter un aveugle utiliser un lecteur d'écran configuré a quelque chose comme 10x.

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.