L'affaire fait suite au passage de l'Acid2 Standards-Compliant Test (test de compatibilité avec les standard Web extrêmement exigeant) par Safari. Il y a deux ans, Apple annonçait avoir choisi le moteur de rendu KHTML, issu du projet KDE, comme moteur de rendu pour son navigateur web destiné à supplanter Internet Explorer de Microsoft sur les systèmes Mac ; à l'époque, l'équipe de KHTML se réjouissait de ce choix et Apple s'érigeait en champion de la collaboration avec les développeurs open source.
Deux ans après, le constat est plutôt amer pour les développeurs de KHTML. La collaboration avec Apple s'est faite à sens unique et les deux projets KHTML et Webcore diffèrent tellement que les patches qui ont permis le passage de l'Acid test sont inapplicables aux sources de KHTML. Pour mettre fin aux critiques à son encontre, Apple n'a rien trouvé de mieux que de conseiller aux développeurs de KDE de migrer vers Webcore.
Cette dernière réaction semble être la goutte d'eau qui a fait déborder le vase. Les développeurs de KDE dressent un bilan très négatif de la « collaboration » avec Apple. Ils estiment n'avoir eu aucun poids dans le développement de Webcore, ce dernier s'effectuant essentiellement en interne et sans aucune concertation avec l'équipe de KHTML, l'accès aux source de la branches de développement restant malaisé. La plupart des développeurs de KHTML sont en total désaccord avec l'orientation prise par Webcore (patches rapides et inélégants) et ne souhaitent donc pas intégrer ce code à KHTML.
Le mainteneur de KHTML semble résigné et conclut par :
« Aussi longtemps qu'ils ont eu besoin de nous, ils nous ont utilisés, mais dès qu'ils ont acquis une base de connaissances suffisante, ils n'avaient plus de raison de nous envoyer des compte-rendus et des patches » et « À un moment ils ont décidé que la collaboration était devenue une perte de temps, et ils ont tout simplement cessé de communiquer... Il y a eu un espoir qu'ils contribuent à KHTML mais cela n'est jamais arrivé. »
Est-ce la preuve de l'incompatibilité entre un mode de développement trop éloigné du modèle Open Source (reproche déjà fait dans une moindre mesure à l'encontre de la Mozilla Foundation) ? Une mauvaise gestion de la collaboration par Apple, ou de trop grandes attentes de la part de l'équipe de KHTML ?
Aller plus loin
- Apple WebCore (3 clics)
- Le Blog de David Hyatt (programmeur principal de WebCore) (1 clic)
- Zack Rusin's blog (KDE) (1 clic)
- La nouvelle sur Cnet (1 clic)
- La nouvelle sur /. (0 clic)
- Un article annonciateur sur /. (0 clic)
# Ou pour Gecko ?
Posté par Bruno Ethvignot (site web personnel) . Évalué à 10.
http://www.mozillazine-fr.org/archive.phtml?article=6419(...)
Le projet KDE porte Mozilla et ajoute le support dans les applications
http://www.mozillazine-fr.org/archive.phtml?article=5263(...)
[^] # Re: Ou pour Gecko ?
Posté par JoeltheLion (site web personnel) . Évalué à 9.
D'autant qu'avec l'évolution actuelle de la fondation mozilla, avoir une alternative libre à Gecko ne me paraît pas de trop...
[^] # Re: Ou pour Gecko ?
Posté par Piksou . Évalué à 1.
qu'on approuve pas leur politique de marque OK, je la partage pas non plus mais Gecko est et restera libre, rien n'empêche d'utiliser Gecko dans KDE
oui, dommage de laisser tomber khtml qui marche, mais c'est pas encore plus dommage de diviser les efforts du libre dans deux projets à finalité identique ? (ce qui est un vieux débat...)
[^] # Re: Ou pour Gecko ?
Posté par Frédéric COIFFIER . Évalué à 3.
J'ai eu le problème d'un site avec du JavaScript mal codé qui se comportait mal avec Firefox (impossible de passer à la page suivante car un test était systématiquement faux). A priori, Konqueror doit être plus perméable (souple) au niveau de l'interprétation du JavaScript et Konqueror m'a permis de remplir le formulaire sans avoir à rebooter sous Windows pour utiliser IE. Au final, l'utilisation des 2 navigateurs dans leur état actuel a été un plus.
[^] # Re: Ou pour Gecko ?
Posté par Piksou . Évalué à 0.
Mais avec un moteur unique qui gererait tout tu n'aurais même pas à changer de browser ;-)
Plus sérieusement, cette vision est assez limitée: elle ne vaut que si tu es sous KDE et que tu utilises comme browser principal un autre browser que konqueror (genre ff, donc un truc GTK vu que XUL est rendu par GTK sous X11, arrêtez moi si ça a changé). Quelqu'un sous Gnome va pas installer konqueror et donc les 3/4 de KDE juste pour avoir khtml sous la main :-/ Donc au final ça ne lui sert à rien. Alors que des efforts conjugués aurais peut-être (you may say i'm a dreamer...) permis d'avoir un moteur unique meilleur que Gecko et khtml plus vite et avec une rapidité encore meilleure
# Licences
Posté par john Smith (site web personnel) . Évalué à 10.
C'est qu'une vague histoire de licences... la morale de l'histoire pourrait etre "Dans l'avenir choisi bien ta licence"
C'est ni plus ni moins qu'un Fork bien ficellé...
.
[^] # Re: Licences
Posté par john Smith (site web personnel) . Évalué à 3.
[^] # Re: Licences
Posté par Zorro (site web personnel) . Évalué à -8.
[^] # Re: Licences
Posté par gnumdk (site web personnel) . Évalué à 10.
De plus, webcore est lié au technologie MacOSX, contient de l'objC donc reutiliser webcore dans Kde reviendrait à refaire un nouveau fork. Donc, vu que khtml a continué à évoluer depuis le fork de Apple, il n'y aucune raison de passer à webcore, ca serait une perte de temps.
[^] # Re: Licences
Posté par gnumdk (site web personnel) . Évalué à 10.
http://www.kdedevelopers.org/node/view/1046(...)
Esperons que cela aboutisse vraiment à une meilleur collaboration entre les deux projets.
[^] # Pas de dispute
Posté par ZeroHeure . Évalué à 7.
Je l'ai recopié à quelques lignes d'ici. En voilà l'essentiel: après une discussion sur IRC, il y a une opportunité de travailler ensemble: d'un côté on bosse sur le code pour KDE4, de l'autre Apple vient de finir Tiger et prépare la suite. Il faut juste trouver un mode de coopération.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Licences
Posté par reno . Évalué à 10.
Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.
Certes les GPL/LGPL apportent la liberté de forker, liberté tres importantes et utile si le développeur original ne bosse plus dessus ou si on est en désaccord avec lui, mais forker pour forker comme Apple a fait, c'est assez méprisable..
Bah, Apple a fait souvent des bétises de ce type: un exemple au lieu d'utiliser OpenGL comme librairie graphique, ils ont utilisé leur propre API 3D, que personne n'a utilisé bien sûr: ils n'ont pas le pouvoir de Microsoft!
Résultat, ils ont du l'abandonner, en la remplaçant (finalement) par OpenGL, OpenGL qui entre temps s'est bien affaibli..
Si Apple avait utilisé OpenGL dès le départ, il est envisageable qu'OpenGL soit beaucoup plus utilisé actuellement [ bon ok, vous me direz avec des si.., c'est juste un exemple d'une des c*** d'Apple].
La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres: apres un coup comme ça, je pense qu'il y a assez peu de developpeur de KDE qui seraient interressé par porter KOffice sur MacOSX, par exemple..
[^] # Re: Licences
Posté par Guillaume POIRIER . Évalué à 10.
Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.
Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.
Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.
Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde
J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...
[^] # Re: Licences
Posté par mdlh . Évalué à 7.
[^] # Re: Licences
Posté par benoar . Évalué à 7.
Pas totalement d'accord: Apple respecte la lettre de la LGPL et publie toutes les modifications apportées, KHTML pourrait être en GPL, cela ne changerait rien!
Bah si justement, étant donné qu'ils intègrent KHTML à du code proprio (Safari), avec la GPL ils n'auraient pas pu l'utiliser. Tu va me dire qu'à ce moment là KHTML n'aurait pas été choisi et serait resté seul dans son coin, c'est vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Deux 'tites coquilles, et une vraie question
Posté par Sixel . Évalué à 5.
Coquille #2 : (2ème lien) programmeur principal_ (d'ailleurs, comment vous dites pour une femme qui programme? programmeuse, ça sonne bizzare, non?)
Vraie question : KHTML est bien un projet libre. WebCore peut donc être considéré comme un fork, chose somme toute pas vraiment rare dans le monde des LL.
Je comprends bien que c'est contraire à l'esprit du libre de pomper les connaissances des devs de KDE tant que Apple en avait besoin, et ensuite de ne faire aucun retour, mais bon, ce n'est pas non plus contraire à la licence! Et justement, grâce à ladite licence, les modifs et divers patches créés par l'équipe de WebCore sont libres eux aussi, et même s'ils ne sont pas directement implémentables dans le code de KHTML, au moins le code est diponible.
Si ça avait été une collaboration du type OOo/StarOffice (même si la situation initiale n'est pas vraiment la même), ce serait vraiment scandaleux, mais dans le cas KHTML/WebCore, on parle bien d'équipes de devs distinctes, à l'opposé de Sun qui fournit des devs pour le projet OOo.
Alors ok, c'est pas cool pour l'équipe de KHTML, surtout qu'ils font un travail super et que sur le coup, ils sont pas vraiment récompensés, et c'est vrai que Apple aurait pu se retenir de proposer l'adoption de WebCore, mais bon, y'a pas mort d'homme non plus...
mes 0.02 euros
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Sixel . Évalué à 4.
Ok, la prochaine fois, je me renseigne, KHTML est sous LGPL, donc c'est même pas gagné que l'accès aux sources de WebCore soit possible. Mais dans ce cas, les devs de KHTML peuvent encore moins se plaindre, comme dit plus haut, ils ont mal choisi la licence :-/
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par arnaudus . Évalué à 7.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Pierre Tramo (site web personnel) . Évalué à 9.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par patrick_g (site web personnel) . Évalué à 3.
Tiens une idée me vient (c'est pas tous les jours).
Imaginons la situation suivante : je suis une méchante corporation multinationale et je veux profiter tranquillement du code libre qui est produit par ces hippies de communistes de hackers....comment faire pour les entuber ?
Simple : je pompe du code GPL et je le trifouille à ma sauce pour en faire un logiciel que je vends très très cher. Quand on vient me demander de livrer le code source (obligation induite par la GPL) je fais la manoeuvre suivante : je fournis un seul _gros_ fichier txt sans indentation et sans sauts de lignes qui regroupe tous les modules et bibliothèques de mon logiciel.
C'est comme si le source complet était aligné sur une seule ligne.
Inutile de dire que ce fichier txt est, sinon complètement inutilisable, du moins _très_ difficilement exploitable par quiconque qui voudrait récupérer mes divers patchs au fil du temps.
Moralité : j'ai pompé du code GPL pour sortir mon fork à moi et j'ai respecté la lettre de la GPL tout en empêchant quasiment toute réutilisation par des tiers de ma version.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Seazor . Évalué à 4.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Security__Watch . Évalué à 2.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par domak . Évalué à 2.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
Ce qui ne me paraît guère compatible avec ton idée.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par fabien . Évalué à 3.
oui mais ton fichier txt il compile et il est sous GPL,
et ben une autre boite, le recupere le compile et le vends moins cher... et voilà, ou même le distribue gratos, et là tous les efforts de la 1ere boites pour ajouter des focntionalité ou juset obfusquer le code et ben c'est du temps de perdu.
domage pour ta demonstration ;)
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par plagiats . Évalué à -1.
bien sur si ton code est GPL et que Mark Shuttleworth (par exemple) décide de payer les 10 millions, on pourra demander le code à Mark et court-circuiter ton business.
à moins que tu sois vraiment méchant et que tu fasses payer 10 millions de dollars l'accès à la moindre modification... dans ce cas on ne pourra avoir qu'un instantané à travers Mark. :-)
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
http://www.gnu.org/licenses/gpl.html(...)
... or a charge no more than your cost of physically performing source distribution, ...
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par plagiats . Évalué à 1.
merci d'avoir rectifié.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par 태 (site web personnel) . Évalué à 1.
C'est pas tout à fait la suite de patches, mais on n'en est pas très loin.
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042(...)
et ont été annoncés sur kde-core-devel :
http://lists.kde.org/?l=kde-core-devel&m=111470451721883&w=(...)
Le problème est qu'ils sont pour la plupart impossibles à appliquer parce qu'utilisant des bouts d'ObjectiveC ou des librairies spécifiques à OS/X (voir la suite du thread sur kde-core-devel).
[^] # Re: Deux 'tites coquilles, et une vraie question
Posté par Paerro Trime . Évalué à 1.
Rappelons que dans le cadre de la LGPL, il doit y avoir un accès aux sources, pour tout le monde - pas juste pour Tintin et Milou, à partir du moment ou les binaires de la version modifiée sont distribués.
# Démagogie
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Vu sur le blog d'un dév KHTML il y a peu : http://www.kdedevelopers.org/node/view/1006(...)
In December 2004 I “ported” the CSS text-shadow property from WebCore. I put ported in quotes because the only thing ported was the code to parse the property. In the rendering Apple had created an extension to KWQ (their Qt) that used an OS X call to draw the shadow. This meant that to “port” it I had to write the shadow drawing myself.
Résumé : pour certaines fonctionnalités, WebCore utilise les bibliothèques d'OSX, qui sont loin d'être libres. Porter WebCore nécessiterait donc de réécrire énormément de fonctionnalités fournies par ces biblio. Faire cette proposition alors qu'Apple sait que KHTML n'a actuellement que de faibles resources me fait vraiment penser à un gros foutage de gueule...
[^] # Re: Démagogie
Posté par arnaudus . Évalué à 2.
De toutes manières, si l'équipe de KHTML ne veulent pas reprendre le code qu'on leur propose, c'est qu'ils estiment qu'il est moche. Par conséquent, WebCore va être un soft buggé, difficile à faire évoluer. Pas de quoi piquer une crise.
C'est juste dommage pour les dev de KHTML qui ont perdu du temps dans cette "pseudo collaboration" ; maintenant, KHTML ne va pas bénéficier deu développement d'Apple, et vice versa. La communauté des gens capables de faire des rapports de bugs corrects et de proposer des patches est du côté de KHTML, donc WebCore va y perdre au moins autant que ce qu'ils avaient gagné. C'est une histoire de stratégie d'entreprise.
Si par contre ce comportement est juste dû à quelques kékés qui n'ont rien compris au libre et qui plombent la stratégie d'Apple par flemme ou pour se faire mousser, ça va chauffer. Mais je ne crois pas qu'il s'agisse de ça.
[^] # Re: Démagogie
Posté par Infernal Quack (site web personnel) . Évalué à 6.
Ceci fait que de nombreuses personnes s'imaginent que Konqueror et Safari ont le même rendu et donc quand un truc marche sur Safari mais pas Konqueror les bugs-reports ressemblent à "TrucMuche work on Safari but not on Konqueror. How is it possible ? Please fix this quickly".
Je comprend que ça fasse raler les développeurs KHTML car l'inverse est plus rare, les utilisateurs Konqueror étant plus au courant du fait que WebCore est un fork et non le même projet comme Apple semble le faire croire.
Webcore est un fork sauvage de KHTML. Que les développeurs web le sachent et arrêtent de faire chier l'équipe KHTML avec Safari qui lave plus blanc. Apple a des moyens et l'équipe KHTML est restreinte et a peu de moyen. Les développeurs de KHTML étant en plus souvent développeurs sur d'autres parties de KDE.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Démagogie
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
> on Konqueror. How is it possible ? Please fix this quickly".
kde n'a qu'à faire comme les autres ânes de la mozilla fondation et déposer la marque khtml, il parait que ça aide à ne plus avoir ce genre de bugreport
[:kiki]
[^] # Re: Démagogie
Posté par chaperon . Évalué à -1.
Utilisez WebCore plutot que KHTML pour que vous nous débuggiez gratis le code pourri qu'on a pondu.
[^] # Re: Démagogie
Posté par Jiel (site web personnel) . Évalué à 1.
# La situation semble se détendre entre les deux parties
Posté par qdm . Évalué à 9.
L'article de CNET fait dans le sensationnalisme ronflant en arrivant 2 semaines après la bataille (By Paul Festa : comment ça j'avais deviné l'auteur avant même de cliquer sur le lien ?)
# Mise a jour ...
Posté par Mickael Marchand . Évalué à 3.
http://www.kdedevelopers.org/node/view/1046
la cooperation n'a pas encore totalement disparue apparemment
Mik
# Un mars aussi ?
Posté par ckyl . Évalué à 10.
Par exemple quand Dillon à créé Dragonfly BSD personne chez FreeBSD n'a demandé que le boulot leur tombe dans le bec. Si FreeBSD veut des choses de Dragonfly bin ils remontent leurs manches et se débrouillent comme des grands pour que ca marche chez eux.
Bien sur on peut rêver d'un monde idéal... Le monde réel c'est un ensemble de joueurs ou chacun essait de tirer au mieux son epingle du jeu. C'est un jeu d'influence, de buz, et de technique. La c'est apple donc c'est des méchants, mais au sein de tout projet c'est exactement la même chose à une échelle plus petite. Chacun s'arrange pour que ca aille dans la direction qui l'interesse.
Pour finir si on veut pas que cela puisse se produire on fait du proprio/open source.
[^] # Re: Un mars aussi ?
Posté par jojolapin4 . Évalué à 10.
le procès fait à apple ici pourrait être fait à n'importe quelle équipe de développement ayant forké un soft
c'est dingue quand même, quand une boite fait que du proprio, on le lui reproche, et à l'opposé quand elle s'investit un peu dans l'open source, elle est tout aussi critiquée.. mon avis perso est que ça décrédibilise le monde de l'open source, en le faisant passer pour pleurnicheur et éternel insatisfait, et ça c'est vraiment dommage :/
[^] # Re: Un mars aussi ?
Posté par Jonathan Loriaux . Évalué à 1.
Sinon, en effet, à part un perte de temps et de l'énervement, il n'y a pas de mal à faire un fork, mais alors il faut le faire jusqu'au bout !
[^] # Re: Un mars aussi ?
Posté par Dominique Feyer (site web personnel) . Évalué à 2.
Apple par de son côté, KHTML reste sur leur position ... pas grave, je profite du meilleure des deux mondes.
Je trouve qu'il y a quand même pas mal d'extrémisme dans ce procès Apple vs KHTML ...
[^] # Re: Un mars aussi ?
Posté par GhZaaark3 . Évalué à -4.
Qu'on ne dise pas qu'Apple contribue au libre dans ce cas, il y a une différence entre un fork libre et un fork commercial.
Ce qui m'amène à penser qu'on peut malheureusement encore filouter une licence libre visiblement.
Bref, Apple a été très malin sur ce coup, éspèrons juste que les devs libres se souviendront de l'intérêt de choisir judicieusement sa licence, cela semble être la seule morale de l'histoire. (j'suis peut-être limité cérébralement ^_^)
[mode spéculation]
Peut-être que la team de KHTML avait peur de passer pour extrêmiste en ne choisissant pas la très critiquée GPL qui est pourtant la véritable garante de notre code libre.
[retour à la réalité]
+
nb: Dire qu'il y a peu je demandais des infos sur les contribs d'apple pour le libre (car ce ne sautait pas aux yeux), maintenant j'en ai pour mon argent :o)
# Le mieux à faire...
Posté par ragoutoutou . Évalué à 8.
De toutes façons, il y a un plus grand nombre d'utilisateurs potentiels pour KDE que pour Apple, alors autant ne pas marcher dans un sentier jonché de pommes pourries.
Et si chez apple ils veulent voir webcore sous linux, qu'ils le fassent eux-mêmes...
[^] # Re: Le mieux à faire...
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: Le mieux à faire...
Posté par gallenza . Évalué à -10.
Les switchs Linux -> OS X sont bien plus nombreux qu'on ne le dit parmis les informaticiens fan de LL (même si les couches proprio de OSX font très mal à certain).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le mieux à faire...
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Le mieux à faire...
Posté par Mildred (site web personnel) . Évalué à 0.
Ou est la jolie interface chromée ? C'est le dernier argument que j'i eu pour ne pas passer à Firefox (un autre c'est que Safari c'est bien et c'est déja installé).
Et a mon avis, un thème ne change pas cela, l'interface chromée permet de déplacer la fenêtre n'importe où ou c'est chromé. Pas seulement dans la barre de titre.
Aussi, il y a trop de boutons pour certains. A quoi sert le bouton Stop a coté du bouton Recharger. On ne peux pas stopper et recharger une page en même temps.
Le gestionnaire de bookmarks de Safari est à l'interieur de la fenêtre, ce n'est pas une fenêtre séparée.
On ne peux pas redimentionner la barre d'adresse et la barre google avec Firefox.
Par contre, j'aprécie beaucoup FireFox (puisque je l'utilise), et je ne l'abandonnerais pas por Safari. Manue Adblock, WebDeveloper et des choses comme l'inspecteur DOM qui sont bien utiles.
J'ai juste résumé des arguments qui pouvaient être utilisés.
[^] # Re: Le mieux à faire...
Posté par ZeroHeure . Évalué à 2.
Bien vu!
A soumettre aux devs de Mozilla, Firefox, Konqueror, ...
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Le mieux à faire...
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
[^] # Re: Le mieux à faire...
Posté par He_is_me . Évalué à 1.
Moi je trouve ça trèèèèèès pratique.
[^] # Re: Le mieux à faire...
Posté par ArBaDaCarBa . Évalué à 2.
[^] # Re: Le mieux à faire...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Je suppose que c'est le cas sur Safari.
[^] # Re: Le mieux à faire...
Posté par Juke (site web personnel) . Évalué à 2.
L'utilisateur avancé quant à lui appuiera sur stopper/recharger succesivement et rapidement ou utilisera le raccourci clavier (mais je ne vois toujours pas l'interet)
[^] # Re: Le mieux à faire...
Posté par ragoutoutou . Évalué à 3.
Désolé, mais non, il ne faut pas penser à ce dont l'utilisateur l'ambda a besoin, il faut lui demander...
Il arrive fréquemment que des pages ne terminent pas d'être transférées, mais le browser reste en attente. Avec un bouton reload, il est plus rapide et plus intuitif de faire redémarrer le téléchargement de la page qu'en devant faire un stop->reload. Avec un bouton à deux états (stop et reload), l'utilisateur peut se méprendre sur l'état du bouton et faire un stop d'une page en train de charger ou un reload d'une page chargée alors qu'il n'en a pas besoin, pour peu que l'état du bouton change pendant que l'utilisateur veuille utiliser son état précédent.
[^] # Re: Le mieux à faire...
Posté par Antoine . Évalué à 5.
Bien vu!
A soumettre aux devs de Mozilla, Firefox, Konqueror, ...
Non, mal vu. Un bouton qui change de fonction selon le contexte est une horreur ergonomique.
[^] # Re: Le mieux à faire...
Posté par tgl . Évalué à 2.
Mais ceci dit, les HIG de Gnome par exemple sont d'accord avec toi. Enfin, c'est pas parfaitement explicite, mais est cité le cas des boutons Play et Pause dans les toolbars des lecteurs multimédia, qui est très similaire, et la recommandation est : « Do not change Play to Pause while the clip is playing. »
http://developer.gnome.org/projects/gup/hig/2.0/toolbars.html(...)
Une explication du pourquoi ?
[^] # Re: Le mieux à faire...
Posté par Juke (site web personnel) . Évalué à 3.
Le bouton de la lumiere change de fonction selon le contexte.
Lumière eteinte : Le bouton sert à allumer.
Lumière allumée : Le bouton sert à éteindre.
[^] # Re: Le mieux à faire...
Posté par Juke (site web personnel) . Évalué à 2.
C'est vrai je n'avais jamais fait attention.
Quelqu'un voit une utilité à ce truc ?
Par contre un truc aussi qui ne sert à rien je trouve c'est le bouton ->OK à coté de la barre d'adresse. Quand on tape une url, on la tape au clavier, je ne vois pas l'interet d'attraper la souris et de cliquer sur ->OK.
[^] # Re: Le mieux à faire...
Posté par ZeroHeure . Évalué à 4.
Beaucoup de gens ne savent pas quoi faire une fois l'URL tapée. C'est facilement compréhensible: pourquoi faire "entrée", où est la logique? aucune interface graphique ne montre de lien entre cette touches et les différentes versions des boutons "valider", "ok", "envoyer" etc.
Quand je m'en sers devant des stagiaires, j'ai l'impression de leur révéler un nouveau raccourci clavier...
Cela dit, s'il n'y avait pas de bouton "ok" sur IE, la plupart des utilisateurs finiraient par comprendre.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Le mieux à faire...
Posté par Tonton Benoit . Évalué à 2.
[^] # Re: Le mieux à faire...
Posté par Erwan . Évalué à 2.
[^] # Re: Le mieux à faire...
Posté par He_is_me . Évalué à 1.
[^] # Re: Le mieux à faire...
Posté par He_is_me . Évalué à 1.
Si, grace à cette extension : http://extensions.geckozone.org/ResizeSearchBox/(...)
[^] # Re: Le mieux à faire...
Posté par 태 (site web personnel) . Évalué à 2.
Il est plus beau (il s'integre parfaitement au bureau osx alors qu'au mieux firefox melange brushed metal et pas brushed metal)
Il est plus rapide
Il supporte mieux les css
Pour le premier point, il y a camino, mais franchement, la seule raison que j'y verrais c'est d'etre allergique au proprietaire, et c'est pas coherent avec l'utilisation d'osx.
Sinon, il y a opera qui est pas mal : au niveau css, ca doit etre sensiblement equivalent, mais il a ses pubs, et il a des lenteurs dans l'interface.
Donc vraiment, si c'est pour le plaisir d'utiliser un navigateur libre, je conseillerai shiirad (belle interface, utilise le meme moteur de rendu que safari)
[^] # Re: Le mieux à faire...
Posté par dawar (site web personnel) . Évalué à 2.
Par contre je connais pas shiirad, je vais voir ca de ce pas : http://hmdt-web.net/shiira/index-e.html(...) ?
Quand a khtml, ben oui il faut pas croire Apple (ni beaucoup de socétés) quand elles disent "on est gentil tout plein on va vous aider, vive le libre"
[^] # Re: Le mieux à faire...
Posté par Sam Hocevar (site web personnel) . Évalué à 0.
[^] # Re: Le mieux à faire...
Posté par ragoutoutou . Évalué à 5.
Pour le reste, je suis déjà sous gnome mais je ne compte pas faire de querelle de clocher entre gnome et kde. KDE est un projet formidable, Gnome aussi. L'important c'est que ces projets restent des projets servant à leur communauté et non à une entreprise extérieure s'amusant à déposer des peaux de bananes...
[^] # Re: Le mieux à faire...
Posté par William Steve Applegate (site web personnel) . Évalué à 5.
Envoyé depuis mon PDP 11/70
[^] # Re: Le mieux à faire...
Posté par Cali_Mero . Évalué à 4.
Il est clair que ce n'est pas le but d'Apple. Je pense plutôt que cette proposition va dans le sens de leur conception de la "coopération" entre projets libres.
Apple se gausse d'avoir réussi à passer l'Acid2, et dans un élan de bonté ils proposent aux développeurs de KHTML, qui n'est pas au même niveau sur ce point, de reprendre les fruits de leur boulot partiellement ou complètement. C'est à la fois de la pub et une volonté d'entraide telle qu'ils peuvent la concevoir. Que les dévs de KHTML acceptent ou pas, c'est une autre histoire, il auront sûrement de bonnes raisons de ne pas le faire mais reste à voir objectivement si ca peut être intéressant de partir sur une base webcore ? En dehors du strict respect des standards et de l'Acid2, où en sont respectivement les deux projets ?
L'intérêt immédiat, si cette proposition aboutissait, serait la compatibilité qui redeviendrait bonne entre les moteurs WebCore (qui s'identifie, comme certains le soulignent, comme khtml) et khtml. Ce n'est pas anodin, comme avantage... Aussi bien konqueror que Safari sont promis à un bel avenir et il est dommage que les développeurs web ne puissent en tirer pleinement profit à cause de leurs différences pas clairement identifiables.
Et puis, Apple aurait très bien pu ne rien proposer du tout...
[^] # Re: Le mieux à faire...
Posté par ragoutoutou . Évalué à 5.
Oui, proposer, c'est bien, mais il faut voir les conditions, les licences.
Si tu proposes un sandwich aux saucisson pur porc à un rabbin, je ne pense pas qu'il voie ça comme de la générosité... et si tu sais pertinamment que les rabins ne mangent pas de porc, on ne peut pas te qualifier non-plus de généreux. (maintenant, certains dirons "il est con, ce rabin, un sandwich au saucisson pur porc, ça ne se refuse pas", mais là on entre dans un débat de principes)
[^] # Re: Le mieux à faire...
Posté par Mildred (site web personnel) . Évalué à -2.
# traque aux bugs
Posté par Pooly (site web personnel) . Évalué à 10.
lire entre les lignes : on a besoin d'un plus grand nombre de gens pour chasser nos bugs, si vous remplacer KHTML par WebCode notre controle qualité sera amélioré.
[^] # Re: traque aux bugs
Posté par fasthm . Évalué à 2.
un an de patch gorets, ça finit toujours par se payer.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# Apple is near microsoft
Posté par johnf . Évalué à 5.
Si apple avait eu le succés de microsoft, rien ne dis que nous ne detesterions pas tous Apple aujourd''hui. C'est pas loin d'être plus propriétaire que Microsoft par moment....
[^] # Re: Apple is near microsoft
Posté par bz31 . Évalué à 4.
Je suis content d'avoir choisi linux (une debian unstable) pour mon iBook G4. J'ai installé le dual boot, mais finalement je ne reboot presque plus sous os x. Je vais virer complètement os x quand j'aurais trouvé une solution wifi avec support wpa.
Je ne suis pas un inconditionnel de logiciels libres, mais comme beaucoup de lecteurs de DLFP, j'essaie d'utiliser le maximum de logiciels libres.
[^] # Re: Apple is near microsoft but ...
Posté par Mildred (site web personnel) . Évalué à 1.
En fait, ils y on un interêt: ils sont minoritaires sur le marchés des ordinateurs personnels, alors ...
Mais on a pas mal de trucs de chez eux, il me semble ... Par exemple Wifi, USB, FireWire ou ZeroConf (=rendezvous=bonjour)
Peut être que certaines de ces technologies ne venaient pas de chez eux directement ... mais il les ont intégrés très en avence.
Il me semble qu'on trouve encore beaucoup de PC sans pour firewire alors que c'est la norme chez Apple. C'est vrai, il n'y a pas beaucoup de périphériques compatibles (je n'en ai pas alors que j'ai un port FireWire), mais ca va venir.
[^] # Re: Apple is near microsoft but ...
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Non.
Si dans un an les sites pullulent avec ce truc on se retrouvera avec les mêmes merdes qu'à l'époque des "layer" de Netscape. Heureusement Safari n'ayant pas le monopole ça n'arrivera pas.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Apple is near microsoft but ...
Posté par Blairux . Évalué à 4.
Il y a peut-être une explication très simple : la licence Firewire n'est pas gratuite (à la différence de celle de l'USB), elle est vendue – chère parraît-il – par Apple. Partant de là, il est logique que les fabricants de matèriel ne l'intègrent que sur des machines plustôt haut de gamme afin de ne pas plomber le prix des PC courants.
Côté photo et vidéo, beaucoup de fabricants équipent aujourd'hui leurs camscope en USB2, seuls restent (généralement) en Firewire les appareils photo pro genre Canon EOS 1D/Ds ou Nilon D1/D2.
De plus, lorsque le port Firewire est présent sur un portable, c'est souvent en version 4 broches (appelé iLink chez Sony) et donc ne permettant pas l'alimentation d'un périphérique tel qu'un disque (les petits qui tiennent dans la poche :o), à la différence de l'USB2.
Dans ce contexte, l'intérêt du Firewire 400 devient donc de plus en plus faible, tout le monde n'a pas besoin d'une pile de LaCie pour archiver son boulot ou ses photos, vidéos, mp3… ce qui explique peut-être pourquoi les fabricants de PC ne forcent pas la main aux clients en vendant un port dont bien peu on besoin.
# Utilisation de Safari ?
Posté par Wawet76 . Évalué à 2.
Je ne connais pas beaucoup de personnes sous Mac-OS, mais elles utilisent toute soit IE soit Firefox...
[^] # Re: Utilisation de Safari ?
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
L'enjeux pour Apple n'est pas d'avoir "Le navigateur". Mais d'en proposer un par défaut. Les macquistes ont toujours choisie leur navigateur. Sous Mac OS 9 IE et Netscape étaient livrés par défaut. Le succés de FireFox sous Mac est bien moins surprennant que son succés sous windows
Ceci dit Safari est un bon navigateur. Bien plus modèrne que IE
[^] # Re: Utilisation de Safari ?
Posté par pierthi . Évalué à 3.
Je pense que là où Safari (et KHTML aussi d'ailleurs) enfonce FireFox (enfin Gecko), c'est en vitesse de rendu. Utilisez des div en "position: fixed" ou de la transparence PNG avec un "background-position: fixed" : c'est d'une lenteur exaspérante avec FireFox. Sur les G4 500 du parc, c'est très trés pénible, Safari en comparaison est 2 à 3 fois plus rapide.
Et puis, j'attends encore le jour où Gecko cessera d'utiliser son système de widget "fait maison", qui est plus moche que Motif et Tk réuni (encore une raison de préférer KHTML ou Safari).
[^] # Re: Utilisation de Safari ?
Posté par pierthi . Évalué à 1.
Oula, avant que ça parte en troll .... j'aurais du préciser le plus gros du boulot à quand même été fait par l'équipe de KHTML.
[^] # Re: Utilisation de Safari ?
Posté par Boa Treize (site web personnel) . Évalué à 7.
À l'époque, ça marchait pas bien sous Konqueror (sa faute ou la mienne, je sais plus), j'avais pas trop examiné le problème, mis au rayon du « Konqueror ne respecte pas encore assez bien les standards ».
Récemment, j'ai refait un essai, j'ai été bluffé : ça scrolle très fluide sous Konqueror, Mozilla ressemble à une grosse brouette à roue carrée en comparaison !
[^] # Re: Utilisation de Safari ?
Posté par William Steve Applegate (site web personnel) . Évalué à 4.
Ah ben là, je ne peux qu'être d'accord, ça fait des lustres que je répète que Konqi est plus rapide lorsqu'on vient me vanter la vitesse de Faïrefosque. Mais jusqu'à pas si longtemps, je n'avais que mon impression subjective. Maintenant, il y a un monsieur qui a fait des tests (j'avais vu ça sur /. il y a quelques temps) et ça donne ceci [http://www.howtocreate.co.uk/browserSpeed.html#linspeed(...)].
En resumé : Konqi est près de deux fois plus rapide pour le rendu CSS, mais en revanche c'est une vraie daube pour le scripting (et je confirme : dès qu'une page contient du bon gros Javascript, comme la barre DLFP sur une dépêche avec plein de commentaires, Konqi s'effondre et me présente l'infâme message « un script sur cette page entraîne le gel de kHTML… »).
Envoyé depuis mon PDP 11/70
[^] # Re: Utilisation de Safari ?
Posté par Zorro (site web personnel) . Évalué à 1.
[^] # Re: Utilisation de Safari ?
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Hélas, à ma connaissance Gecko insiste pour utiliser son jeu de widgets multi-plateformes, indépendamment de l'utilisation de XUL pour l'interface ou non. Du coup, si la page Web a le moindre élément de formulaire, son interface rompt complètement avec l'environnement graphique local. Un exemple parmi d'autres à [http://galeon.sourceforge.net/graphics/shots/fonts.png(...)] (note la gueule des contrôles en haut de la page).
Envoyé depuis mon PDP 11/70
[^] # Re: Utilisation de Safari ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
Le probleme, c'est surtout que gecko fait le choix de laisser les elements de formulaires etre stylés via CSS completement, chose impossible a faire avec les widgets natifs, qui ne permettent pas suffisamment de liberté niveau stylage.
Safari fait le pari opposé, et ne laisse que peu de possibilités de stylage, justement pour etre cohérent avec l'environnement.
En bref, on a 2 écoles différentes...
[^] # Re: Utilisation de Safari ?
Posté par ... a little wood elfe . Évalué à 6.
Un exemple : Mac OS X propose dans ses réglages réseaux de paramétrer le proxy à employer et Safari utilise le dit réglage ensuite. Donc lorsqu'on déplace son portable d'un lieu à un autre il suffit de changer de configuration active pour que Safari sache s'il doit ou pas utiliser un proxy et lequel. A l'inverse avec FireFox après avoir changé de configuration réseau active on doit encore changer le réglage du proxy dans FireFox...
Autre exemple : la gestion des cookies, Safari les stocke dans un endroit bien défini du système. Si on s'identifie sur un site via un cookie en utilisant Safari, toute application Cocoa désirant faire un accès au site en question va être automatiquement identifiée également.
----
Sinon je ne pense pas que KDE ait intérêt à abandonner khtml, en revanche GNUstep aurait sans doute plus l'utilité d'utiliser WebCore.
[^] # Re: Utilisation de Safari ?
Posté par Antoine . Évalué à 2.
[^] # Re: Utilisation de Safari ?
Posté par wismerhill . Évalué à 3.
# Webcore/gtk
Posté par foulmetal canette (site web personnel) . Évalué à 9.
http://gnomedesktop.org/node/2014?PHPSESSID=af47f5f584ce24abb62cf9f(...)
Les gars de Nokia (!) ont porté relativement récemment (fin octobre 2004) le moteur webcore de Apple pour gtk.
Euh tiens, dans la page des liens du site, il y a d'autres projets qui basé sur webcore/gtk : atlantis et même un hack pour faire marcher galeon avec webcore... Étonnant non ?
* gtk-webcore : http://gtk-webcore.sourceforge.net(...)
* atlantis : http://www.akcaagac.com/index_atlantis.html(...)
* hack galeon : http://sourceforge.net/mailarchive/forum.php?thread_id=5818624&(...)
[^] # Re: Webcore/gtk
Posté par Ph Husson (site web personnel) . Évalué à 1.
Plus ou moins
Plus quand on voit ce que donne gnome "vs" kde
Moins en sachant que sous unix tout est modulaire (enfin tout les modules font une chose et le font bien)mais aussi d'avoir le choix
donc ici on a le choix du module
Enfin en tout cas c'est une bonne initiative :)
(Bon par contre à packager avec des vrais descs c'est amusant)
# michel
Posté par - - . Évalué à 10.
-------
cela fait depuis le début qu'apple a maintenu sa propre branche de khtml nommée Webcore
c'est logique, parce qu'apple a viré toute reference à QT ou autre pour seulement Quartz, et toutes les technologies propres à osx
bien des fonctions graphiques utilisées dans le rendu de Webcore sont écrites dans d'autres part d'osx
elles existent pas sous linux, en tout cas pas dans kde
il ne suffit pas d'adapter le code de webcore pour faire identique dans konqueror. il s'agit parfois de réécrire des choses équivalents à Quartz, à quicktime etc
Safari est pas simplement "webcore + une interface toute conne".
si safari est meilleur que Firefox c'est dans l'intégration avec le reste de l'os et cela va très loin
l'exemple des "cookies" donnée plus haut est incomplet
Safari (et toute application native à osx) utilise le trousseau de clé intégré à osx pour stocker les identifications et mot de passe . bilan -> quand vous avez demandé à safari de mémoriser vos mots de passe d'un site web , toute vos applications internet peuvent utiliser ces informations pour aller lire le site.
c'est très pratique, c'est l'une des multiples intégrations entre applications natives d'osx. il y a des centaines d'exemples similaires (les services, le inputmanager, le dictionnaire, etc )
firefox comme par hasard ne profite d'AUCUNE de ces technologies. Ni même le correcteur orthographique intégré, ni rien.
Safari est meilleur que firefox pour l'ensemble du confort qu'il hérite naturellement par l'usage de Cocoa.
-------
Apple a jamais développé d'équivalent de direct 3d ou Opengl. apple a utilisé opengl depuis que ca leur était utile et c'est devenu totalement dépendant d'opengl dès osx 10.0
(os x 10.0 ne faisait pas du "extrem quartz" mais c'était le standard utilisé pour faire des jeux en 3D sur mac, pas de direct3D ou autre )
il y a quicktime3D qui a rien à voir avec le fait de faire des polygones et des vertex-bidule sur carte nvidia ou ati. apple a pas cherché à faire sans opengl , à la Microsoft.
----------
apple étant une société (américaine de sucroit) elle est forcément maléfique comme microsoft et vient de l'enfer
mais que cela soit avec GCC ou KHTML ils ont simplement respecté la licence gpl
et on permis à des morceaux entier du systeme d'être accessible au passionné et aux développeur
qu'est ce que je m'en fiche si Webcore est devenu indépendant de KHTML ! ca reste quand même une très bonne lib qui est LGPL
cela a permis à des développeurs comme de Omnigroup de modifier webcore, de l'adapter à leur usage pour faire un logiciel qui va plus loin encore que ce qui fut prévu pour Safari
si webcore n'était pas un logiciel libre (genre moteur html de ie) ,ce qu'à fait omnigroup aurait été impossible.
il faut bien réaliser que apple a forké des projets pour non seulement les adapter le plus possible à un système qui n'est PAS linux ET à des technologies qui leur sont propres
faire un arbre commun revient à intégrer 2 branches totalement incompatible de toute façon.
redhat ou novell ou suse n'ont pas du tout les même considérations que Apple
Apple est dans une situation similaire à Sun si on veut.
---------------
apple fait exactement ce que demande la licence.
si vous aviez imaginé des "devoirs" fantaisistes du genre "faut documenter, faut écrire un bo changelog, faut boire du thé avec les autres développeurs" ben figurez vous que Stallman a pas du tout voulu obliger cela en écrivant cette licence.
-----
et dans le genre Apple est un Gros méchant de l'enfer. je rappelle que l'entreprise a plusieurs fois changé la licence du noyau d'osx pour satisfaire la FSF. rien n'obligeait Apple à faire cela à part pour se donner une bonne image. cela me va très bien.
-------------
une bonne fois pour toute WEBCORE n'est PAS khtml avec des correctifs pour faire "plus compatible"
c'est KHTML qui fut Adapté, nettoyé et totalement réorganisé pour avoir un moteur html qui utilise TOUTES les technologies NATIVES (et pas disponible pour autre chose) d'OS X
il était naturel que très vite, les modifs d'apple soient totalement impossibles à remettre dans le khtml sans un travail délirant. (l'exemple bien expliqué des css-shadow est un appel au sous système graphique d'osx qui fait _tout le job_ . y a rien d'équivalent dans KDE (non et même pas Cairo ou Pango ) .
bref ,FIN de polémique. y a que des attitudes naturelles la. et maintenant des gens de kde essaient de calmer la machine médiatique et la masse des forum qui sont partis dans le pure délire à la X-files.
[^] # Re: michel
Posté par Ph Husson (site web personnel) . Évalué à 2.
si safari est meilleur que Firefox c'est dans l'intégration avec le reste de l'os et cela va très loin
l'exemple des "cookies" donnée plus haut est incomplet
Safari (et toute application native à osx) utilise le trousseau de clé intégré à osx pour stocker les identifications et mot de passe . bilan -> quand vous avez demandé à safari de mémoriser vos mots de passe d'un site web , toute vos applications internet peuvent utiliser ces informations pour aller lire le site.
c'est très pratique, c'est l'une des multiples intégrations entre applications natives d'osx. il y a des centaines d'exemples similaires (les services, le inputmanager, le dictionnaire, etc )
firefox comme par hasard ne profite d'AUCUNE de ces technologies. Ni même le correcteur orthographique intégré, ni rien.
Safari est meilleur que firefox pour l'ensemble du confort qu'il hérite naturellement par l'usage de Cocoa.
tout a fait d'accord mais j'ai un petit commentaire
Ce que tu raconte ca ressemble très fortement à konqueror sur KDE :p
Donc en suivant ton raisonement konqueror est mieux que firefox
Oui bon c'est vrai donc c'est un bon syllogisme vrai :)
qu'est ce que je m'en fiche si Webcore est devenu indépendant de KHTML ! ca reste quand même une très bonne lib qui est LGPL
indépendant.....
C'est quand même un fork
Ils ne sont plus compatible en grande partie mais y a quand meme certaines (petites?) parties qu'on peut échanger
et dans le genre Apple est un Gros méchant de l'enfer. je rappelle que l'entreprise a plusieurs fois changé la licence du noyau d'osx pour satisfaire la FSF. rien n'obligeait Apple à faire cela à part pour se donner une bonne image. cela me va très bien.
toutafait
bref ,FIN de polémique. y a que des attitudes naturelles la. et maintenant des gens de kde essaient de calmer la machine médiatique et la masse des forum qui sont partis dans le pure délire à la X-files.
He je tiens à mes trolls!
[^] # Re: michel
Posté par qdm . Évalué à 2.
[^] # Re: michel
Posté par Mildred (site web personnel) . Évalué à 1.
et ca, c'est très très mal ...
Par contre, je suis actuellement en recherche de navigateur web mieux intégré au système, moins lent et avec quelques fonctionnalités en plus (correcteur ortho sur konqueror ?) ...
Cepandant, konqueror ne me convient pas car on ne peux pas le personnaliser facilement (sans personnaliser en même temps le gestionnaire de fichiers) ...
Existe-t-il un navigateur utilisant webcore ou khtml qui ne soit pas konqueror mais propose tout de même psa mal de fonctionnalités ?
-----
Sinon, j'espère que cela mènera a un rapprochement de webcore et khtml, ce serait bien pour le respect des standards et pour tout le monde ...
peut être pouraient-ils travailler ensemble ... Apple faisant des patchs rapides pour les choses urgentes et KHTML travaillant en parallèle a coté avec l'aide d'Apple...
[^] # Re: michel
Posté par qdm . Évalué à 4.
[^] # Re: michel
Posté par eddycap . Évalué à 5.
Si : QuickDraw 3D. Il existait meme des cartes d'accélerations dédiées.
Il existed'ailleurs un projet qui implémente QuickDraw 3D au dessus d'OpenGL :
http://www.quesa.org/
# Santa Barbara
Posté par Beretta_Vexee . Évalué à 5.
Le Lead Dev de FireFox s'en rentre dans la danse, il désapprouve le comportement de l'équipe de KDE.
Il annonce en substance que WebCore est largement supérieur a KDE, et que Apple avait tous a fait le droit de faire le minimum. Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps.
A quand le prochain épisode ? Manque plus que Opera et IE.
[^] # Re: Santa Barbara
Posté par Ph Husson (site web personnel) . Évalué à 0.
Ouuuueeeeeeeeeeecccccccchhhhhhhhhhhhh
Il annonce en substance que WebCore est largement supérieur a KDE, et que Apple avait tous a fait le droit de faire le minimum.
s/kde/khtml/
A quand le prochain épisode ? Manque plus que Opera et IE.
Et links?
et dillo?
(pourquoi penser au proprio des le début?)
[^] # Re: Santa Barbara
Posté par Beretta_Vexee . Évalué à 3.
Dillo, il est reservé pour le troll sur GTK2 vs Qt vs un bibliothéque quelqu'on que.
Il restait plus que du proprio.
[^] # Re: Santa Barbara
Posté par Infernal Quack (site web personnel) . Évalué à 10.
Il est bien sympa Ben en critiquant l'équipe de KDE, en disant que Safari est
largement meilleur que Konqueror et en disant que Apple a respecté la licence
donc qu'ils n'ont rien à dire.
Si j'ai bien suivi les dernières nouvelles, la Fondation Mozilla a posé des
restrictions sur l'utilisation des mots Firefox et Mozilla. Or Apple utilise
toujours "khtml" pour son fork de KHTML ce qui a entraîné et entraîne
toujours des problèmes.
Premièrement, quand Apple a annoncé sa sortie de Safari en disant qu'il était
basé sur KHTML il n'a pas suffisament précisé qu'il avait fait un fork de
KHTML. Donc beaucoup de développeurs et de site-webs on considéré que tester
un site sur Safari suffisait et que ça roulerait pour Konqueror. Des sites
qui avaient fait des comparatifs des propriétés reconnues par les différents
navigateurs ont complétement fait disparaitre toute allusion à Konqueror en
précisant de se référer à Safari. Bref Konqueror n'existait pas beaucoup mais
la pub d'Apple pour son "Safari basé sur KHTML" a tué toutes références à
Konqueror. Même Tristan ne le cite jamais sur son Standblog :)
Ca a aussi entrainé de nombreux mécontentements d'utilisateurs ou
développeurs-webs venu raler auprès de l'équipe KDE (via mail, bugzilla,...)
pour dire "Ca marche avec Safari, qu'est ce que vous foutez ? Alos vous
appliquer le patch quand ?". Ils pensent que Apple fournit des patchs à
l'équipe KDE ce qui n'est pas le cas. A chaque version de Safari tout le
source est mis à disposition. Les développeurs KDE doivent se taper le source
pour voir ce qu'il y a de nouveaux. Et quand ils y arrivent ils tombent sur
de l'Objective C, l'utilisation de couches native de Mac OS X.,.... ce qui
est normal mais ça n'aide pas l'application des patchs que les utilisateurs
attendent en ralant.
Apple a accès au modification du code de KHTML et aux mailing-list de KDE.
L'équipe de KDE a accès à des tarballs dès qu'une version de Safari est
disponible.
L'équipe KDE a le droits aux gens qui ralent parce qu'ils veulent la même
chose que Safari.
Apple n'a aucune plainte d'utilisateurs leur demandant d'implémenter les
choses que Konqueror a mais pas Safari (il y en a peu mais il y en a).
Bref la coopération ne va que dans un sens.
Qui plus est, Webcore s'identifie comme KHTML et les propriétés CSS
spécifiques à Webcore commencent par -khtml-... ce qui fout la grouille.
Apple aurait dû forker intégralement en utilisant -webcore-...
Et je rajoute suite à "Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps" :
L'équipe qui travaille sur KHTML travaille aussi sur les librairies KDE et sur Koffice. Contrairement à l'équipe Mozilla ou Safari, ils ne développent pas uniquement pour le navigateur et son en effectif beaucoup plus réduit. Et malgré ça Konqueror avance à grand pas. Ils ont déjà intégré les modifs pour passer une partie du test Acid2 ; Konqui 3.4 supporte la propriété text-shadow et les compteurs CSS ; il supporte aussi le SVG animé. Et pour tout ça Mozilla ne le fait pas encore.
Ben n'a pas totalement tord mais je le trouve insultant vis à vis de l'équipe KDE.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# Petit résume en 18 points
Posté par Mathieu Pillard (site web personnel) . Évalué à 9.
http://www.kdedevelopers.org/node/view/1049(...)
Ca a le mérite de clarifier un peu le bordel ambiant, et peut etre d'eviter que tout le monde se tape dessus sans comprendre...
# apple à la traine
Posté par B16F4RV4RD1N . Évalué à 3.
J'utilise firefox sinon (avec wmaker par ex. si je ne veux pas charger mon système)
Sur mon ibook j'utilise Safari qui est plus réactif que Firefox ou Camino (latence pour changer d'onglet par ex.)
Je pense que les dev. d'Apple ont fait du bon boulot avec Safari, seulement apparemment c'était surtout un coup marketing leur "collaboration avec l'open source". On le voit avec leur support des applications x11 qui traîne la patte, le support des systèmes de fichiers linux complètement inexistant (ext3, reiserfs) il parait même que le module libre (ext2fsx) pour monter des partitions ext3 sous osx ne fonctionne plus avec le dernier mac os x Tiger (apple doit ne rien en avoir à faire que des utilisateurs mac aient un double boot).
C'est dommage car gnu / linux j'y crois, apple j'y crois aussi, je pense qu'en collaborant dans les 2 sens il y avait moyen de faire de superbes choses. L'évolution de mac os x faisant suite à NEXTstep s'est très bien faite, en gardant vraiment la philosophie de next. Mais avec les ipoderies qui montent à la tête d'apple, je crois qu'ils perdent un peu de la philosophie next, et que cela entrave un peu leur collaboration avec le libre.
Comme a dit justement qqu'un, il faut laisser le temps à Apple de peut-être s'y faire, on verra ce que cela donnera dans le futur.
Je n'utilise pas bpc KDE, mais j'espère que ce projet avec khtml continuera loin, c'est bien d'avoir une alternative à gecko !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Et finalement...
Posté par François Becker (site web personnel) . Évalué à 1.
http://www.kdedevelopers.org/node/view/1129(...)
... "Konqueror now passes Acid2"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.