Enjolras a écrit 295 commentaires

Je vois mal comment construire un système de type cohérent sans valeur nulle. Le problème du C++, c'est que les pointeurs peuvent être nuls à l’exécution, pas que nul existe. Mais si tu n'as pas de type nul, tu n'as pas de fonction qui ne retourne rien, tu n'as pas de fonction sans argument, et j'en passe.

D'ailleurs, cite moi un langage qui se respecte ou null n'existe pas ?

Que, tout compte fait, dans le développement d'un logiciel, les développeurs sont aussi important que les utilisateurs.

Je ne comprends pas ton exemple de if .

Un widget, c'est un objet conceptuel que tu peux décrire dans un langage structuré, aussi compliqué soit il, sans avoir besoin de code. C'est juste un ensemble d'états et de propriétés, auxquelles tu peux lier des actions.

a forme du contenu, c'est le contenu. Sinon c'est de l'information brute.

Le principe des langages comme HTML ou xml c'est de stoquer du contenu structuré comme de l'information brute oui…

Le truc c'est que la mise en page du contenu dépend à la fois de l'appli elle-même et des traitements qu'elle fait que des CSS GTK3

Ca dépend de ton application, tu n'as pas forcément besoin de DOM, mais oui, je suis d'accord, ton layout peut changer en fonction des évènements. Je ne vois pas ce que tu cherches à prouver. Il faut distinguer thème et moteur de thème. Je pense que c'est là qu'on ne se comprend pas. C'est peut être parce que les devs GTK3 ont tenté d'utiliser CSS comme un moteur de thème, autant qu'un descripteur de thème.

Ce que tu décris, l'interaction sur le DOM, le fait de vérifier que le thème appliqué préserve bien la sémantique du document décrit, tout ça c'est du boulot du moteur de thème, et ça ne doit pas être réalisé en CSS. Il faut avouer que les devs GTK se sont laissé bercé par l'illusion que CSS allait leur ouvrir toutes les portes. Tu dis que l'utilisation de CSS avec GTK3 n'est pas souple, je veux bien te croire, je n'ai jamais tenté d'écrire un thème GTK ni même une application, ça ne me tente pas plus que ça. Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.

Il suffit de laisser le moteur de thème faire son boulot, et d'utiliser CSS pour faire ce qu'il sait faire, à savoir, décrire des propriétés héritables.
Et là, je ne vois pas où ça pose un problème, ce n'est pas à toi d'ajouter des sélecteurs, ça serait plutôt au moteur de thème de t'exporter des classes appropriées. L'idéal ça serait de pouvoir écrire soi-même très simplement un moteur de thème un peu comme Qt, mais ce n'est pas le cas.

Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris… Bah je pense qu'on ne devrait pas en arriver là et utiliser autre chose. Comme clutter.

Je note que tu évites encore la question, et que tu t'attaches à des points précis alors que je m'efforce de faire le contraire.

Non.
En HTML on a trois choses : le balisage, le contenu et la selection. Un widgets a en plus des états, des relations et de façon générale toute uen logique cablée qui influence son comportement.

Je ne vois pas pourquoi tu dis non. ce n'est pas parce qu'un widget est plus qu'un élément d'un langage de markup que ça n'en est pas un.

Mais la mise en forme ca influence le contenu. Si l'utilisateur a décidé de mettre la barre d'outil en vertical à gauche et de tripler la taille du texte j'ai le choix entre mettre à la poubelle ses préférences

C'est pas le contenu, c'est la forme du contenu.

Mais je veux pas ajouter de widgets, je veux simplement une méthode simple qui me permette d'utiliser mes bouttons dans les partie spécifiques de mon appli et les bouttons standards dans les parties génériques.

Oui, j'avais bien compris, je passe sur la suite parce qu'en fait, je t'ai déjà répondu. Tu ne fais que préciser et détailler les critiques que tu as déjà exposé et dont j'ai reconnu le fondement, mais tu ne réponds pas à la question : pourquoi CSS n'est il pas adapté ? Tu réponds juste que l'implémentation n'est pas assez poussée et intégrée, tu ne donnes aucun argument contre CSS.

En fait, en te lisant, j'ai l'impression que, malgré ton affirmation première, au lieu de dire qu'il ne faut pas utiliser CSS dans GTK, tu demandes à ce qu'on puisse utiliser CSS dans GTK3.

Soit dit sans fiel, fuis finaux fréquemment et fébrilement, il fraye finalement fort facilement avec finaud, ce qui fignolerait finement tes fadaises en frasques d'un fieffé filou.

Il n'empêche pas de faire un navigateur réactif. Mais il ne rend pas non plus un navigateur réactif. Pire, ça n'apporte presque rien à la réactivité. Et ce n'est pas parce qu'un navigateur n'a pas cette architecture que son architecture est pourrie.

Le CSS est principalement utilisé au sein des pages HTML, qui par leur DOM permettent de facilement désigner des éléments, des éléments imbriqués dans d'autres, etc.

Ce n'est pas parce que le CSS es utilisé comme ça qu'il ne peut être utilisé que comme ça.

J'ai trouvé ton commentaire très "pensez aux pauvres développeurs qui font un truc à moitié abouti, ne considérez pas leur travail comme mature même s'ils le disent, c'est plutôt bien pour ce que ça donne"

ce n'est pas que j'essaye de dire, ce que j'essaye de dire, c'est que même si une partie de ses critiques sont fondées, elles ne répondent pas vraiment à la question : en quoi le fait d'utiliser CSS est fondamentalement mauvais. Et en quoi le fait d'utiliser CSS est pire que les hacks de GTK2.

Mon commentaire visait juste montre que même si l'intégration du CSS n'était pas entièrement aboutit, les critiques remettent plus en question le manque de travail sur le sujet plus qu'un problème de fond qui interdirait l'usage de la technologie dans ce contexte.

Un jour, un maître programmeur interpella l'un de ses disciples:
- Si tu avais le choix entre programmer un logiciel de comptabilité et un noyau de système >d'exploitation, lequel choisirai tu ?
- Le noyau de système d'exploitation, maître.
- Bien, et pourquoi ?
- Programmer un système d'exploitation soit bien plus complexe et plus difficile que de programmer un logiciel de comptabilité, mais j'aurai néanmoins le choix des concepts que je pourrai utiliser. Alors que programmer un logiciel de comptabilité va me forcer à apprendre et à respecter des concepts et des règles archaïques immuables sans aucun degré de liberté.
- C'est bien, je te laisse tranquille.

AHAHAHAH :') !

Tu veux dire, libre de ne pas utiliser la norme PC-BIOS, libre de ne pas te conformer à des trucs désuets de POSIX, libre de ne pas coder pour x86, libre te te coltiner la compatibilité PIC… Etc etc

Tu peux certes repartir de zéro, mais c'est exactement pareil que pour le logiciel de comptabilité, tu as intérêt à ce que ça soit vraiment vraiment bon.

Et c'est pour ça que tu es devenu un troll lourdaud alors que tu aurais pu apprendre les nuances de ce que tu critiques pour le troller dans les règles de l'art.

Think about that.

Et, la fenêtre qui gère la boucle des évènements et les entrées utilisateurs, elle communique comment avec le contenu à ton avis ? Ca n'est pas très compliqué de voir le rapport avec ma phrase que tu cites, non ?

Sauf que… La réactivité n'a rien à voir avec ça. C'est en majorité une question de parallélisme, d'asychronie, et accessoirement par là de qualité du GC. J'imagine que le fait de ne pas avoir l'UI écrite en JavaScript doit pouvoir aider aussi.

Simple: une application Web est aussi lente qu'une application GTK2 sur une machine vielle de 8 ans.

Rassure moi, tu trolls ? Parce que bon juger CSS sur des critères comme ça… Il y a tellement de choses qui impactent ! La qualité du moteur de rendu graphique, la qualité du moteur javascript, la qualité du GC, la qualité des bindings DOM…

CSS est une goute d'eau la dedans, et son utilisation dans un toolkit écrit en C n'a pas trop de rapport à son utilisation dans un navigateur web.

je me suis dit que tu étais un trolleur

j'avais plutôt l'impression que c'était toi, après tout, le troll n'est il pas le fait d'affirmer des opinions sans les justifier ?

Il ne parle pas du noyaux mais de git (C'était d'ailleurs très clair en lisant la citation) et plus précisément, la performance de son point de vue d'utilisateur de git (oui, il n'est plus vraiment le dèv. de git). Il parle de l'expérience des utilisateurs au niveau de l'utilisation de git. Donc, c'est en plein dans le sujet.

J'ai du mal à voir le rapport entre git et GTK3, mais bon. L'important avec git, c'est qu'il ai fini sa tâche le plus rapidement possible.
L'important avec GTK3, c'est qu'il ait réussi à dessiner ce qu'on lui demande de manière assez rapide pour que l'utilisateur ne remarque pas la différence. Pour prendre un exemple dans le domaine du graphisme, à quoi ça sert de calculer plus de 60 FPS sur un écran de 60Hz ?

Sur un serveur, un envoi de mail qui a tous les coups prends 1s au lieu de 1/2s, cela signifie :
- Au moins le double de connexions tcp, de la mémoire, et des ressources réseaux monopolisées
- Du stockage sur les disques
- Et un effet en cascade

Je ne parle pas d'un serveur, ou en effet la performance a son importance. Je parle d'un client. Dans le monde de l'UX, de plus en plus d'opérations sont asynchrones, et n'affectent pas l'UI. Par exemple, quand j'ajoute une tâche dans le calendrier, je peux fermer la popup de l'utilisateur avant d'avoir ajouté réellement la tâche. L'ajout se faisant en arrière plan, la durée importe peu. Et cela a lieu trés souvent.

De même quand tu envois ton mail, il est placé dans la boite d’envoi, le temps que ça prend pour qu'il soit envoyé t'importe vraiment peu.

a) Qui a parlé de transformer le CSS en widget ?

Les widgets jouent un peu le rôle des balises HTML, et le CSS sert à définir le style. Je pense que ta distinction contenant contenu est mauvaise. Les widgets ne sont que du contenu sémantique, tout comme le texte. Par exemple, le widget "textbox" est un un contenu sémantique. On a bien un markup language comme HTML, qui propose un définition structurée sémantiquement du contenu. Il n'y a pas de contenant, tout est du contenu, sauf peut être la fenêtre de base.

• Il peut influencer le contenu (via margin , padding, font etc.)

Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. Ca ne touche pas le contenu, tu peux choisir la fonte que tu veux et la marge que tu veux, dans une certaine mesure, le sens du texte reste le même.

Les deux autres commentaires ne sont que des critiques sur l'implémentation du CSS dans GTK et ne remettent pas vraiment en question son utilisation.

b) Non, ce n'est pas la force du CSS. C'est la force de HTML combiné à CSS. Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS pour le thème dans GTK3 mais plutôt avec le fait que les widgets sont déjà définis et que GTK3 n'est pas un toolkit modulaire permettant d'ajouter des widgets. Ce que tu critiques est je pense voulu. Une classe par widgets, pour assurer l'uniformité du thème.

Le fait que GTK3 ne propose pas assez de classe, ni de manière d'ajouter des classes aux widgets, ou des classes par instances, est encore un problème d'implémentation et non un frein majeur à l'utilisation de CSS.

c) Pourquoi veut tu un DOM ?

Ce que tu demandes, c'est ce que GTK3 ne te fournit pas, mais encore une fois, non parce qu'il utilise CSS, mais parce que ce n'est pas son but. Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.

En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais, et qu'il t'impose un usage de CSS, en utilisant des widgets et leur classe de manière globale.

d) GTK3 assume l'utilisation d'un sous-ensemble de CSS, je ne vois pas en quoi c'est un problème en soi tant que c'est documenté.
Quelle est la différence avec un navigateur qui n'implémente pas toutes les propriétés ?

Pour résumer ton commentaire, tu dis que GTK3 ne répond pas à tout tes besoins et ne te permet pas une aussi grande souplesse qu'un site web. Je pense que les problèmes que tu soulèves sont fondés, mais, il faut comprendre que GTK3 est développé par une équipe trés réduite et qu'on ne peut pas coder ce que tu demandes en 1an.

Laisse moi te poser deux questions. Même si ces critiques sont fondées, en quoi remettent t'elles en question l'utilisation de CSS ? Quand je lis ton commentaire, j'ai l'impression que tu voudrais au contraire que CSS soit mieux intégré à GTK3, et qu'il te permette de définir des styles par widgets et non par classe de widgets, et ce dans un DOM complexe.

Ce n'est pas parce que ce n'est pas le cas que CSS ne remplit pas son rôle actuel, et j'aimerais surtout savoir autre chose : en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?

J'ai quand même l'impression que les utilisateurs finals ont l'impression que les développeurs n'existent pas.

le manuel

Hurd est un noyau

Non. Hurd est un OS, pas un noyau, enfin, pas entièrement un OS, mais beaucoup plus qu'un noyau.

Dans un navigateur web, la situation est totalement différente..

Oui, c'est vrai, quand tu as une action sur l'interface, en général, tu ne veux pas que le navigateur réponde instantanément.

D'ailleurs, parler de vitesse ne me semble pas réellement approprié, il vaudrait mieux parler de latence.

De toute manière, il faudrait 2 niveaux d'addons: une API interne qui peut tout faire mais avec lesquels tu n'as pas la sécurité et une API externe qui est dans un processus séparé: moins de souplesse mais tu as la sécurité.

C'est marrant, ça me fait beaucoup penser à firefox.

Oui euh Chrome est plus performant que Firefox donc visiblement ils ont réussi a surmonter l'obstacle.

Chrome a un meilleur GC, un meilleur JIT javascript, un meilleur backend graphique, une gestion du cache plus poussée, et divers hacks.

Mais indépendament de ça, tu t'échines à voir la séparation en processus distincts comme la recette ultime de la performance.

Pour toi, l'affirmation d'une seule personne sortie de son contexte est une vérité absolue et immuable ?

Peux tu répondre aux exemples que j'ai proprosé plutôt que de laisser les autres penser à ta place ?

Chrome est plus performant, chrome a plusieurs processus. Ça ne signifie en aucun cas que l'un implique l'autre.

s/avoir/à voir/

Et dans ce cas, ta demande deviens plus d'utiliser dwm qu'autre chose

Sans tomber dans dwm, je pense que sa demande se rapprocherai plus de e17 et de sons sytème de thème en format binaire.

Je pense que tu fais exprès de ne pas comprendre ce que je dis.

Dans un navigateur, il en sont arrivés à un point ou la performance avait un impact sur les fonctionnalités. Donc ils optimisent ce qui a un impact. Sur GTK3 ce n'est pas le cas. GTK3 tourne très bien sur mon raspberry pi.

Quant à ce que tu cites, ça n'a rien à voir avec CSS en fait. Les JIT ont avoir avec javascript. L'accélération matérielle n'a rien avoir avec l'interprétation de CSS mais avec le rendu, et que tu utilises CSS ou n'importe quel langage qui te passe par la tête, il faut bien en passer par là.

tout ça pour obtenir un résultat minable si on compare un quadruple cœur avec un navigateur et un pentium 4 avec une application native GTK2 (et je ne vais pas comparer avec d'autres toolkit, ça serait insultant).

je ne comprends pas vraiment ta phrase.

Et sinon, parler de "simplicité technique et de lisibilité du code" avec CSS, comment dire …

Je vois mal comment écrire un langage déclaratif plus simple. Au lieu de troller dans le vide, je te saurais gré de faire des critiques construites et intéressantes

Sans compter que quand ma présentation beamer de 40 slides prend 12s à compiler, je ne trouve pas que ça soit rapide.

Tu peux t'abriter derrière la pensée de qui tu veux, je pense que cette citation n'a pas d'objet ici. On ne parle pas de correction d'un algorithme d'un calcul, et de privilégier le résultat rapide et approché qu'au résultat exact. Je parlais de simplicité du code, et de facilité d'utilisation de la technologie, j'ai du mal à voir le rapport avec la correction d'un algorithme. C'est un problème entièrement différent, mais, je pense que si on essai de la raccorder au sujet, ta citation va dans mon sens.

En effet, Linus applique le même raisonnement que je fais sur la performance, mais lui le fait à l’exactitude. Linus travaille dans le développement d'un noyau, où, bien souvent, la fonctionnalité principale d'un composant est sa performance, tout autant que son bon fonctionnement. Ce qu'il dit, c'est qu'il ne faut pas s’entêter à chercher l'exactitude a priori tant qu'on n'est pas certain d'en avoir besoin.

Et bien, c'est pareil pour la performance. Que t'importe que ton mail prenne 1/2s ou 1s à être envoyé ? Est ce que le fait qu'ajouter une tâche dans un calendrier prenne 50ms de moins est important, surtout si l'UI cache le temps que prend l'opération réelle ? Je ne pense pas.

Pour plagier linus,

"performance" is often irrelevant because it doesn't matter.