Guillaume Denry a écrit 2954 commentaires

Sauf qu'en javascript, c'est "sans filet", il ne suffit pas soi-même de faire attention à la documentation du code pour savoir que tel champ est privé (Extjs fonctionne uniquement avec la documentation, les propriétés privées ne sont pas nommées différemment des propriétés publiques et la doc est un outil primordial pour ce genre de d'information), si tu modifies ou copies le code d'un collègue qui a utilisé un champ privé d'un objet, rien ne te l'indique sauf à aller regarder la doc systématiquement pour chaque variable….
Bref, il ne faut pas se le cacher, l'absence de portée est un gros point faible du langage et les artifices pour les simuler sont un pansement sur une jambe de bois.

Et comme je suis toujours à la recherche de nouvelles expériences, je me demande ce que je pourrai faire ma caméra et moi lorsque nous serons ensemble.

Te mettre la GoPro sur le front et aller demander à Richard Stallman de faire sa conférence en espagnol.

console devient quand même relativement courant voire standard, même dans les frameworks côté serveur, comme nodejs.

Tu as raison, ça a certainement été l'occasion pour les fondateurs de Gnome de faire leur propre jouet, mais après tout, n'est-ce pas justement ce qui fait la richesse du libre ?

Oui, je suis d'accord, mais je ne répondais pas vraiment à cela.

Héhé, moi aussi ça m'a fait tiquer cette petite attaque gratuite dans une dépêche dont le ton semblait jusque là plutôt neutre et factuel.

Je vais juste répondre à ton premier point: le fait que KDE s'appuie sur un framework non libre (Qt à l'époque) était quand même sacrément choquant pour un bureau libre, et tout le monde avait bien compris la motivation de la création du projet Gnome à cette époque.
Absolument rien de WTF pour le coup.

Ensuite tu peux tout à fait faire de l'encapsulation en Javascript, il suffit de se sortir les doigts: http://javascript.crockford.com/private.html

C'est quand même assez limité lorsqu'on veut un peu optimiser les choses.
Si j'osais, je dirais que c'est comme si on filait un pistolet à billes à un soldat.
Par exemple, définir des fonctions dans le constructeur (le concept de membre privilégié dans le texte de ce bon vieux Douglas Crockford) est une mauvaise pratique car elle instancie une méthode par instance d'objet, au lieu de la définir dans le prototype.
Pareil pour le concept de membres privés, lorsqu'on souhaite définir les fonctions dans prototype, ces fonctions ne peuvent naturellement plus accéder aux variables du scope du constructeur, donc pour mutualiser des données entre les fonctions du prototype, on est forcé de les déclarer dans l'objet ou dans son prototype (public).
Cela dit, j'ai pleinement pris le parti de faire comme tu disais et d'assumer pleinement les manques du langage ; je fais du private par convention, dans la documentation, et tant pis pour ceux qui passent outre. Ca a quand même des effets assez horribles, moi je m'en fous, je fais du code métier, si quelqu'un utilise des membres privés de mon code, ça sera un collègue et on peut s'arranger, mais on utilise un framework javascript connu (extjs), et lorsqu'elle possède certains manques fonctionnels, on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal, mais j'ai remarqué qu'on était loin d'être les seuls, du coup, je plains un peu Sencha pour gérer la réorganisation de son code privé au regard de sa clientèle qui paniquera le jour où plus rien ne marche à une révision mineure supérieur :) Du coup, on met de gros warnings dans le code les quelques fois où on est poussé à le faire.

J'imagine que ça dépend à quel point on hiérarchise son "workflow", personnellement, j'ai 8 bureaux virtuels et rajouter un nouveau niveau de profondeur sémantique (les activités) me semble overkill.
Cette idée de hiérarchiser un peu plus ses applications est séduisante, je suis développeur et ça m'aurait fait marrer de coder un truc comme ça, mais en pratique, il faut se méfier des niveaux d'imbrications, ça rajoute une couche de complexité souvent mal appréciée. Maintenant, même si je suis persuadé que ce truc là est vraiment en phase avec les attentes de nombreuses personnes, je ne suis pas certain que ça valait forcément le coup de le rendre aussi visible au sein du bureau KDE.

Et c'est encore pire sous Mosaic. Ces gens qui ne respectent pas les standards du web, ça me dégoûte.

Tu as raison, j'ai un peu buggé, je préfère donc remettre un lien vers le commentaire que j'en faisais à l'époque :
http://linuxfr.org/users/gnumdk/journaux/un-nouvel-environnement-de-bureau#comment-1301519

Les applications sont là pour vous.

"activités"

Bon sinon, mon avis n'a pas changé depuis toutes ces années ; le concept d'activité, c'est très sympa (pas d'ironie) mais je pense que trop peu de monde en a l'utilité pour imposer cet espèce de gros bouton sur le fond du bureau KDE qu'il est impossible de cacher.

J'apprécie les liens généraux en haut à gauche dans un bandeau toujours visible.
Les liens à droite dans la CSS par défaut sont anti-ergonomiques au possible, le regard étant généralement porté dans le coin nord-ouest.
Attention néanmoins aux liens répondre/modifier du commentaire qui se chevauchent (bug reproductible naturellement seulement pendant le cours laps de temps qui suit la création du commentaire).

En informatique, si tu n'avances pas, tu recules. Ok, j'exagère un peu (quoique) mais je trouve ça très bien que l'équipe KDE adapte peu à peu leur code aux fonctionnalités les plus modernes du framework sur lequel il s'appuie, ça permettra une plus grande souplesse plus tard.
Et puis si y'a quelques bugs, c'est pas dramatique, en tout cas, moins dramatique que si tu payais cet environnement de bureau et que tu exigeais un niveau élevé de stabilité.
Et puis un logiciel libre, c'est aussi l'occasion pour les développeurs de se faire un peu plaisir, on est pas uniquement dans un rapport de fournisseur à client.

Et tu proposes quoi ? De fouetter les développeurs ou bien de les rétribuer financièrement pour qu'ils se magnent le cul ?

Déjà on n'achète pas un flim, on achète une copie d'un flim.

Ouf, merci de la précision, on avait tous compris qu'on repartait avec le master sous le bras ainsi que les droits d'exploitation, le tout pour $5.
Y'a des mouches qui doivent marcher de traviole…

Je ne comprends pas ce que tu reproches au projet KDE : qu'il ait mis un certain temps à corriger le problème ou bien qu'il ne force pas les distribs à intégrer le correctif introduit dans la 4.9 ?
Dans le premier cas, je te conseille simplement de passer par leur service commercial pour obtenir un remboursement.
Dans le second cas, je te recommande d'écrire une lettre manuscrite à l'équipe de ta distribution favorite, mais n'oublie pas les formules de politesse qui siéent.

Comme tu dis.
Les limites du format INI sont connues depuis longtemps mais lorsqu'il s'agît de stocker des clefs/valeurs avec une faible profondeur hiérarchique et/ou de lire/editer de façon intuitive le fichier, c'est un format de choix.
On peut toujours "bidouiller" pour stocker des tableaux dans un format INI (ajout d'un suffixe d'indexation des clefs).

Même si j'ai une faiblesse pour le JSON qui arrive à allier concision et simplicité de lecture.
Le XML par contre, sa puissance est clairement dans ses systèmes de validations/schémas, mais le reste, erk…

Pour les menus freedesktop, j'ai un peu de mal à comprendre pourquoi il a été choisi par rapport à JSON/XML, on pourrait pré-supposer qu'un menu est une hiérarchie d'entrées.

Où il m'a mis la patée ?
Me mettre la pâtée c'est me démontrer que systemd est l'outil qu'il faut.

Pas exactement ; je me fiche de savoir si vous êtes ou non convaincu par l'explication de Misc, par contre, force est de constater que ses explications sont beaucoup plus limpides, techniques et exhaustives que l'espèce de mélange de propos sans queue ni tête qui constituent votre commentaire. Sérieusement, j'ai buté un nombre incalculable de fois sur vos phrases en me demandant ce que vous aviez bien voulu dire par là. Sans parler des petites tournures de phrase débiles qui n'apportent strictement rien au débat comme : "1/ je ne suis pas admin. Donc je dois être facile à convaincre. C'est raté."
Ho my gosh, je viens de relire le 2/, c'est encore pire que le 1/
En fait, c'est même plus fort que ça, on dirait parfois sur Jean-Claude Van Damme :

En France, les gens veulent une voiture au diesel, donc le contructeur fait encore du diesel. Au Japon, c'est strictement interdit pour des raisons de santé publique.
Me diriez vous que nous sommes ici intelligents en voulant toujours du diesel ?

Sans parler de cette étrange obsession sur la présupposée inadéquation/médiocrité du format ini pour un fichier de configuration. Qu'est-ce qui vous fait dire cela ? De l'XML, du JSON ou du format INI, ce dernier est bien le plus lisible et est encore utilisé par un nombre infini de projets d'envergure.

Punaise, tu lui as mis sa pâtée, c'en est presque écœurant ;)

C'est beau comme la Pravda. CSS, c'est le langage si simple et accessible qu'aujourd'hui tout le monde préfère utiliser des surcouches (bootstrap, etc.).

Accessible, CSS l'est assurément, et documenté.
"Simple", ok, ça peut devenir compliqué mais d'une part, non, tout le monde n'utilise pas des surcouches à CSS, d'autres part, ces surcouches pondent du CSS/HTML en sortie donc y'a pas vraiment de contradictions ; on garde un format universel, qu'on peut concevoir de façon "haut niveau" avec des toolkits.

Tu essayes de trop intellectualiser les propos et de prêter des intentions aux gens, on est pas en train d'écrire des équations mathématiques, on s'exprime avec nos petits défauts rhétoriques, avec nos raccourcis d'êtres humains et toi tu pars dans de grandes théories sur l'égalité devant la famille entre une femme de ménage et un développeur, non mais ho, arrête toi deux secondes et respire un grand coup ;)

Bah pour moi le débat est mort depuis un moment, c'est une sorte de gloubi-boulga de malentendus, de certitudes, d'incompréhensions, et de lieux communs. On ne va rien apprendre (il existe des gens talentueux, des gens talentueux qui bossent, des gens non talentueux qui bossent, des gens qui sacrifient leur vie de famille pour leur hobbie, etc), et j'avoue, j'ai un peu participé à ça, je n'ai pas du tout été informatif. J'avais juste envie de crier mon aigreur et ma jalousie face à des Alan Cox :)

En relisant les commentaires, ça me fait peur : les gens ayant posté des commentaires la croient que le libre est obligatoirement un hobby et n'imaginent pas que ça peut être un emploi (exactement comem eux en ont un)?

C'est ça, on est exactement aussi con que ça : on croit que le libre est un hobby pour tout le monde.
T'as vraiment compris le fond de notre propos, ça fait plaisir.

Je confirme à 100%.

J'ai une femme, deux grimlins en bas âge et une maison.
Si je ne partage pas les tâches avec ma douce, mon couple est terminé dans le trimestre :)
Il me reste très très peu de temps pour coder à côté. Ca m'attriste car j'ai quelque part l'impression de ne pas m'accomplir (même si mon boulot principal est intéressant) mais j'ai fais ce choix d'avoir des mômes donc j'assume, et puis "ça apporte d'autres joies" (phrase auto-consolatoire :)).
Ou alors il faudrait que je dorme moins, mais non, j'ai besoin de mes 8 heures.