Ce journal continue la série commencée dans mon journal précédent.
C´est un conseil qu´on ne devrait pas avoir à donner en 2012. Après tout, dès 2000, il y a 12 ans, Joel Spolsky avait publié un fameux article sur ce sujet. C´était à l´occasion de la sortie désastreusement retardée de Netscape 6.0.
Traduisons-en les premiers paragraphes:
Netscape 6.0 va enfin sortie dans une première version bêta. Il n´y a jamais eu de version 5.0. La dernière version majeure, 4.0, est sortie il y a presque trois ans. Trois ans, ça fait terriblement longtemps dans le monde d´Internet. Pendant ce temps, Netscape est resté immobile, impuissant, alors que ses parts de marché s´effondraient.
Allez, je suis un peu vache de les critiquer pour avoir laissé tant de temps s´écouler entre les sorties. Il ne l´ont pas fait exprès, n´est-ce pas?
Eh bien, si. Ils l´ont fait exprès. Ils l´ont fait en commettant la pire de toutes les erreurs stratégiques qu´une entreprise informatique peut commettre:
Ils ont décidé de réécrire le code à partir de zéro.
La thèse de Joel Spolsky dans cet article est que les réécritures sont contre-productives parce que, si le vieux code semblait moche, il n´y a généralement pas de raison que le nouveau code soit meilleur, et par contre, il y a de bonnes raisons pour qu´il soit moins bon puisque l´on perd au passage tout un patrimoine de corrections de bugs.
Quand Joel Spolsky écrivait ça en 2000, il avait déjà un bon stock d´exemples à donner. Ce qui est incroyable, c´est que 12 ans plus tard, on n´a rien appris. On peut aujourd´hui donner de nombreux nouveaux exemples dans la galaxie libre.
À tout seigneur tout honneur, commençons par KDE4. (*)
Vers 2006, KDE 3.5 était l´environnement de bureau le plus populaire pour Linux/X11, seul GNOME arrivait peut-être ex aequo. Quand Asus a lancé son fameux Eee Pc, le premier des netbooks à succès, il tournait sous un KDE 3.5 modifié. Si le projet KDE avait travaillé de concert avec Asus pour améliorer le produit de façon incrémentale, je suis sûr qu´Asus aurait été ravi. Seulement, en 2006, une seule chose importait pour le projet KDE: le futur KDE4, qui, quoiqu´en disent les développeurs de KDE, était bel et bien, en grande partie (les composants les plus visibles ayant été les plus touchés) une réécriture. Lorsque KDE 4.0 est finalement sorti en 2008, il n´était toujours pas prêt à être installé par défaut par des OEMs, et Asus avait depuis longtemps abandonné le navire et retenu Windows XP comme unique choix pour ses Eee PCs.
Certaines applications de KDE ont été encore plus touchées. Amarok, entre les versions 1.2 et 1.4, était probablement le meilleur lecteur audio de son temps. Amarok 2.x n´est pas mauvais… mais il n´offre pas grand chose de plus. On peut se demander si tout le temps pris a développer et stabiliser les versions 2.x était un bon investissement.
Et ne parlons même pas de KMail, qui était un bon client email à l'époque de KDE 3.5, et qui a pris tant de temps à se porter au nouveau système de KDE 4, appelé Akonadi, qu´entre temps, la notion même de client email de bureau a presque disparu, la majorité des utilisateurs préférant désormais les webmails.
D´autres exemples? On pense bien entendu à GNOME 3. Là encore, les développeurs ne le considèrent pas comme une réécriture, et pourtant, le composant le plus visible pour l´utilisateur, GNOME Shell, est un logiciel tout neuf qui vient remplacer les solutions existantes: difficile de ne pas appeler ça une réécriture. On retrouve les mêmes conséquences néfastes pour le projet: transition plus longue que prévu, utilisateurs mécontents de la nouvelle solution, perte d´opportunités stratégiques.
Pourquoi ces grands projets de logiciels libres ont-ils cette propension à commettre cette erreur?
Dans un logiciel libre se reposant sur le volontariat, chacun préfère travailler sur les projets les plus intéressants sur le plan technique. Lire, comprendre, débugger, améliorer le code existant, c´est ennuyeux. Écrire du code tout neuf en se croyant plus malin que les auteurs du code existant, c´est bien plus gratifiant.
Il est donc très important pour la réussite des logiciels libres, de bien valoriser le débogage et l´amélioration incrémentale du code existant. C´est une question de culture. Faire circuler le lien vers ce bon vieil article de Joel Spolsky serait un début!
(*) Je précise que je suis un ex-développeur de KDE4, coupable de certaines fonctionnalités bling-bling inutiles du type même de ce qui me fait critiquer KDE aujourd´hui. Et j´utilise encore KDE4 (et Amarok 2) parce que ça reste ce qui me convient le mieux.
# Pourquoi réécrire ?
Posté par rewind (Mastodon) . Évalué à 10.
Parce que pour faire un bon logiciel, il faut l'écrire deux fois. La première fois, on commet toutes les erreurs et la seconde fois, on sait comment bien le faire (avec des fonctionnalités identiques).
[^] # Re: Pourquoi réécrire ?
Posté par 2PetitsVerres . Évalué à 5.
Pour ça il faut que ce soit la même personne (ou la même équipe) qui le fasse…
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Pourquoi réécrire ?
Posté par rewind (Mastodon) . Évalué à 2.
Dans tous les exemples données, c'est le cas…
[^] # Re: Pourquoi réécrire ?
Posté par Octabrain . Évalué à 3.
C'est la même entité, mais pas forcément les mêmes personnes. Tu as vu si les auteurs originaux de nautilus de gnome2 sont les mêmes que ceux qui le maintenaient récemment ? Idem pour KDE4, un certain nombre de développeurs sont certainement les mêmes sur l'ensemble du projet, mais combien ne sont pas ceux du début (et qui donc ne mesurent pas forcément les erreurs qui ont été faites) ?
[^] # Re: Pourquoi réécrire ?
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
En fait, que ça soit le cas ou pas ne fait pas une grande différence. Être la même personne n'offre pas une bien grande garantie contre les régressions. La seule garantie contre les régressions est d'avoir une batterie de test unitaires vraiment très exhaustive (KDE n'a que quelques maigres parties couvertes par des tests unitaires) et d'avoir une règle très stricte de rejet de toute modification qui régresserait un test unitaire sur une machine de test (KDE n'a pas à ma connaissance de machine de tests ni de règle de rejet de patchs causant des régressions, en tout cas n'en avait pas à l'époque de la réécriture).
[^] # Re: Pourquoi réécrire ?
Posté par Batchyx . Évalué à 4.
Ou sinon, il suffit juste d'avoir une batterie d'utilisateurs qui vont bien te faire chier quand ça marche plus. Cette technique fonctionne très bien avec le noyau Linux.
[^] # Re: Pourquoi réécrire ?
Posté par Antoine . Évalué à 3.
C'est à voir, il y a par exemple eu des régressions sur la consommation énergétique du noyau ces dernières années.
[^] # Re: Pourquoi réécrire ?
Posté par Octabrain . Évalué à 4.
Second-system_effect
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pourquoi réécrire ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Sauf pour les EFL, ou c'est 4 fois.
"La première sécurité est la liberté"
# Nokia et Maemo/Meego est aussi un bon exemple
Posté par tanguy_k (site web personnel) . Évalué à 10. Dernière modification le 12 août 2012 à 23:04.
L'un des meilleur exemple est certainement Nokia et Maemo/Meego.
(Grosso modo pour simplifier)
Au depart c'est un OS base sur Debian avec dpkg qui utilise une version etendue/modifiee de GTK+. Maemo est sortie en 2005, ils avaient plusieurs annees d'avance sur tout le monde !
Puis ils se sont rendu compte que Qt est bien meilleur que GTK+/GLib, ils ont achete Trolltech et decide de virer GTK+/Glib au profit de Qt
-> re-ecriture
Puis ils se sont allies avec Intel. Du coup Maemo (devenu Meego) ne se base plus sur Debian et dpkg mais sur RPM
-> re-ecriture
Puis les developpeurs de Qt ont sortie QML et donc les devs de Nokia se sont dit qu'ecrire
QWidget * widget = new QWidget()c'etait has been et ont decide de basculer sur QML-> re-ecriture
Elop a dit stop. On connait le resultat.
D'apres ce que j'ai compris, les devs de KDE re-ecrivent les applications pour profiter de QML mais de facon intelligente : petit a petit, de facon iteratif et c'est ca la solution.
LibreOffice fait de meme : ils refactorent/nettoient le code de facon iterative.
[^] # Re: Nokia et Maemo/Meego est aussi un bon exemple
Posté par Benoit Jacob (site web personnel) . Évalué à 8.
Oh oui, que Nokia est un bon exemple de réécritures inutiles, que je regrette de ne pas avoir mentionné.
Mais je ne fais pas la même interprétation de la décision d'Elop. Pour moi, Elop n'a fait qu'ajouter une entrée de plus dans la longue liste des réécritures inutiles:
- Elop décide que Windows Mobile c'est mieux que Qt.
Bref, un exemple de plus.
+1 pour les transitions itératives, c'est bien le contraire des réécritures que je pourfends. Je n'en sais pas assez sur QML pour savoir si ça tombe dans cette catégorie.
[^] # Re: Nokia et Maemo/Meego est aussi un bon exemple
Posté par lolop (site web personnel) . Évalué à 2.
Sauf que Windows Mobile ne se place pas au même niveau que Qt, mais au niveau d'Android ou iOS.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Nokia et Maemo/Meego est aussi un bon exemple
Posté par TImaniac (site web personnel) . Évalué à 10.
Je trouve au contraire que c'est un très bon contre-exemple de ton raisonnement :
Windows Phone choisi par Elop est effectivement une réécriture de Windows Mobile (quoique c'est le même OS dessous). Alors oui, un certain nombre de fonctionnalités ont été perdues au passage (notamment au niveau des fonctionnalités entreprises et l'absence de compatibilité des applis), mais :
- Le système est devenu "moderne" techniquement et a su attirer les développeurs : 100 000 applications sur le store aujourd'hui, là où la tentative de market sur feu Windows Mobile 6.5, simple évolution qui allait plutôt dans ton sens, a fait un gros bide.
- MS a pu faire table rase de la vieille interface et proposer quelque chose de nouveau, adapté au tactile, et différent d'iOS ou Android : les parts de marché sont encore faibles (3%) mais sur une pente ascendante, contrairement à Windows Mobile qui était en chute libre.
- MS a les moyens de ses ambitions : ce n'est pas un logiciel libre et ils ont les moyens de mettre en oeuvre les outils de Q/A pour limiter les régressions/bugs.
Il faut parfois savoir repartir de 0, faire table rase du passé et arrêter de traîner des boulets. Alors oui, à court-terme ca engendre à coup sûr des régressions, des mécontents, etc. Mais le choix de repartir sur des bases saines est généralement une vision sur le long terme qui peut s'avérer à au premier abord dangereux, mais peut être indispensable à la survie/succès demain.
Un autre contre-exemple vient de chez toi (Mozilla) : Firefox sur mobile a récupéré dans un premier temps les bases techniques de l'UI traditionnelle à base de XUL : au résultat un bousin non performant pas adapté aux contraintes mobiles. Tu crois qu'ils s'en seraient sorti mieux en faisant évoluer l'UI XUL ou est-ce qu'ils n'ont pas bien fait de repartir sur du code plus adapté au contexte ?
Bref, je trouve ta vision très court-termiste : il faut parfois prendre le risque d'être ambitieux et d'avoir une vision sur le long terme. Note le "parfois" : je ne prétends pas qu'il faille systématiquement tout remettre en cause systématiquement, ca dépend du contexte.
[^] # Re: Nokia et Maemo/Meego est aussi un bon exemple
Posté par antistress (site web personnel) . Évalué à 2.
Pour approfondir sur ce sujet précis, on lira avec profit (et beaucoup de temps devant soi) :
# Théorie bancale
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 10.
Pour prendre un autre exemple du monde réel, dans mon précédent taf, que je ne nommerais pas mais qui commence par sky et se termine par blog, on est repartis de zéro, on a réécrit l'intégralité du code vieillissant (php2/3) pour une nouvelle base objet (php 5), tout en changeant complètement d'architecture (passage de génération statique, oui tous les blogs étaient re-générés intégralement un à un en statique à chaque modification par une queue, donc quand on arrive à XX millions de blogs et XXX millions/milliards de posts/commentaires par jour, ça devient vite long, à une structure dynamique basée sur memcached/mysql/sharedance/fluxy/des raclettes qui sentent bon dans tout l'openspace/etc.). Et bien non seulement ça a bien marché mais en plus ça n'a pas tué le projet ni la boîte.
Ce n'est pas le seul exemple que j'ai vécu comme réécriture qui s'est bien passée.
Le problème de la réécriture à mon avis c'est qu'on veut trop en faire en même temps. Ré-écrire du code vieux/sale/moche/ARG oui, mais si on veux en même temps revoir complètement le design, les fonctionnalités, etc. il est fort probable qu'on ne verra jamais le bout du tunnel, ou que le développement sera anormalement long et difficile. Pour la simple et bonne raison que la partie chiante (ré-écrire du code qui marche) est cumulée avec la partie intéressante (créer de nouvelles choses), donc les dévs vont se lasser si ça dure trop longtemps, car enfermés dans un boulot peu créatif, et le boulot créatif n'aura pas de public avant des mois/années, plutôt déprimant. Il faut donc simplement séparer la partie chiante et la partie sympa. D'abord ré-écrire pour obtenir la même chose mais avec du nouveau code tout beau. Et ensuite commencer à écrire de nouvelles fonctionnalités, refaire le design de zéro, etc. Ça sera beaucoup plus encourageant et permet aussi de placer des objectifs plus petits et plus rapprochés dans le temps.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Théorie bancale
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
autre exemple, DLFP en RoR ça n'a pas trop mal marché on dirait :)
(cela dit, je comprend tout à fait que dans beaucoup de cas ça puisse être vécu comme une forme de maladie… quand je vois les projets meego/tizen/truc qu'on ne voit jamais en fait, je me dit que ces projets ont un drôle de métabolisme)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Théorie bancale
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Et pour continuer sur DLFP : effectivement, à part le style, tout le fonctionnement a été repris tel quel. Une partie des changements conceptuels avait été faite avant (la disparition de la seconde page de journaux et dépêches par exemple), une partie de nouveaux concepts (wiki) a été développée pour la nouvelle version, l'essentiel de la nouvelle version n'a été qu'une réécriture… les autres changements viennent après cette réécriture. Donc DLFP est un bon exemple, et on n'a pas à taire son nom ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Théorie bancale
Posté par ckyl . Évalué à 4.
Oui enfin DLFP c'est simple et petit à réécrire. Ca fait pas grand chose, c'est assez bien défini, et dans tout les cas il y a très peu de fonctionnalités exposées aux utilisateurs. Encore une fois ce n'est pas un jugement de valeur, c'est juste typiquement le type de projet qui se réécrit "facilement".
En dehors de la majorité des projets libres qui ont le temps de se pignoler (par ce que c'est plus rigolo de réécrire en se disant que ca ira mieux) et où la base de code est suffisamment petite, simple et peu mature pour que ca ait un vrai impact (le libre compte plus de libs/utilitaires que de "vraies" applis); le vrai risque de la réécriture c'est que généralement quand on en arrive là c'est que la navire prenait déjà l'eau depuis un bon moment, et que les problèmes sont souvent profond et ne vont pas disparaître par magie avec une implem V2. C'est effectivement plus simple au début, puis quand on doit supporter absolument toute la compat avec l'ancien code, arriver au même niveau de features et de stabilisation on retombe rapidement sur le même bordel, le tout avec des régressions pour les clients pendant des mois/années. Avant de décider de réécrire, il faut souvent faire des choix drastiques concernant le produit. Si on est arrivé à absolument avoir besoin d'une V2 c'est aussi souvent que ces choix n'ont jamais été fait avant et qu'ils vont être très très douloureux tant pour les devs que les utilisateurs.
Si c'est juste changer l'archi / l'implem d'un ou quelques modules où l'on identifie très bien les problèmes, c'est pas une réécriture et ca devrait déjà être fait depuis longtemps.
[^] # Re: Théorie bancale
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
Pour se débarrasser de templeet, la réécriture était obligatoire.
[^] # Re: Théorie bancale
Posté par fleny68 . Évalué à 1.
Ce n'est même pas la première réécriture: Da comme Dacode Linux French Page.
# KDE4
Posté par Guillaume Denry (site web personnel) . Évalué à 5. Dernière modification le 13 août 2012 à 00:45.
Il me semble que l'exemple de KDE4 est particulier, car ils ont voulu profiter du saut drastique de Qt3 vers Qt4 (API remise à plat) et pour offrir une expérience homogène sur tout leur parc applicatif, il aurait été difficile de traîner des morceaux de Qt3 conjointement à des morceaux de Qt4. Mais bon pourquoi pas.
[^] # Re: KDE4
Posté par Benoit Jacob (site web personnel) . Évalué à 6.
Où l'on voit les effets secondaires indésirables de surévaluer l'importance du bête toolkit au point d'en faire le facteur principal qui va déterminer quand lancer une nouvelle version majeure. Cf mon autre commentaire ci-dessous.
[^] # Re: KDE4
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
Le truc, c'est que Qt n'est pas forcément l'exemple parfait du "bête" toolkit car il fait un peu à boire et à manger. Lorsqu'on utilise à fond son API, on est un peu pied et poing lié à son devenir.
Et comme c'est un framework de qualité, on a tendance à l'utiliser à fond.
# Effet de bord des accents ?
Posté par Zylabon . Évalué à 1.
Bonjour,
le texte accentué est bien plus facile à lire (merci beaucoup). Cependant, je me dois de remarquer qu'il semblerait qu'il y ait eu un effet de bord sur l’apostrophe. ´ ça n'en est pas une (U+180E, l'apostrophe c'est ' U+0027 ).
(Il manque aussi les espaces devant les signes doubles)
Please do not feed the trolls
[^] # Re: Effet de bord des accents ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
En effet, pour faire des apostrophes j´ai fait touche apostrophe + touche apostrophe, mais il semble que j'aurais dû faire touche apostrophe + barre d'espace.
[^] # Re: Effet de bord des accents ?
Posté par Redskull . Évalué à 4.
Non, l’apostrophe c’est ’ (U+2019).
[^] # Re: Effet de bord des accents ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Et tac ! Remonte ton slibard, Lothar !
[^] # Re: Effet de bord des accents ?
Posté par Almacha (site web personnel) . Évalué à 1.
La présence des accents permet d'éviter un troll occupant les 3/4 des commentaires de l'article précédent . C'est marrant d'ailleurs de voir que bien que le contenu de l'article ait été de nature à susciter les trolls, c'est la forme qui a constitué le plus gros troll.
# Motif
Posté par Maclag . Évalué à 10.
Avec un raisonnement pareil, on serait encore tous sous Motif.
Ben oui: faut pas réécrire, à la limite faut attendre qu'un truc nouveau débarque, et qu'il sera plus mieux que ton truc réécrit.
C'est sûr?
Alors je propose autre chose:
Au lieu d'utiliser le nom KDE4.0, vous auriez dû écrire YetAnotherDesktopEnvironment (YADE) 0.6. Là on aurait eu du code tout neuf et propre alors que réécrire, c'est mal!
Na pas réinventer la roue, ça ne veut pas dire rester scotché éternellement sur la même base de code. D'ailleurs, suivant la même logique, il faut de suite arrêter Wayland (pourquoi faire, on a XFree86, non? cessons un peu de réinventer la roue!).
Pourtant, parfois, il faut se rendre à l'évidence: avec les améliorations incessantes du logiciel, l'évolution des besoins, la multiplication de fonctionnalités, des priorités sur les performances de certains éléments et pas d'autre, la base de code au jour J n'est plus adaptée. Alors soit on s'obstine à continuer un château de carte de plus en plus bancal, soit on accepte de repartir d'une base saine au prix d'une réécriture majeure.
Est-ce que KDE3.x avait la moindre chance de devenir en terme d'expérience utilisateur ce qu'est KDE4.x aujourd'hui? Est-ce qu'on aurait pu faire un équivalent à Plasma Active?
Il faut savoir faire des sacrifices parfois!
[^] # Re: Motif
Posté par Benoit Jacob (site web personnel) . Évalué à 10. Dernière modification le 13 août 2012 à 07:12.
Il y a quelques années j'étais convaincu de l'importance d'avoir un bon toolkit. D'où mon intérêt pour Qt et KDE. Plus maintenant.
Un toolkit, en fait c'est juste quelque chose qui doit faire tourner une boucle d'événements et afficher de bêtes boutons. Ça n'est pas très intéressant et ça ne mérite pas qu'on se tape le cul par terre comme une libellule au printemps.
Qt s'est embarqué dans une bien plus vaste entreprise, celle d'offrir un cadre de développement d'applications C++ complet, remplaçant bien des composants allant de la bibliothèque standard (QVector, QList) à la gestion de bases de données SQL (QtSQL) en passant par la créations de contextes OpenGL (QtOpenGL) mais je ne suis absolument pas convaincu que cette intégration extrême de tous les besoins d'une application dans un projet unique soit bénéfique aux applications, surtout que j'ai découvert à Mozilla que les applications vraiment avancées auront toujours besoin de plus de contrôle manuel que ce qu'une panoplie à la Qt peut offrir.
Quant à Plasma Active: ce projet a-t-il vraiment des exemples de matériels à succès démontrant son utilité? Désolé, je suis devenu un peu cynique. C'est peut-être aussi l'expérience de travailler sur des plateformes mobiles, mais toujours est-il que je ne pense pas que l'on puisse offrir une bonne expérience mobile en restant au haut niveau auquel travaille Qt. Offrir une bonne expérience mobile, ca nécessite toutes sortes de hacks de bas niveau pour tirer le meilleur parti de ces matériels très limités (un peu comme de programmer un Amstrad CPC dans les années 80), et ces hacks sont hors de portée d'un projet comme KDE qui a pour credo qu'on peut se reposer aveuglément sur Qt, ou même de Qt qui a pour credo qu'on peut se reposer aveuglément sur l'OS sous-jacent. Tant que le mobile restera la jungle que c'est aujourd'hui, il n'y aura pas de place pour ces tentatives se reposant naïvement sur la qualité et la bonne performance des couches sous-jacentes.
[^] # Re: Motif
Posté par _PhiX_ . Évalué à -10.
Je suis assez d'accord si j'en juge par mon expérience d'utilisateur standard. Plasma n'a rien apporté de fondamental à mon bureau KDE, qui reste toujours défini par des icônes de fichiers et d'applications posées sur un fond d'écran, avec une barre principale disposée en bas contenant un menu principal, une barre des tâches, des lanceurs d'applications, une horloge, etc. rien que de très classique. Je n'ai besoin d'aucun plasmoïde supplémentaire.
[^] # Re: Motif
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Qt n'étant qu'une lib, il n'est pas interdit d'aller plus bas niveau soi-même quand le besoin s'en fait sentir. A une époque, lorsque Qt n'offrait pas la gestion des trayicons, on "hackait" soi-même pour offrir cette fonctionnalité uniquement sur les plateformes qui le supportaient.
[^] # Re: Motif
Posté par Misc (site web personnel) . Évalué à 6.
En gros, comme le code ne convient pas, il faut le réécrire ? So ironic.
[^] # Re: Motif
Posté par zebra3 . Évalué à 3.
Il faut tout de même se poser l'autre question : cette expérience utilisateur est-elle nécessaire ?
Apparemment, on se la pose pour GNOME Shell mais pas pour Plasma Active :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# pas convaincu
Posté par Guillaume Knispel . Évalué à 5.
Tout dépend des cas et surtout de l'architecture.
Il est des correction de bugs qui ne sont rien d'autre qu'un sparadra sur une structure branlante (pas forcement pour les cas que tu cites; ceux la j'en sais rien je les connais pas assez). Dans ce cas les garder parce que "au mon dieu si on recommence il n'y aura pas les corrections de tous ces bugs" relève au mieux du culte du cargo pour Spolsky (qui ne demande pas ça), au pire de la folie douce.
[^] # Re: pas convaincu
Posté par reno . Évalué à 1.
Ce qui est rigolo c'est que le sujet initial de l'article Firefox a toujours une architecture pourrie rapport à Chrome car ils n'ont pas le support d'un processus par site web et qu'ils ont renoncé à travailler sur le sujet car ça ferait trop de changements..
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 9.
Ce qui est rigolo c'est de penser que "ne pas avoir un processus par site web" == "avoir une architecture pourrie". Tout ce qui n'est pas Hurd a donc une architecture pourrie ?
T'es tu demandé si séparer en processus n'avait pas des inconvénients ? Comme une consommation mémoire plus élevée, une moins grande souplesse dans l'écriture des addons, plus d'optimisations/codes en fonction de l'OS, etc.
Avoir une tâche dans un processus, c'est surement une bonne chose, mais malheureusement, tout le monde ne tourne pas sous HURD, ça nécessite d'avoir une bonne gestion des processus dessous si on veut pas avoir à hacker pour avoir des perfs potables, ça nécessite un IPC portable performant, ça demande plus de code, pour un simple gain de sécurité.
Parce que le seul gain qu'apporte le multi-processus, c'est de la sécurité, de part la séparation des espaces d’adressage. Croire que c'est la raison des performances de chrome est assez naïf, et croire que c'est la seule manière d'avoir un navigateur performant l'est encore plus. Certes, le gain de sécurité n'est pas minime, mais si tu utilises ton navigateur et ton OS avec prudence, c'est loin d'être "une architecture pourrie".
[^] # Re: pas convaincu
Posté par TImaniac (site web personnel) . Évalué à -1.
Ce qui est rigolo, c'est qu'en l'occurence Chrome est plus sécurisé mais aussi plus performant. Bref, en fait on cherche encore l'inconvénient, sachant que la plupart des concurrents ont adopté cette technique là où Firefox recule l'étape pour franchir le pas.
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 9.
Chrome est plus performant, chrome a plusieurs processus. Ça ne signifie en aucun cas que l'un implique l'autre.
[^] # Re: pas convaincu
Posté par zebra3 . Évalué à 1.
Ça ne veut pas dire non plus qu'ils ne soient pas liés.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pas convaincu
Posté par TImaniac (site web personnel) . Évalué à 3.
J'ai pas dit qu'il y avait une implication, au contraire : il est possible d'avoir du multi-process et de bonnes performances. On cherche encore les vrais inconvénients pour l'utilisateur final.
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 2.
J'ai quand même l'impression que les utilisateurs finals ont l'impression que les développeurs n'existent pas.
[^] # Re: pas convaincu
Posté par Marotte ⛧ . Évalué à 3.
Le saviez-tu ? Tu es plus écrivain, qu'économiste ou linguiste :)
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 5.
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.
[^] # Re: pas convaincu
Posté par TImaniac (site web personnel) . Évalué à 2.
Qu'insinues-tu ?
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 1.
Que, tout compte fait, dans le développement d'un logiciel, les développeurs sont aussi important que les utilisateurs.
[^] # Re: pas convaincu
Posté par zebra3 . Évalué à 1.
Encore plus dans le libre, qui fonctionne à la méritocratie.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pas convaincu
Posté par TImaniac (site web personnel) . Évalué à 2.
Et ? Quel est le rapport avec mon propos ?
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 1.
Que ce n'est pas parce qu'il n'y a pas d'inconvénient majeur pour l'utilisateur final qu'il n'y en a pas pour le développeur, et quand l'inconvénient pour le développeur est trop grand, c'est une bonne raison pour ne pas le faire.
[^] # Re: pas convaincu
Posté par TImaniac (site web personnel) . Évalué à 4.
Je comprends la difficulté pour les développeurs : une remise en cause profonde de l'architecture de Firefox nécessite beaucoup de boulot et ils doivent fixer des priorités. Ils font donc le choix qu'ils veulent, mais qu'ils arrêtent de justifier que ce choix est pertinent vis-à-vis de la concurrence et de l'expérience utilisateur. Qu'ils admettent juste qu'ils n'en ont pas les moyens pour le moment.
[^] # Re: pas convaincu
Posté par zebra3 . Évalué à 6.
Oui :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: pas convaincu
Posté par reno . Évalué à 3.
J'y ai réfléchi effectivement.
C'est a peu près le seul réel inconvénient, mais note que Chrome te permet aussi de tout mettre dans le même processus, donc quand tu as une mémoire très restreinte, tu peux le configurer de la sorte: pouvoir avoir un processus par site web, n'implique pas forcément d'utiliser un processus par site web..
Et il y a beaucoup de machines avec beaucoup de RAM ou utiliser un peu plus de mémoire n'est pas un gros problème.
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é.
Chrome ET Firefox sucks tout les deux car ils n'ont pas ces 2 niveaux.
Oui euh Chrome est plus performant que Firefox donc visiblement ils ont réussi a surmonter l'obstacle.
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 3.
C'est marrant, ça me fait beaucoup penser à firefox.
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.
[^] # Re: pas convaincu
Posté par reno . Évalué à 4.
Tu te trompes, pour moi les 2 intérêts principaux sont: 1) la sécurité ET 2) la réactivité.
(1) est aussi important que (2).
La séparation en processus n'est pas la recette ultime de la performance mais au moins ça nettoie simplement les ressources quand on ferme un onglet: ça n'est plus un problème avec FF mais ça l'a été pendant très longtemps.
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 3.
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.
[^] # Re: pas convaincu
Posté par Guillaume Knispel . Évalué à 2.
Sous réserve des détails d'implé (et évidemment d'un scheduler correct), c'est pas totalement idiot de penser que la réactivité pourrait avoir un rapport avec le multi-process…
[^] # Re: pas convaincu
Posté par reno . Évalué à 2.
Une autre remarque: Hurd est un noyau, pour les noyau la vitesses des IPCs est extrêmement importante, les noyaux monolithiques ont donc un avantage important.
Dans un navigateur web, la situation est totalement différente..
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 2. Dernière modification le 13 août 2012 à 13:49.
Non. Hurd est un OS, pas un noyau, enfin, pas entièrement un OS, mais beaucoup plus qu'un noyau.
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.
[^] # Re: pas convaincu
Posté par reno . Évalué à 2.
Alors les multiple sens de The Hurd, je te les laissent.
N'importe quoi, je faisais remarque que dans un OS, les processus communiquent souvent entre eux par contre dans un navigateur web, les sites web ne communiquent pas entre eux (enfin rarement), ça n'est pas très compliqué de voire la différence non?
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 1.
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 ?
[^] # Re: pas convaincu
Posté par reno . Évalué à 2.
1) Les être humains sont lents par rapport à des processus.
2) Chrome me parait bien plus réactif que Firefox donc le multi-processus n’empêche donc pas de faire un browser réactif..
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 2.
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.
[^] # Re: pas convaincu
Posté par yellowiscool . Évalué à 2.
Un effet collatéral de cette séparation en multi-processus, c'est qu'il suffit de fermer des onglets pour récupérer toute leur mémoire.
Il serait certainement possible d'avoir un comportement similaire avec un bon garbage collector, mais ce n'est pas le cas avec Firefox actuellement.
Envoyé depuis mon lapin.
[^] # Re: pas convaincu
Posté par Enjolras . Évalué à 2.
En fait si. Mais ça dépend de quelle mémoire tu parle. Si c'est de la mémoire résidente ou de la mémoire allouée. Si tu parles de la mémoire résidente, ce n'est en effet pas encore totalement le cas, même si Firefox s'en est bien rapproché ces derniers temps. Mais le moving GC en développement devrait permettre de s'en rapprocher très prés. L'avantage, c'est que c'est vrai même quand tu fermes pas l'ongle mais qu'une patie de la mémoire n'est plus utilisée.
Pour plus de précisions, tu peux lire mon journal.
[^] # Re: pas convaincu
Posté par Guillaume Knispel . Évalué à 2.
C'est beau de réécrire un OS dans un navigateur. Une idée me vient, on pourrait aussi remplacer Javascript par du Lisp ?
# Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 1. Dernière modification le 13 août 2012 à 09:21.
Je rebondis sur l’exemple de GNOME. Les utilisateurs râleurs voient souvent ça uniquement de leur point de vue, mais techniquement, gnome 3 est une bonne chose.
Je pense qu'il était nécessaire de se débarrasser du gnome-panel vieillissant, avec des technos aussi moches que bonobo, ou de l'architecture GTK 2, peut souple, et pas vraiment adaptée aux nouvelles problématiques de portabilité. GTK3 introduit par exemple un moteur de thème standard basé sur CSS, et la notion de backend de dessin GDK.
En outre, gnome 3 n'est pas vraiment une réécriture de zéro, c'est la réécriture de l'interface basée sur des mises à jours majeures de la plateforme. On peut pas dire que GTK ai été complètement réécrit, ni la glib, ni beaucoup de libs, ni même les applications comme nautilus, epiphany, evolution, etc etc. Mutter non plus n'est pas vraiment une réécriture de metacity mais une modification en profondeur pour plus de modularité et l'intégration du composite. Le reste s'apparente plus à une écriture qu'une ré-écriture et touche beaucoup plus à l'UI qu'a la base de code de gnome. Après, il y a eu aussi des ré-écritures inutiles comme gnome-disks, mais c'est récent et assez marginal.
Mais, tout ça pour conclure que la ré-écriture de zéro n'est pas mauvaise en soi. Il ne faut pas avoir peur de s'y lancer, mais il ne faut pas s'y lancer non à plus bras ouverts. Je pense qu'il ne faut pas avoir peur de ré-écrire une architecture peu adaptée, mais il faut toujours tenter de récupérer le maximum de code existant, même si on repart de zéro sur l'architecture.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 6.
Quelle réaction puérile !
C'est sûr, il vaut mieux garder la syntaxe hackée et beaucoup plus faible, comme avec GTK2 qu'utiliser un format standard utilisé largement, maitrisé par beaucoup de monde, et qui a fait c'est preuve !
CSS est un format déclaratif permettant de décrire le style d'objets définis sémantiquement par un langage structuré. Le layout d'un toolkit s'y apparente grandement, avec ses frames et ses widgets. Le CSS joue exactement le rôle qu'on lui demande, permettant d'attacher et d'hériter des propriétés de style à des balises.
D'ailleurs, la relation est tellement proche que Mozilla se sert de HTML/CSS pour écrire un toolkit.
A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 1.
Et les performances ? C'est aussi lent qu'un navigateur ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 3.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 1.
C'est extrêmement gonflé de parler d'interpréter du CSS comme une "petite inefficacité", surtout pour un toolkit généraliste qui sera utilisé par plusieurs applications. Si c'est votre trip d'empêcher les gens de lancer trois programmes s'ils n'ont pas une machine dernier-cri, c'est pas le cas de tout le monde. Il y en a qui aimeraient juste pouvoir bosser.
Même LaTeX est plus rapide, en plus d'être plus puissant. Pourquoi ne pas l'utiliser ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Misc (site web personnel) . Évalué à 2.
Je ne crois pas que latex soit spécificé autrement que via son propre code source, ce qui n'en fait pas un candidat idéal. Sans compter que latex est rapide car il est assez long à compiler. Et l'état des piles latex actuels ( genre texlive ) est loin d'être idéal ( genre 600 Mo de paquets, un foutoir de license, une explosion de paquets )
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 3.
Sans compter que quand ma présentation beamer de 40 slides prend 12s à compiler, je ne trouve pas que ça soit rapide.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 4.
J'attends un benchmark qui montre que GTK3 est plus lent à rendre un thème que GTK2. Si la différence est supérieure à 10%, alors, on pourra considérer que peut être CSS est un mauvais choix.
Mais avant d'en arriver à dire que CSS est un mauvais choix, on peut aussi essayer d'optimiser quand le problème se présente. Les performances ne doivent pas guider les choix techniques a priori. C'est ce qu'on appelle le kikoo-driven developpment.
Tant qu'il n'est pas prouvé qu'une solution technique efficace et adaptée a un impact assez important sur les performances pour gêner le logiciel dans sa fonctionnalité, ni que le problème de performance vient de la solution technique en soi et non d'un mauvais usage de celle ci, il est parfaitement idiot de se contraindre à ne pas utiliser cette technologie.
La performance en soi est inutile. Parfois, il vaut mieux privilégier la simplicité technique et la lisibilité du code tant que la fonctionnalité et l'expérience utilisateur n'est pas impactée.
Ce que tu proposes, c'est de l'optimisation a priori, et à mes yeux, c'est la plus grave anti-pattern en développement logiciel.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 5.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 2.
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 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 2.
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 ?
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 ?
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Guillaume Knispel . Évalué à 5.
Bien souvent pousser une idée à l’extrême est tout aussi ridicule que son extrème inverse. Se ficher royalement des performances pour un desktop (au sens logiciel, pas au sens installation et type d’équipement) est une position qui n'est guère tenable très longtemps.
Ceci étant dit je ne suis pas convaincu qu'il soit impossible de faire du CSS très performant pour une UI locale. Reste à savoir si c'est (ou ça sera) fait.
WTF???
Sur le coup tout le monde s'en fiche, effectivement. Après on en reparlera quand ta batterie sera vi
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 2.
Désolé, mais ce point là à été atteint depuis bien longtemps avec les navigateurs modernes. Ils en sont à se battre avec de l'accélération matérielle, des compilateurs JIT et du parallélisme, 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).
Tu devrai leur dire d'arrêter leur "kikoo-driven developpment" et de se concentrer sur la simplicité technique et la lisibilité du code.
C'est avec ce genre de raisonnement qu'on se demande à quoi ça sert de faire un OS multitâche si les applications sont tellement lourdes qu'on ne peut pas en faire tourner deux en même temps.
Et sinon, parler de "simplicité technique et de lisibilité du code" avec CSS, comment dire …
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 5. Dernière modification le 13 août 2012 à 11:50.
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à.
je ne comprends pas vraiment ta phrase.
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
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à -2.
s/avoir/à voir/
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 3.
Simple: une application Web est aussi lente qu'une application GTK2 sur une machine vielle de 8 ans.
Sur la lisibilité du code :
- L'ordre des déclarations est important et peu introduire des bugs silencieux. Impossible de réorganiser du code ou de splitter ça dans plusieurs fichiers sans risquer d'introduire des bugs silencieux. C'est comme si on virait les déclaration en C et qu'on définissait toutes les fonctions avant de pouvoir les utiliser: c'est juste complètement hideux.
- L'absence totale de sémantique, et le fait que tout code avancé soit un amas de bidouilles: pour aligner des blocs horizontalement, utilisez float:left. Hein ?
Sur la simplicité technique, il n'y a même pas de commentaire à faire, il suffit de regarder les tests ACID 1 et 2 et de te demander combien de temps il te faudrai pour faire une implém qui respecte la norme.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 6.
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 0.
CSS va imposer de supporter des fonctionnalités comme des dégradés orientés et tout un framework d'animation ainsi que bien d'autres fonctionnalités plus ou moins utiles pour mettre en forme une interface.
En anglais, on appelle ça du bloat.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 3.
Personne n'a dit qu'il fallait implémenter tout le standard CSS de A-Z. Ton argument est invalide.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à -3.
Attend, tu est en train de dire que tu va réimplémenter l'interprétation de CSS ?!?
Tu trouve pas qu'il y a suffisamment d'interpréteur de layout CSS ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 2.
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 2.
Tout ça n'est certainement rien à coté du code général des impôts ou de tout ses équivalents européens. Et surtout, tes normes sont prévues pour des ordinateurs, alors que le code général des impôts est prévu pour des humains.
C'est pareil pour CSS: c'est prévu pour être utilisé sur le web par des implémentations indépendantes interchangeables avec une contrainte de compatibilité ascendante et descendante (il faut ignorer les attributs que l'on ne connaît pas) et qui doit avant tout être une fonctionnalité optionnelle. C'est un peu se flageller que de s'imposer ces contraintes là pour décrire des interfaces.
Une interface avec un layout optionnel ça te fait peut-être triper, mais moi j'aimerai bosser.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Guillaume Knispel . Évalué à 2.
Effectivement le BIOS, les x86 et les PIC, se sont les toutes dernières tendances à la mode. Ça et les AS400.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par kursus_hc . Évalué à 4.
Ca fait un moment que tu peux utiliser inline-block en fait !
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 1.
Ce n'est pas toujours possible, et ça n'a pas plus de sens que "float:left", pour une interface graphique.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par kursus_hc . Évalué à 2.
C'est-à-dire ?
C'est-à-dire ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Misc (site web personnel) . Évalué à 7.
J'aurais tendance à dire "non", c'est pas plus long que l'ancien format de theme, car je vois pas ce qui dans css serait plus lent en soit que le bon vieux .gtkrc. Dans un cas, tu dit "tel widget est de tel couleur", dans l'autre, aussi.
J'ajouterais que ce qui rends les choses longues sur un navigateur, c'est que tu as des tas de widgets, que tu as sans arrêt des nouveaux trucs à afficher ( à chaque page web ), et une css différente à chaque fois. Donc tu payes le prix de l'application du css à chaque page.
Mais oui, c'est sans doute plus long que de harcoder le style dans chaque widget, parce qu'il y a 2 passes. Mais dans ce cas, il faut comparer l'usage de css à rien, pas à .gtkrc. Et dans ce cas, ta demande deviens plus d'utiliser dwm qu'autre chose ( dwm, pour ceux qui ne connaissent pas, se configure uniquement en changeant son code source ).
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à -1.
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par zebra3 . Évalué à 1.
s/qu'un navigateur/que Firefox/
Non parce que Chrome et tout ce qui utilise Webkit est rapide.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Batchyx . Évalué à 2.
J'avais essayé uzbl/surf/l'exemple pywebkit et ça swappait aussi mal que Firefox.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . Évalué à 10.
A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
Dans l'ordre :
a) C'est pas fait pour ça - Il existe certes des bibliothèques (le plus souvent en javascript) qui permettent de transformer certains éléments CSS en widgets, mais le CSS est un descripteur de style, c'est à dire qu'il sert à normaliser la mise en forme du contenu. S'en servir pour du contenant ne fait pas sens. Cela fait d'autant moins sens que GTK3 possède déjà un moteur de style qui lui est propre - et qu'une partie du fonctionnement interne est inaccessible depuis les CSS, le role de CSS dans le cadre du thème est donc batard :
- Il peut influencer le contenu (via margin , padding, font etc.) mais pas complètement le mettre en forme
- Il peut faire le thème mais pas complètement (il n'y a pas de "retour" en CSS - il faudra donc de toute façon écrire de la logique hors CSS pour le comportement avancé des widgets)
- Il rend le test des applications très complexe : comme les CSS GTK3 ne gèrent pas (encore ? apparament ca ne sera pas fait) l'ajustement automatique de la taille, un élément rendu trop grand par une CSS innapropriée sera tronqué. Comme il est décommandé de créer son propre moteur de theme, on arrive à des situations ou la barre de menu peut avoir été décalé sur le coté alors que vos widgets dans cette barre sont en long. Au final soit on force un thème complet ou presque dans l'appli (mais alors les préférences utilisateurs sont détruites) soit on prévoit 12 gazillons de possibilités (barre verticale à droite dans un système d'écriture droite à gauche), le tout avec le moteur standard, avec unico et avec adwaita pour faire bonne mesure.
b) C'est pas moi qui choisi les classes
La force de CSS est que l'on peut décrire une foultitude de classe de façon à faire passer des sélecteurs pour les modifier ou les manipuler si besoin est. Sauf que là les classes sont pour la plupart prédéfinie, et c'est préférable vu que l'on altère plus le contenant que le contenu. Mais du coup on arrive au point ou l'on est coincé dans sa capacité à choisir ou à disposer des classes. le résultat est que l'on se retrouve à créer des sélecteurs en pagaille sur des propriétés.
Vous voulez une image spéciale quand on est grisé une radio box dans un menu d'une fenêtre ? rien de plus simple il suffit de créer le sélecteur
.frame.menu.menuitem.radio:active:insensitive (pour la version cochée)
.frame.menu.menuitem.radio:insensitive (pour la version décochée)
.frame.menu.menuitem.radio:inconsistent:insensitive (pour la version qu'on sait pas encore si elle est cochée ou pas)
Faire un thème pour le moindre widget prend trois pages de déclaration, la seule solution pour ne pas avoir des sélecteurs à rallonge c'est de passer par le nom du widget créé. Par exemple faire une cascade sur NautilusWindow - ah oui mais dans ce cas là on perd l'avantage majeur du CSS : séparation de la logique et du rendu. Pas grave, les thèmes officiels Gnome ne passent quasiment que par des sélecteurs par nom du widget.
c) Il est ou mon DOM ?
Pour pouvoir utiliser les CSS correctement, voire intelligemment il faut connaitre au moins vaguement le DOM, c'est à dire savoir à quel niveau se trouve tel ou tel élément. Dans GTK3 non seulement je ne comprend pas le DOM, mais en plus je ne sais même pas ou se trouve le mien. C'est peut être moi qui suis mal comprenant mais…
J'écris une appli, je fais son css pour elle, j'importe les css GTK3 de base et je tente de respecter le au maximum les préférences utilisateur. Bon à un moment j'ai besoin de permettre à l'utilisateur de naviguer dans les fichiers locaux - pas de soucis j'invoque un widget nautilus et AAAHHH… Mais qu'est-ce qui se passe. Qui est la fenêtre active ? Je suis dans un widget donc ça devrait toujours être moi, mais qu'est-ce qui se passe au niveau du thème ? gnome-application.css fait de l'override forcé du thème mais est-ce que mon widget est bien le fils de mon appli ? Est-ce que les composants de mon widgets sont tous les fils de leur père ? Et si je branche un clef usb après avoir appelé mon widget ?
Et une fenêtre non modale ? C'est une parente de ma fenêtre principale ? Elle hérite des thèmes ? De tous les thèmes ?
Le pire c'est qu'à chaque fois que vous commencer à connaitre (parce que comprendre c'est pas possible) il y a un bug report qui est traité et qui "corrige" un comportement absurde par un autre comportement non moins absurde dans la cascade des styles.
Et puis il y a le SVG. Qui apporte son lot d'élément DOM, mais pas tout à fait comme le DOM SVG html. On pourrait écrire des pages et des pages la dessus.
d) Le CSS change - et GTK3 ?
Déjà sur du pur HTML le W3C se fout sur la gueule en permanence pour savoir ce qui rentre dans CSS et ce qui ne rentre pas. En faisant le choix du CSS GTK3 va se retrouver à plus ou moins long terme à devoir choisir entre deux choses désagréables
1 - suivre le W3C quoi qu'il arrive même si les nouvelles CSS partent dans des directions qui n'apportent rien à un système de thème
2 - maintenir et faire évoluer une version des CSS qui ne sera pas supporté par le W3C.
Ca a déjà commencé. Bonne chance pour faire mumuse avec du z-index ou du float sous GTK3, la taille des éléments est définie en points sans unité précisée (encore que l'em semble être supporté pour les fontes dans les dernières versions - mais c'est pas documenté), et les sélecteurs par nom du widget c'est assez fort…
C'est donc un langage qui ressemble à du CSS, mais qui n'est pas (du tout) du CSS. Ni dans l'esprit (mélange fond forme, DOM tordu, sélection par attributs en pagaille) ni dans la lettre (manque pleins de choses puissantes, subtiles nuances sur les choses restantes).
Voilà…
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 0.
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.
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 ?
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
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. Si tu dois partir sur des suppositions et "Inch'allah !" pour faire ton CSS plutôt que de partir sur une source fiable, c'est pas terrible pour programmer.
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". Certes c'est bien, mais le développeur qui se repose sur GTK veut développer son logiciel, et c'est très désagréable de commencer à utiliser une façon de faire et de se dire « Mais, mais, pourquoi ils ont fait ça comme ça ? Mais c'est pourri ? WTF ??? Je me retrouve à coder mon interface graphique en C au moindre truc compliqué alors que j'aurais pu faire autrement et ne pas me casser le cul ? Génial, j'ai le choix entre continuer les hacks dégueulasses ou jeter aux orties des heures et des heures de … » ⁽*⁾
⁽*⁾ C'est un peu ce que je ressens avec QtCreator en ce moment, qui a la bonne idée de proposer absolument tout via le code C++ mais qui empêche de réaliser certaines choses via l'éditeur graphique d'interface dans QtCreator4 alors que dans QtCreator3 c'était possible. Les nazis de l'interface graphique sont partout…
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 1.
Ce n'est pas parce que le CSS es utilisé comme ça qu'il ne peut être utilisé que comme ça.
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . Évalué à 7.
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.
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. C'est pour celà qu'en CSS gnome on passe son temps à définir des dizaines de comportement CSS en fonction de tout une palanquée d'attributs.
Pour que les paradigmes se recoupent il faudrait que GTK3 fonctionne comme javascript, c'est à dire qu'il utilise les mêmes sélecteurs CSS que la mise en forme. (Et ca ne serait pas une bonne idée du tout.)
_Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. _
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 (ce qui est la solution retenue par toutes les applis GTK3 que j'ai pu croiser) ou prendre le risque que mon interface explose.
Pour bien faire il faudrait une fois de plus que le rendu CSS GTK3 soit fluide, et que l'on dispose d'un retour sur l'interface du même type que celui dont on dispose en javascript - et qui permette de récupérer, d'analyser et de modifier la mise en page à la volée. Gnome-shell permet (un peu) ce genre de choses, mais une appli standard ne dispose pas de framework standard pour effectuer ces opérations. On y va à coup d'introspection et on prie.
_ Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS, 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._
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.
Un exemple tout con : je veux faire un éditeur de texte dans lequel j'ai un arbre de navigation et une fenêtre de saisie d'un certain type pour les langages procéduraux et un autre arbre de navigation avec une autre fenêtre de saisie pour les langages fonctionnels. De plus je rajoute ou j'enlève des éléments à mon arbre en fonction du fait que le langae soit objet ou non. A cela j'ajoute une fenêtre de saisie en dessous pour l'accès console et une autre fenêtre en affichage seul pour la sortie de compilation/le debug.
Si je pouvais créer des classes ca prendrait 10 secondes à faire, mais comme je ne peux pas je suis OBLIGE de me trimballer des sélecteurs de 100 pieds de long pour distinguer entre mes différents éléments qui déscendent tous du même widget. Et si je veux créer une fenêtre en double pan pour les diffs et les merge ? Encore un selecteur. Et si je veux que l'utilisateur puisse détacher la fenêtre de debug pour la passer sur l'écran d'à coté ? Encore un autre sélecteur. Et dans chaque selecteur je refais TOUTE la CSS spécifique à l'élément. Donc le jour ou je veux changer le comportement de mon élément il faut que j'aille modifier mes CSS à 14 endroits différents. C'est EXACTEMENT ce que le CSS est supposé éviter.
_ Pourquoi veut tu un DOM ?_
Déjà parceque ca me permet de savoir quels éléments vont hériter de mes modifs CSS et quels sont ceux qui vont passer au travers. C'est fondamental quand on fait un thème ou une interface de savoir ce qui va être impacté. Je veux que mon boutton "fermer" soit en rouge violent sur la fenêtre qu'il ne faut surtout pas fermer a moins d'être sur à 100% de son coup, par contre je ne veux pas qu'il soit en rouge violent au niveau de la fenêtre d'aide qui peut elle être fermée quand on veut. Le DOM est ce qui me permet de savoir QUEL comportement je modifie quand je n'ai pas envie de les modifier tous.
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.
Je te rassure, GTK3 fourni tout un tas d'outils qui permettent de faire des modifications d'aspect en fonction du fonctionnel sans que ca n'impacte l'ensemble des widgets du même nom sur toute l'appli. Sinon ca ne servirait pas à grand chose. On ne peut juste pas accéder simplement a ces fonctions depuis les CSS parceque les deux méthodes d'accès (par classe spécifique utilisateur et par parcours de l'arbre DOM) ne sont pas implémentées correctement.
Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.
Assumé est un bien grand mot. Ils (les devs Gnome) disent qu'il ne faut pas créer de moteurs de thème, qu'il ne faut pas faire d'introspection pour des raisons de décorations, qu'il ne faut pas faire des sous groupements de widgets par fonction etc. Tu dois tout pouvoir faire avec du SVG et des CSS. Alors du coup tu essayes, tu y arrives pas et tu vas lire leur code poru savoir comment eux ils ont fait. Réponse : Ils ont créés des moteurs de thème custom dans lesquels il font des sous groupes de widgets, ils font de l'introspection à tire larigo, ils utilisent du png pour les images sans arrêt….
Sur Gnome-Shell ? On va carrément chercher un interpreteur ECMASCRIPT. Sur Nautilus ? On créé un widget custom par fonction et par sous fonction.
Si même eux n'arrivent pas à respecter leur truc sur des aspect fondamentaux du produit, je vois pas comment moi j'arriverai à faire quelque chose de propre.
En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais
Non je rale parceque je me prend tous les inconvennients d'un sucre syntaxique assez lourd (les objest CSS) sans aucun des avantages. Pas de réutilisabilité au sein de mon appli, pas de selecteur simple, pas de DOM donc pas d'éléments cibles facile à atteindre. A chaque instant ou j'utilise les CSS GTK3 j'ai l'impression qu'on m'a donné une perceuse pour planter des clous. C'est proche du besoin en effet, mais makgré tout complètement à coté de la plaque.
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é.
Alors déjà le tant que c'est documenté on y est pas encore.
Ensuite comme les CSS ne sont pas respectés par l'équipe Gnome elle-même on a des glitch dans tous les sens (variables en fonction du moteur de style utilisé) - donc même documenté il y aurait des chausse-trappes partout.
Et pour finir utiliser les CSS parceque "c'est trop cool, tout le monde connait, tout le monde sait s'en servir" avant de sortir une version limité autant au niveau des éléments, que des attributs et avec en prime un format différent pour les valeurs acceptable c'est idiot.
Sélectionner mes éléments avec des elem:active:insensitive:hoover:focus ca n'est intuitif pour aucun dev CSS. Ne pas pouvoir créer des classes et les réorganiser ca n'est intuitif pour aucun dev CSS.
Quitte à faire un autre langage, autant en faire vraiment un autre - là cet hybride est juste un piège qui va faire croire aux devs qu'ils peuvent rentrer dans le code directement (et qui va les accueillir avec un grand coup de batte de base-ball dans les gencives).
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 n'ai pas dit ça du tout. J'ai dit que GTK3 CSS ne permet pas de faire du GTK3. GTK3 et CSS sont sur deux paradigmes différents, ils ne peuvent totu simplement pas travailler ensemble de façon efficace pour faire du theming. Ca n'est juste pas possible. L'un des deux doit évoluer pour pouvoir dialoguer pleinement avec l'autre. Idéalement GTK3 devrait évoluer pour coller parfaitement au CSS du W3C (ou même à un sous ensemble de ces CSS) puisque c'est le but avoué de tout ce tintouin. Sauf que bien sur, à chaque fois qu'il y a un soucis c'est soit une verrue, soit une modif des specs CSS GTK3.
en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?
Ben je n'utilise plus correctement CSS en GTK3 (et je ne m'en porte que mieux), l'utilisateur devrait déjà être content de conserver sa déco de fenêtre intacte. Je fais mes déco dans des scope volatils au moment du refresh. Mes feuilles css redéfinissent à peut près tous les widgets demon appli (et elles sont elles mêmes écrasées par les css dynamiques des scope précédamment évoqué). Pour tous les trucs un peu complexe (genre un slider qui est légèrement plus gros ou plus rouge que les autres) je donne un grand de coup de hache dans le moteur de thème etc.
C'est moche hein ? Mais tu sais le pire ? Tout le monde fait comme moi, même au sein du projet Gnome.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 1.
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.
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.
C'est pas le contenu, c'est la forme du contenu.
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Albert_ . Évalué à 4. Dernière modification le 13 août 2012 à 16:36.
Il demande que la publicite corresponde au produit. Ce qui ne semble pas etre le cas.
D'apres ce qu'il dit (et que tu ne nies pas) les devs Gnome pronent un truc, l'utilisation de CSS, et font exactement l'inverse. Cela a de quoi etre "tres" legerement enervant.
En meme temps je vais avouer que je ne comprend pas pourquoi il veut absolument utiliser GTK3 alors que Qt4 est nettement plus simple a utiliser…
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . Évalué à 3. Dernière modification le 13 août 2012 à 16:44.
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.
Ok tu te sens d'écrire un truc du genre
Moi pas.
C'est pas le contenu, c'est la forme du contenu.
La forme du contenu, c'est le contenu. Sinon c'est de l'information brute. 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. Et comme le DOM est en vrac il n'y a pas possibilité de tracer la séparation. C'est comme si dans OpenOffice ton texte s'ouvrait différament en fonction de ton choix de thème. C'est idiot.
pourquoi CSS n'est il pas adapté
J'ai déjà répondu aussi. Un widget N'EST PAS un balisage. Je donne plus d'exemple pour que tu saisisses le problème, mais ca ne passe pas apparament.
CSS est un descripteur de mise en forme qui fonctionne par selection. Si on fait plus que de la mise en forme et/ou que l'on ne dispose pas de sélecteurs puissants (en l'occurence les deux dans GTK3) il faut autre chose. CSS n'est pas fait pour décrire l'ensemble de ce que peut être un widget. A partir de là il ne peut pas le sélectionner dans toutes les nuaunces et donc il ne peut pas le peindre correctement. Même en HTML c'est javascript qui s'occupe de ce boulot. Et c'est pas en rajoutant des sélecteurs attributs par paquets de 50 (elem:was_left_clicked_20_seconds_ago_but_lightly:was_originally_created_elsewhere_then_imported_here) qu'on va résoudre le problème. Bien au contraire.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Enjolras . Évalué à 1.
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.
Le principe des langages comme HTML ou xml c'est de stoquer du contenu structuré comme de l'information brute oui…
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.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . Évalué à 3.
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.
Et une balise c'est juste un espace vide et des indications.
La différence majeure entre une balise et un widget c'est que la balise est "idiote". Une balise image par exemple, si l'image cible n'existe pas - ben j'ai quand même un espace de 240px.400px qui est vide (et dans lequel le navigateur va déssiner uen croix rouge ou un fichier brisé pour me signifier qu'il n'a pas trouvé le contenu)
Une balise est par essence innerte. Si je remplace ma balise image par un champs texte ou par un objet video, la page s'affiche pareil.
Pire si j'agis en javascript pour modifier la cible de ma balise et la remplacer par une cible valide, ben l'image s'affiche.
Un widget c'est de la logique. Si je demande à ouvrir un widget nautilus vers un site FTP inexistant le widget ne sera pas créé. Ca me renverra un message d'erreur. Derrière je ne peux plus changer la cible de mon widget puisqu'il n'a jamais été créé.
Même chose pour certains widgets image. Pas de bras, pas de chocolat.
Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.
Dans le cadre de GTK3 si. On ne pourra jamais utiliser les CSS pour des fonctions de theming dans GTK3 sauf à modifier GTK3 en profondeur. Cette modification consisterait à couper chaque widget en deux : d'un coté la partie graphique/placeholder/rendu et de l'autre la logique. Mais ca revient à créer un autre toolkit complètement.
Dans le cadre d'un nouveau toolkit, la question de la pertinance se pose. Autant les CSS pour la mise en forme du contenu peuvent se justifer, autant pour le contenant ca peut devenir lourd très vite. Le point le plus important pour que les CSS tournent bien est de garder le coté inerte du balisage (pas de retour en CSS => pas de logique). Mais alors il faut cabler chaque bouton, chaque zone de saisie, chaque slider a la mano. En plus il faut aussi se palucher les flux trop gros pour tenir en mémoire d'un coup. Ca allourdi le code, mais c'est faisable (et même déjà fait - jquery-ui, mootools et YUI le prouve.)
_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 _
Il va avoir du mal à choisir les bonnes. A moins d'être très intelligent ET de lire mes pensées. Parceque pour deviner que je veux mettre les mêmes fontes dans le menu et dans les info-bulles mais pas dans les pop-up d'alerte il faut y aller.
Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris
Besoins compliqués ? L'exemple que j'ai donné c'est un éditeur de texte, du type de ceux qu'on demande d'écrire en deuxième année d'école d'info. Un éditeur de texte c'est quand même pas compliqué. Un navigateur web ou un logiciel de simulation 3D temps réel je dis pas, mais un éditeur de texte…
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Antoine . Évalué à 9.
Les gens en général ne râlent pas contre GNOME 3, mais uniquement contre GNOME Shell.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Jux (site web personnel) . Évalué à 9.
Et le mainteneur de Nautilus.
-> []
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Albert_ . Évalué à 6.
s/mainteneur/destructeur/
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par stopspam . Évalué à 2.
Et moi je râle parce que Gtk3 n'est toujours pas dispo sous windows (encore moins le binding python) !
J'ai encore tout un tas d'appli en pyGtk2 mais à un moment ou un autre ça ne tournera plus. J'ai regardé du côté de pySide mais plusieurs choses ne me plaisent pas.
Résultat : après avoir abandonné Gnome pour XFCE, je cherche un remplaçant à Gtk.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Des EFL pour Python peut-être ? J'ai vu que EFL était dispo pour Windows, j'ai pas creusé.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# TL;DR
Posté par Krunch (site web personnel) . Évalué à 5.
http://www.jwz.org/doc/cadt.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Au passage
Posté par Arathor . Évalué à 9.
Puisqu'on parle de Mozilla, de tout réécrire de zéro, des bugs qu'il serait plus facile de corriger sans tout réécrire…
Depuis au moins 10 ans, Mozilla/phoenix/firebird/firefox a un vieux bug chiant : quand on lance une deuxième fois Firefox alors qu'il tourne déjà, au lieu d'avoir une nouvelle fenêtre/onglet (comportement de tous les autres navigateurs), on a un message qui parle d'un processus déjà-ouvert-mais-qui-répond-pas. Très explicite pour l'utilisateur lambda, au passage. J'ai eu plusieurs fois la remarque de la part de mes parents.
Je pense même que ce bug était déjà là à l'époque de Netscape… Il y aurait du code datant de Netscape dans Firefox aujourd'hui ?
Vous en êtes où de la correction de ce truc ? Il faut attendre une réécriture de Firefox ? :D
[^] # Re: Au passage
Posté par ckyl . Évalué à -1.
Status: CLOSED
Reason: Could not reproduce
[^] # Re: Au passage
Posté par Anonyme . Évalué à 10.
Pourtant ce n'est pas difficile de le faire proc ce bug. Suffit de fermer Firefox, et de le relancer dans la foulée. En effet, Firefox fait sa tambouille lors de la fermeture et même si la fenêtre disparaît, son processus reste encore un moment actif, et tant que ce processus existe, on se tape le message. Et parfois ça peut être long avant qu'il ne se ferme, voire il arrive même qu'il se plante complètement (assez rare tout de même).
Et comme j'avais envie, je l'ai reproduit.
[^] # Re: Au passage
Posté par Kioob (site web personnel) . Évalué à 3.
D'ailleurs, même problème avec Thunderbird/Icedove en "pire" : le process peut rester actif pendant des heures après la fermeture. Pratique. Et pourtant cette cochonceté d'indexation globale est inactive.
alf.life
[^] # Re: Au passage
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 15 août 2012 à 17:41.
Et si on essaie de lire profile.ini alors que le système de fichier est plein, il y a de forte chance qu'il essaie de le réécrire… en échouant rendant un fichier vide.
ce commentaire est sous licence cc by 4 et précédentes
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.