Parce que je ne suis pas totalement idiot et que même si je ne suis pas dev, je suis quand même sysadmin et je suis quand même capable d'avoir une petite idée de la manière dont on développe un logiciel, et de ce qu'une doc doit fournir.
Je réalise que ma phrase était mal formulée, je te présente mes excuses.
Explique en quoi, parce que j'ai du mal à voir où. J'avoue que je ne suis pas développeur, mais a-priori les deux fournissent les informations nécessaires…
Si tu n'es pas développeur, comment arrives-tu à savoir a priori ce qu'il est nécessaire d'aller chercher comme informations ?
Je sais bien que mon affirmation était péremptoire, mais franchement, il faut développer souvent en Qt pour comprendre en quoi cette doc est, à défaut d'être parfaite - aucune doc ne l'est - très bonne.
Elle anticipe de nombreux cas d'usages qui sortent un peu du cadre général d'utilisation des objets Qt, c'est en cela qu'elle cartonne, dans sa réponse à ces situations un peu tendues où l'on utilise un objet de façon peu courante.
En outre, elle n'hésite pas à intégrer des bouts de codes en exemple même dans les documentations de membres des classes en anticipant également les prochaines étapes (ou même transverses) de conception de notre logiciel, typiquement http://doc.qt.digia.com/qt/qmainwindow.html#restoreState
Je ne dis pas qu'elle est mal foutue, non plus, je dis juste que je ne la trouve pas parfaite. Son concurrent chez gtk à aussi ses défauts, elle est un peu fruste, mais de là à dire de façon catégorique que celle de Qt est la meilleure, il y a un fossé que je n'oserais jamais franchir.
Moi je le franchis, mais vraiment complètement et sans hésitation.
C'est peut-être parce que je connais les deux, je les pratique, et je prends un plaisir bien plus grand avec la doc Qt, car elle est complète et rigoureuse et m'évite des aller-retour avec des forums et des sites pour trouver de l'info.
Par contre, la doc à un problème, ici: quid de la complexité de cette fonction? "find" => "recherche" => consomme du temps. Alors?
C'est une preuve que cette doc n'est pas exhaustive.
Là franchement, y'a des mouches qui devraient mettre un peu de lubrifiant si elles veulent passer une meilleure soirée ; si tu veux une doc qui colle autant au code source de la lib, bin… lis le code source, ça tombe bien, il est libre. D'autre part, un code IHM qui cherche un widget en fonction d'un id n'a pas forcément besoin d'un algo en O(log(n)), savoir si on est dans un parcours intégral des widgets (dans le pire des cas, comme on peut le supposer) ou pas est une info d'un intérêt très relatif.
Sinon, tant que la doc ne collera pas à la ligne prêt au code source, il y aura des gens mécontents qui se serviront de ce prétexte pour avoir toujours raison dans les conversations.
mais ça me prend plus de temps pour, par exemple, connaître la totalité de la hiérarchie. De quoi hérite QAbstractButton ?
C'est plus fin que ça avec la doc Qt, dans chaque section (public/protected/private) tu as le nombre de propriétés héritées des classes ancêtres, tu peux donc indirectement voir par exemple pour le QPushButton pour les méthodes publiques que :
21 public functions inherited from QAbstractButton
215 public functions inherited from QWidget
31 public functions inherited from QObject
12 public functions inherited from QPaintDevice
Et tu as les liens directes vers les portions des scopes (public/protected/private) pour les ancêtres.
Après bien sûr, y'a toute une page avec la hiérarchie des objets Qt, mais c'est en vrac et pas pratique à lire.
Vous cherchez vraiment la petite bête.
Le ton de Tanguy est rentre dedans, je comprends que ça irrite, mais franchement, la doc de Qt est vraiment difficilement attaquable.
Encore un exemple : http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html
Dès qu'un comportement est un peu particulier, il est décrit en détail, avec des schémas s'il le faut, des justifications sur le pourquoi du comment, etc.
Cette doc m'a de nombreuses fois évité d'aller parcourir les forums/stackoverflow
Suivant Qt depuis plus d'une dizaine d'années, j'ai surtout vu une équipe de gens très talentueux et à la barre, des personnes qui ont su imposer un très gros niveau de qualité, en particulier au niveau de l'API qui est d'une très grande clarté et cohérence.
La doc est absolument géniale, elle fourmille d'exemples, de cas d'usages, est d'une exhaustivité rare, c'est un vrai bijou.
Je réalise que mon commentaire est dithyrambique mais ce framework m'a vraiment réconcilié avec l'IHM alors que je sortais d'années de développement avec Delphi.
Comparer les deux n'a absolument aucun sens, ils n'ont pas du tout la même vocation.
Oui, menfin lorsqu'on souhaite écrire un GUI multiplatforme, vient le moment où on se demande si on va opter pour tel ou tel toolkit et les candidats sont peu nombreux, entre autre : GTK, QtGui, wxWidget, Java et .NET (je déconne).
Ca paraît donc relativement pertinent de mettre Qt et GTK dans la balance à ce moment là.
Il faut surtout se demander si on peut les mettre au même niveau, Qt est très générique et VCL a l'air de loin (mais je peux me tromper) d'être une lib métier dédiée à la suite bureautique, VCL offre peut-être des outils qui seraient considérés comme appartenant à une couche au dessus de Qt, bref, est-ce vraiment comparable ? Sans compter que VCL a l'air d'être uniquement dédiée au graphique là où Qt offre beaucoup plus de possibilités.
De toute façon, qui a envie d'évaluer le temps que ça prendrait de convertir la VCL a Qt ? Qui a envie de se demander s'il faudrait utiliser uniquement QtGui ou bien plus de modules pour le coeur de l'application ? C'est très difficile de bouger l'existant, l'inertie a l'air énorme, et je ne vois pas qui trouverait ça trippant de se dire "hé ho, et si je m'amusais à adapter LibreOffice à Qt en ré-écrivant tous les composants métier de l'application avec !"
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.
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 ?
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.
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.
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.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 2.
Pas à grand chose mais ça peut donner une idée générale de la "pilosité" (nombre de membres) des classes ancêtres.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 3.
Je réalise que ma phrase était mal formulée, je te présente mes excuses.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 9. Dernière modification le 12 février 2013 à 16:37.
Si tu n'es pas développeur, comment arrives-tu à savoir a priori ce qu'il est nécessaire d'aller chercher comme informations ?
Je sais bien que mon affirmation était péremptoire, mais franchement, il faut développer souvent en Qt pour comprendre en quoi cette doc est, à défaut d'être parfaite - aucune doc ne l'est - très bonne.
Elle anticipe de nombreux cas d'usages qui sortent un peu du cadre général d'utilisation des objets Qt, c'est en cela qu'elle cartonne, dans sa réponse à ces situations un peu tendues où l'on utilise un objet de façon peu courante.
En outre, elle n'hésite pas à intégrer des bouts de codes en exemple même dans les documentations de membres des classes en anticipant également les prochaines étapes (ou même transverses) de conception de notre logiciel, typiquement http://doc.qt.digia.com/qt/qmainwindow.html#restoreState
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 5.
Moi je le franchis, mais vraiment complètement et sans hésitation.
C'est peut-être parce que je connais les deux, je les pratique, et je prends un plaisir bien plus grand avec la doc Qt, car elle est complète et rigoureuse et m'évite des aller-retour avec des forums et des sites pour trouver de l'info.
Là franchement, y'a des mouches qui devraient mettre un peu de lubrifiant si elles veulent passer une meilleure soirée ; si tu veux une doc qui colle autant au code source de la lib, bin… lis le code source, ça tombe bien, il est libre. D'autre part, un code IHM qui cherche un widget en fonction d'un id n'a pas forcément besoin d'un algo en O(log(n)), savoir si on est dans un parcours intégral des widgets (dans le pire des cas, comme on peut le supposer) ou pas est une info d'un intérêt très relatif.
Sinon, tant que la doc ne collera pas à la ligne prêt au code source, il y aura des gens mécontents qui se serviront de ce prétexte pour avoir toujours raison dans les conversations.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 10.
C'est plus fin que ça avec la doc Qt, dans chaque section (public/protected/private) tu as le nombre de propriétés héritées des classes ancêtres, tu peux donc indirectement voir par exemple pour le QPushButton pour les méthodes publiques que :
21 public functions inherited from QAbstractButton
215 public functions inherited from QWidget
31 public functions inherited from QObject
12 public functions inherited from QPaintDevice
Et tu as les liens directes vers les portions des scopes (public/protected/private) pour les ancêtres.
Après bien sûr, y'a toute une page avec la hiérarchie des objets Qt, mais c'est en vrac et pas pratique à lire.
Vous cherchez vraiment la petite bête.
Le ton de Tanguy est rentre dedans, je comprends que ça irrite, mais franchement, la doc de Qt est vraiment difficilement attaquable.
Encore un exemple : http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html
Dès qu'un comportement est un peu particulier, il est décrit en détail, avec des schémas s'il le faut, des justifications sur le pourquoi du comment, etc.
Cette doc m'a de nombreuses fois évité d'aller parcourir les forums/stackoverflow
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 5.
Punaise, soit tu as les paupières fermées, soit tu es d'une sacrée mauvaise foi….
Qt a des défauts, mais sa doc enterre largement celle de GTK…
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 10.
Suivant Qt depuis plus d'une dizaine d'années, j'ai surtout vu une équipe de gens très talentueux et à la barre, des personnes qui ont su imposer un très gros niveau de qualité, en particulier au niveau de l'API qui est d'une très grande clarté et cohérence.
La doc est absolument géniale, elle fourmille d'exemples, de cas d'usages, est d'une exhaustivité rare, c'est un vrai bijou.
Je réalise que mon commentaire est dithyrambique mais ce framework m'a vraiment réconcilié avec l'IHM alors que je sortais d'années de développement avec Delphi.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 9.
Oui, menfin lorsqu'on souhaite écrire un GUI multiplatforme, vient le moment où on se demande si on va opter pour tel ou tel toolkit et les candidats sont peu nombreux, entre autre : GTK, QtGui, wxWidget, Java et .NET (je déconne).
Ca paraît donc relativement pertinent de mettre Qt et GTK dans la balance à ce moment là.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 9.
Il faut surtout se demander si on peut les mettre au même niveau, Qt est très générique et VCL a l'air de loin (mais je peux me tromper) d'être une lib métier dédiée à la suite bureautique, VCL offre peut-être des outils qui seraient considérés comme appartenant à une couche au dessus de Qt, bref, est-ce vraiment comparable ? Sans compter que VCL a l'air d'être uniquement dédiée au graphique là où Qt offre beaucoup plus de possibilités.
De toute façon, qui a envie d'évaluer le temps que ça prendrait de convertir la VCL a Qt ? Qui a envie de se demander s'il faudrait utiliser uniquement QtGui ou bien plus de modules pour le coeur de l'application ? C'est très difficile de bouger l'existant, l'inertie a l'air énorme, et je ne vois pas qui trouverait ça trippant de se dire "hé ho, et si je m'amusais à adapter LibreOffice à Qt en ré-écrivant tous les composants métier de l'application avec !"
[^] # Re: jet de séduction: échec critique
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 10.
Ah mince, moi quand je vais au MacDonalds, j'y vais pour manger du canard.
Je comprends, maintenant.
[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Ce qui ressemblerait le plus à la notion de privé en C serait pour moi les déclarations static
[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 6.
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.
# Tu cherches sensations fortes ?
Posté par Guillaume Denry (site web personnel) . En réponse au journal GoPro OpenSource. Évalué à 2.
Te mettre la GoPro sur le front et aller demander à Richard Stallman de faire sa conférence en espagnol.
[^] # Re: Merci Etienne
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
console devient quand même relativement courant voire standard, même dans les frameworks côté serveur, comme nodejs.
[^] # Re: jet de séduction: échec critique
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
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 ?
[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Oui, je suis d'accord, mais je ne répondais pas vraiment à cela.
[^] # Re: troll
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
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.
[^] # Re: jet de séduction: échec critique
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 8.
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.
[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 5. Dernière modification le 07 février 2013 à 08:05.
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.
[^] # Re: erratum
Posté par Guillaume Denry (site web personnel) . En réponse au journal KDE : Bureaux virtuels et Activités. Évalué à 4.
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.
[^] # Re: Le site fait main avec IE6
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche FaitMain.org, un magazine collaboratif sur le Do It Yourself. Évalué à 6.
Et c'est encore pire sous Mosaic. Ces gens qui ne respectent pas les standards du web, ça me dégoûte.
[^] # Re: erratum
Posté par Guillaume Denry (site web personnel) . En réponse au journal KDE : Bureaux virtuels et Activités. Évalué à 2.
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
# erratum
Posté par Guillaume Denry (site web personnel) . En réponse au journal KDE : Bureaux virtuels et Activités. Évalué à 5. Dernière modification le 02 février 2013 à 20:33.
"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.
# Très chouette
Posté par Guillaume Denry (site web personnel) . En réponse au journal Une nouvelle feuille de style. Évalué à 2. Dernière modification le 02 février 2013 à 18:05.
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).
# bah
Posté par Guillaume Denry (site web personnel) . En réponse au journal KDE from scratch. Évalué à 10. Dernière modification le 01 février 2013 à 15:16.
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.