Ca déraille autour d'Apple... - Page 8

Juste un truc... dans ma boîte, je souhaite faire une transition vers un OS libre... j'ai donc installé à 2 reprises en deux années des Fedora puis Ubuntu... à chaque fois la même remarque des utilisateurs sur les postes de test : "c'est laid" et "pas clair" (en particulier sur les outils bureautiques. Je souhaite vivement sauter le pas, mais je sais que le changement provoque un rejet, loin d'être objectif (refus d'évolution, de réapprendre certaines choses, etc...), mais il est quand même là.
J'ai eu la même réaction avec des gens quittant le monde Mac OS pour du Windows (y'a même eu des rires moqueurs).

Fait gaffe, PpHd et Lionel vont te traiter d'incompétent

Je plussoie aussi ceux qui ont dit ci-dessus que les applications libres et multiplateformes sont laides et/ou lentes. Y'a qu'à voir OpenOffice, TIEmu, TILP, et bien d'autres.
Java a l'air par contre de bien s'en sortir. J'ai une application Java sur mon ordi que j'utilise tous les jours. Elle est pas plus lente que les autres programmes et est très belle (MyFreeTV).

dualmoo (./206) :
Ensuite des formats ouverts qui marchent y en a plein (à peu près tout langage de prog lambda par exemple), et des formats ouverts qui ont un rendu indépendant du logiciel y en a aussi (pdf).

Il peut y avoir certaines différences de rendu (par exemple au niveau des couleurs). Je n'ai pas d'exemple en tête, mais mon chef en a vu un certain nombre (mais le pdf n'est quand même pas un format libre).

Martial : aucun Cela dit, les applications multiplateformes non libres sont rares. Quand elles existent, elles ont intérêt à être belles pour se vendre.

ici, on est bien d'accord que "se vendre" est au figuré, hein

Le rapport c'est que, de nos jours, les logiciels non libres sont dans leur immense majorité commerciaux Nan ?

Flanker (./202) :
Accessoirement, je n'aime pas les applications qui ne sont pas intégrées à l'OS (genre les boîtes de dialogue pour sélectionner les fichiers qui ne ressemblent à rien...)

Qt/Win et Qt/Mac utilisent les boîtes de dialogue natives, sous X11, l'application est censée utiliser KFileDialog (parce que KDE est l'interface native).

Martial Demolins (./210) :
C'est hideux et trop gros. C'est pour ça que l'niterface de TiEmu est si degueuasse avec GTK, parce que le toolkit est moisi graphiquement Du coup on a une fenêtre de 500*500 pour afficher trois pauvres valeurs

Attention, GTK+ != Qt... Regarde KTIGCC si tu veux voir du Qt.

Kevin Kofler (./221) :

Flanker (./202) :
Accessoirement, je n'aime pas les applications qui ne sont pas intégrées à l'OS (genre les boîtes de dialogue pour sélectionner les fichiers qui ne ressemblent à rien...)

Qt/Win et Qt/Mac utilisent les boîtes de dialogue natives, sous X11, l'application est censée utiliser KFileDialog (parce que KDE est l'interface native).

Y a pas que ça... par exemple, sur Mac
ça n'utilise pas le carnet d'adresse, le drag 'n drop complètement, le trousseau (pour les mots de passe ou les certificats), le correcteur orthographique de base, les raccourcis clavier normaux, les réglages pour les proxys, l'API pour les flux RSS, ...

Bah, il y a des compromis à faire, si on utilise les interfaces propriétaires que Apple propose, ça ne tournera sur rien d'autre. Parfois, un wrapper portable est la meilleure solution, mais parfois le mieux est d'utiliser une librairie multiplateforme (qui d'autant plus est souvent le standard de facto sur les *nix libres) et d'ignorer la solution propriétaire, la gestion des flux RSS est un bon exemple de ça. Pour le correcteur orthographique, KDE 4 utilise Sonnet qui utilise Enchant comme le backend par défaut, et à son tour Enchant a un backend AppleSpell. Donc une application KDE 4 utilise bel et bien (ou du moins peut utiliser) le correcteur orthographique de OS X.

Zephyr (./209) :
Ah bah très bon exemple, d'après toi tous les compilos C acceptent depuis longtemps exactement le même code sans broncher ? Vu l'age du langage c'est ce qu'on pourrait souhaiter, mais il ne me semble pas que ce soit le cas. Par ailleurs, le C repose en partie sur le C qui a eu encore beaucoup plus de temps pour que les choses se tassent, et ce sont justement les features complexes du C qui ont posé des soucis puisque tous les compilateurs ne les implémentaient pas de la même façon. Et je ne parle même pas des features qui ont été implémentées avant d'avoir été normalisées totalement, ce qui a introduit encore un peu de jeu dans l'ensemble.

Bon, ben si tu préfères l'Ogg Vorbis, par exemple, est un format ouvert et compliqué. Et tous les lecteurs d'Ogg Vorbis lisent la même chose (et heureusement). De même pour le xvid ou autres.

Zephyr (./209) :
Lui il a donné des exemples que je peux facilement vérifier avec un coup de Google, coté crédibilité si je débarquais sur le topic je pense que mon avis serait vite fait. Et comme je l'ai déjà dit, je suis globalement d'accord avec ce qu'il a posté.

Mais le problème est qu'il donne des exemples bien choisis pour dire que les formats ouverts sont pourraves, alors qu'il existe des contres exemples et je viens d'en citer. Et surtout ce que je critique dans son post est le troll contre les logiciels libres qui n'ont rien à voir là dedans.

Flanker (./214) :
Il peut y avoir certaines différences de rendu (par exemple au niveau des couleurs). Je n'ai pas d'exemple en tête, mais mon chef en a vu un certain nombre (mais le pdf n'est quand même pas un format libre).

Je ne parle pas de format libre mais de format ouvert, faut arrêter de modifier mes propos. Et je cite wikipedia : « PDF is an open standard, and is now being prepared for submission as an ISO standard. »

Par ailleurs oui il y a surement des différences de rendu entre les logiciels de pdf, mais si on va par là il y a aussi des différences de rendu entre la version windows et la version linux de flash. Ces différences sont souvent mineures, et ce n'est heureusement pas grave. Même si on veut une similarité de rendu plus forte qu'entre deux pages webs vues par deux navigateurs différents, on ne veut pas une égalité bit à bit, que ce soit en flash, en pdf ou dans la plupart des autres formats complexes.

dualmoo (./225) :
Bon, ben si tu préfères l'Ogg Vorbis, par exemple, est un format ouvert et compliqué. Et tous les lecteurs d'Ogg Vorbis lisent la même chose (et heureusement).

Compliqué ? À coté d'un compilateur C++ ou de Flash, pas tellement il me semble (surtout qu'a priori c'est seulement l'algo qui est complexe, pas l'implémentation à partir du standard qui, j'imagine, donne les indications nécessaires).

Mais plus important : comme je l'ai déjà expliqué à propos du pdf, il n'y a pas besoin de référence pour savoir si on a correctement codé un lecteur ogg ou pas : ça s'entend. C'est encore une fois une différence énorme avec des standards genre CSS ou SVG, où l'objectif théorique à atteindre n'est que plus ou moins bien décrit sur un bout de papier, laissant la porte ouverte à toutes les mauvaises interprétations possibles (que ce soit de la faute du standard ou des gens qui l'implémentent, peu importe).

Pas forcément, il peut y avoir des erreurs de décodage qui ne s'entendent que sur certains exemples, tout comme les erreurs d'intérprétation du standard C ne se reconnaissent que sur certaines sources.

Kevin Kofler (./224) :
Bah, il y a des compromis à faire, si on utilise les interfaces propriétaires que Apple propose, ça ne tournera sur rien d'autre. Parfois, un wrapper portable est la meilleure solution, mais parfois le mieux est d'utiliser une librairie multiplateforme (qui d'autant plus est souvent le standard de facto sur les *nix libres) et d'ignorer la solution propriétaire, la gestion des flux RSS est un bon exemple de ça. Pour le correcteur orthographique, KDE 4 utilise Sonnet qui utilise Enchant comme le backend par défaut, et à son tour Enchant a un backend AppleSpell. Donc une application KDE 4 utilise bel et bien (ou du moins peut utiliser) le correcteur orthographique de OS X.

Personnellement, j'ai fait mon choix et je n'utilise aucune application multi-plate-forme

Tiens, d'ailleurs question bête... c'est impossible d'envisager à +/- long terme une fusion de GTK et de QT ?

politiquement, jamais, c'est comme si tu proposes de fusionner vim et emacs

maintenant techniquement...
A la limite un backend QT pour GTK ou l'inverse, mais une fusion ça m'étonnerait. question d'archi globale. Mais je suis vraiment pas sûr.

Nil (./229) :
Tiens, d'ailleurs question bête... c'est impossible d'envisager à +/- long terme une fusion de GTK et de QT ?

Techniquement ? non les approches sont trop opposé..

GTK = Procedural

QT = Objet

Kevin Kofler (./227) :
Pas forcément, il peut y avoir des erreurs de décodage qui ne s'entendent que sur certains exemples, tout comme les erreurs d'intérprétation du standard C ne se reconnaissent que sur certaines sources.

Il pourrait, oui; ceci dit le but d'une batterie de tests un minimum fournie est de trouver facilement ces erreurs, et on les trouvera facilement puisqu'elles s'entendent. Cependant comme tu dis, on pourrait imaginer qu'il reste des erreurs de décodage assez subtiles dans certains codecs actuels, ça va dans le sens de ce que j'explique

Oui et comme je dis plus haut, adobe fait aussi des différences de rendu entre la version windows et linux de flash, et probablement qu'il y a même des différences subtiles entre la spec d'actionscript qu'adobe présente aux développeurs et son comportement réel. L'important est que ces différences soit minimes, mais il y en a toujours, c'est sûr.

Flanker (./228) :
Personnellement, j'ai fait mon choix et je n'utilise aucune application multi-plate-forme

C'est de la bêtise, tu perds des applications importantes pour aucune raison.
Et tu utilises quel navigateur web? Même Safari est disponible sur une autre plateforme maintenant. Où alors tu ne surfes qu'avec IE7 sous l'OS qui va avec?

Nil (./229) :
Tiens, d'ailleurs question bête... c'est impossible d'envisager à +/- long terme une fusion de GTK et de QT ?

Pas vraiment. Histoires de licence, de modèle de développement, d'architecture (les APIs sont très différentes), de langage de programmation (C vs. C++), ...

squalyl (./230) :
A la limite un backend QT pour GTK ou l'inverse, mais une fusion ça m'étonnerait. question d'archi globale. Mais je suis vraiment pas sûr.

Même là, seulement si tu limites "backend" à l'affichage, pas à la gestion d'évènements etc. D'ailleurs, ça a déjà été fait, cf. gtk-qt-engine, et cf. un projet pour faire la même chose dans l'autre sens dont je ne sais pas où il en est.

Godzil (./231) :
Techniquement ? non les approches sont trop opposé..

GTK = Procedural
QT = Objet

Là par contre, c'est n'importe quoi, GTK+ est certes en C, mais avec un système d'objets (GObject).

Kevin Kofler (./234) :
Là par contre, c'est n'importe quoi, GTK est certes en C, mais avec un système d'objets (GObject).

Que ça donne une impression d'etre de l'objet n'en fait pas de l'objet, ça reste procedural, car c'est du C, et non du C++

Kevin Kofler (./234) :

Flanker (./228) :
Personnellement, j'ai fait mon choix et je n'utilise aucune application multi-plate-forme

C'est de la bêtise, tu perds des applications importantes pour aucune raison.
Et tu utilises quel navigateur web? Même Safari est disponible sur une autre plateforme maintenant. Où alors tu ne surfes qu'avec IE7 sous l'OS qui va avec?

Lesquelles ?


enfin, safari, c'est franchement raté comme port multi-plateforme, tout comme iTunes et T… Par contre, sur sa plate-forme d'origine, ça poutre Et si ça ne me dérange pas d'utiliser Safari et QTPlayer sur leur plate-forme d'origine, je ne les utilise pas sur Windows…

Flanker (./236) :
enfin, safari, c'est franchement raté comme port multi-plateforme, tout comme iTunes et T… Par contre, sur sa plate-forme d'origine, ça poutre Et si ça ne me dérange pas d'utiliser Safari et QTPlayer sur leur plate-forme d'origine, je ne les utilise pas sur Windows…

Heu safari a la limite (enfin la verison iPhone/iPod Touch, je peut pas la conciderer comme raté) mais WebKit non c'est vraiment pas un truc raté

Mais je n'ai pas parlé de wekbit, vu que ce n'est pas une application ^^

Safari a carrément été porté n'importe comment (aucune intégration à la plateforme, au contraire ils se cassent la tête à imiter le look OS X au maximum - et puis où est la version GNU/Linux? ), mais justement Qt par exemple (et là je dis bien Qt, pas QuickTime, hein ) fait beaucoup d'efforts pour s'intégrer, donc les applications Qt ne devraient pas être lourdes à l'utilisation.

Kevin Kofler (./239) :
et puis où est la version GNU/Linux? )

Pourquoi faire ?

, mais justement Qt par exemple (et là je dis bien Qt, pas QuickTime, hein ) fait beaucoup d'efforts pour s'intégrer, donc les applications Qt ne devraient pas être lourdes à l'utilisation.

Ça ne vaut toujours pas une appli qui utilise vraiment bien le framework Cocoa (ou alors ton appli offre des fonctions absentes des versions linux et windows)