Benjamin Poulain a écrit 133 commentaires

C'est dans ces moments là qu'on regrette de ne pouvoir éditer les posts :(

Sur KDEnews, il y a eu pas mal de demande pour pouvoir ajouter des commentaires: http://www.kdenews.org/2009/07/12/ongoing-oxygen-icons-usabi(...)

Pour le moment, les graphistes de Oxygen ne sont pas chaux car ils ont peur d'être submergé de commentaire.

Concernant le contexte des icônes, les graphistes disent qu'une icône doit être claire en dehors de l'interface. D'ailleurs sur KDE tu bouges facilement les icônes de place si tu veux, ça pourrait être contreproductif de mettre les icônes voisines.

Les graphistes essayent notamment de faire des icônes qui fonctionnent dans toutes les cultures, et qui soit relativement intemporelle. D'une culture à l'autre, et d'une époque à l'autre, certains éléments n'ont pas la même signification, c'est pour ça qu'ils sont avides de retour comme ce petit formulaire.

Le temps qu'on prend à répondre est aussi pris en compte. Si on hésite c'est un signe qu'ils doivent retravailler l'icône.

Sur Qt on peut en soumettre depuis peu et un collègue qui bosse avec moi à déjà soumis des patchs, mais on lui a dis qu'ils ne pourront pas être intégrés avant quelques mois faute de temps...

Quelques mois? Ils vont super vite les merges request chez Qt! Généralement on a une réponse le jour même, au pire ils le font dans la semaine:
http://qt.gitorious.org/qt/qt/merge_requests?status=merged
C'est laquel la merge de ton collègue?

A noter aussi qu'un développeur de KDE à réussi à faire tourner Plasma sur Symbian: http://www.youtube.com/watch?v=9ni_6qTwj-Y

Une fois que KDELib fonctionne sur les téléphones, on pourrait imaginer porter pas mal d'applications sur Symbian.

Tu confonds avoir une interface standard et forcer la pensée unique.
À t'entendre il faudrait avoir 50 définitions incompatible de TCP/IP, XML, HTML, etc.

Le fait d'uniformiser les outils et des proposer des solutions à des problèmes comme le painting ou le son ne va pas freiner l'innovation sous Linux.

Prend glibc, openssl, fontconfig, pthread etc.
Est-ce que ça a empêché l'innovation? :)

Il faut changer tout le code, les API sont différentes entre XCB et XLib.

À moins que Freedesktop.org ne décide de mieux supporter XCB, ça risque de rester une solution marginale.

XCB marche pas mal. Ça ne corrige aucun des problèmes de X11 (évidemment...), mais par rapport à XLib c'est un net progrès.

Le problème est qu'il manque toujours la dynamique de XLib pour ce projet. La documentation est trop maigre et les extensions de X11 sont d'abord écrites pour XLib, ensuite porté sur XCB si on est patient.

Le problème de QtCurve c'est que c'est une grosse bidouille plutôt qu'une solution.

En gros il font le boulot en double, en faisant un style similaire pour les deux environnement. Si un autre acteur vient se greffer (smalltalk, java, ...), il faut tout recommencer. Il faudrait plutôt que ça aille dans l'autre sens, les frameworks qui viennent utiliser un système de style, pas recopier le système de style pour tout les systèmes.

Pour les boutons le problème ne se pose que avec GTK. Pour KDE le QDialogButtonBox met les boutons dans l'autre sens quand l'application fonctionne sur GNOME.

Je suis pas sûr que ça me plaise que la solution est de tout péter et de tout recommencer en Java...

Surtout quand on voit la vitesse d'Android comparé à nos applications natives.

Tu as raisons que l'utilisateur se fou qu'il utilise Qt ou GTK mais ça pose tout de même quelques problèmes.

Il n'y a pas de système de style standard sous Linux. Qt s'intègre bien dans GNOME, mais ce n'est pas le cas des applications KDE. Dans l'autre sens ça ne marche pas du tout, GTK ne s'intègre pas dans les autres système de style des autres environnement.

Donc l'utilisateur voit un look and feel complètement différent entre les applications. Pour contenter les constructeurs, il faudrait un système de style indépendant des bibliothèques, et il faudrait des directives communes sur la façon dont doivent être conçu les interfaces.


Un second problème est pour attirer les développeurs sur la platforme. Tant qu'on reste sur les couches Unix, Linux a un environnement de développement des plus agréable avec des bibliothèques standard. Par contre quand tu fais du développement graphique, il n'y a pas "d'outils standard" auxquels tu peux t'accrocher.

J'aurais du être plus clair apparemment. :)

Bien sûr, ça fonctionne on utilise OpenGL directement! :-D
L'accélération matérielle est inexploitable pour les opérations standard de X11. Si tu fais du rendu logiciel tu vas encore plus vite qu'en laissant X utiliser la carte graphique.

Les coordonnée 16 bits ça veut dire que tu quand tu dessines un objet au delà de 65536 pixels il revient à 0. Tu vas me dire que personne n'a besoin d'aller aussi loin....mais si tu as des scrollbars tu arrives vite à ça.

Pour que ça marche, tu dois contourner le problème en software, ce qui est beaucoup de boulôt pour contourner un problème de conception du serveur graphique. :(
Si on compare à Quartz par exemple, là il n'y a bas besoin de faire des backends pour décaler toutes les coordonnées.

Vu l'API de Cocoa autant revenir à Motif :)

La lenteur, les latences avec XLib, les coordonnées sur 16 bits, le painting approximatif de certaines primitives, l'accélération matérielle inexploitable, la gestion de la composition...je ne sais vraiment pas ce qu'on lui reproche à ce X11.

"Fragmentation" est le mot qu'on peut lire sur les blogs et forums anglophones en ce moment.

Moblin aussi fout son bordel. On a déjà pu voir des bagarre au sein des communautés GTK autour de clutter, comme si le l'ouverture de Qt en LGPL était pas suffisant pour miner GTK...

On peu prendre le bon côté des choses. Jamais Linux n'a suscité autant d'intérêt pour les téléphones et les pc portables. Ce qui est dommage c'est qu'on assiste à des batailles de grosses entreprises qui ont décidé de réinventer toute la couche graphique.

À la décharge de ces entreprises, il faut admettre que la situation de Linux sur le desktop n'est pas envieuse. Le serveur X est une horreur sans nom, Intel, Google et Palm s'en passent ou le contournent. La guerre Qt contre GTK dure depuis trop longtemps, il est plus que temps de favoriser l'un des deux pour attirer les développeurs.

wow

Je viens de jeter un coup d'œil au code aussi. Je suis d'accord que les commentaires en Français c'est une très mauvaise idée. Il y a même un mélange d'anglais et de Français.

On voit dans le code que tu manques de l'expérience qu'on acquiert sur des projets comme KDE.

Quelques remarques en vrac sur ce que j'ai vu:
-tu ne respectes pas les conventions de codage de Qt et KDE (http://techbase.kde.org/Policies/Kdelibs_Coding_Style). Pourquoi se donner du mal?
-il y a beaucoup de code franchement dégueulasse comme:
QHttp::ConnectionMode mode = murl.scheme().toLower() == "https" ? QHttp::ConnectionModeHttps : QHttp::ConnectionModeHttp;
Quand tu contribues à un gros projet comme KDE, tu t'arranges pour que le code soit bien lisible pour la review. Tu pourrais apprendre pas mal de chose grâce à ces reviews
-beaucoup de commentaires sont inutiles. Des commentaires plus généraux sur des blocs de code sont plus intéressant que des commentaires qui dit ce que fait la ligne qui suit.
-le design des classes est parfois bancal.

Je pense que tu gagnerais vraiment a participer à un projet open-source. Si tu contribue à Qt ou KDE, du code comme celui que j'ai vu serais rejeté. MAIS tu apprendrais a améliorer ton code et le patch suivant serait mieux.

Juste par curiosité, est-ce que tu as déjà contribué à des projets open-sources?

Réinventer les mêmes solutions avec quelques variations est un des maux des logiciels libre. Plutôt que de tout recréer depuis zéro, ne serait-il pas plus profitable à l'ensemble de la communauté si ces changements étaient proposé dans dpkg/rpm.

Je ne pense pas que les développeurs de dpkg/rpm soient beaucoup plus con que toi, ils apprécieront toute amélioration bien écrite. Et de ton coté tu profiteras de toute les solutions aux problèmes qui ont été résolu par eux.

Je viens d'essayer Skyfire sur un N96, c'est plus lent que le navigateur par défaut qui est basé sur Webkit.

Où a tu trouvé que ça utilisait Gecko? Le comportement du javascript de certains sites est différent de celui de Firefox.

Le navigateur de Nokia est basé sur Webkit. C'était d'ailleurs le premier port de Webkit sur téléphones.

J'ajouterais aux commentaires précédents que les changements de KDE 4 ne sont vraiment pas limité au passage à Qt 4.
Le passage a Qt 4 à permit de faire de nombreux changement structurels pour avoir une meilleure base de code (API super propre pour KDElibs, kicker -> plasma, KWin qui gère directement le composite, rien->akonadi, konqueror->dolphin pour les fichiers, etc).

Soit dit en passant, Firefox n'utilise pas GTK+, il utilise juste le moteur de thème de GTK+, comme fait Qt 4.5...

Et la lenteur de GTK ne pourrait pas justifier la vitesse de Firefox, le plus gros du rendu n'ayant rien à voir avec la bibliothèque graphique.

Je trouve la philosophie un peu bancale, "simple d'utilisation, et très ergonomique", ça s'applique aux autres environnement de bureaux aussi. D'autant plus que les KDE et consort utilisent des études sur l'ergonomie pour améliorer leurs interfaces, je n'ai rien vu de tel pour Logram.

Sinon c'est chouette de voir de nouveaux environnement basé sur Qt. Mais j'éviterais de tout réinventer: LIO à la place de KIO, Panache-wm à la place de KWin. Patcher ces derniers et les intégrer me parait mieux que réinventer la roue.

c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.

Essaye PyQt, tu verras si Qt ne tourne correctement qu'avec C++. L'intégration à Python est nickel.
Je peux dire la même chose pour Qt Jambi.
Et dans une certaine mesure j'aime bien aussi Qt Script, qui n'est jamais que du Javascript pour Qt.

Mais oui, peu de gens aiment .Net, et du coup les bindings sont pas terrible parce que personne n'a envie de bosser pour cette plateforme. Bienvenu dans le monde réel.

J'arrête de me prendre la tête avec toi, tu ne réponds jamais qu'à ce qui t'arrange et tu cherches tout sauf une discutions constructive.

Il ne me reste qu'à te souhaiter bon courage pour développer des applications multiplateforme avec .Net.