Quel intérêt ? OpenOffice sous Mac utilisera Cocoa ? (je crains qu'il n'utilise Carbon...).
Bon en fait actuellement OOo sous Mac ne tourne pas sous Aqua mais sous X11 (avec XDarwin) ... ils prévoient un éventuel port pour Cocoa (mais j'imagine que c'est pas demain la veille !)
Oui d'ailleurs, ou ca en est cette histoire d'ObjC++? On peut esperer l'integration dans 2 mois, 6 mois, 1 an, plus ?
Espérons pour les prochaines versions de gcc ...
Et le jour ou il sera supporte, est-ce que le port sera une operation difficile?
Le jour ou ce sera supporté, normalement le port devrait être assez facile -- du moins autant que porter un logiciel cocoa sous gnustep.
Les developpeurs de Chimera tiennent ils compte de ce futur port dans leur politique de developpement?
Ca m'étonnerait.
Meme chose pour pour le futur OpenOffice pour MacOSX...
Quel intérêt ? OpenOffice sous Mac utilisera Cocoa ? (je crains qu'il n'utilise Carbon...).
Parce que si la futur politique d'Apple est de continuer a developper un systeme utilisant massivement des outils libres/open-sources, GNUstep pourrait commencer a largement en profiter.
Bah, Apple est pas très chaud quand même dans sa collaboration avec l'open source... On les sent encore frileux. Mais bon, on ne sait jamais, par exemple ils jouent parfaitement le jeux à priori avec khtml.
Maintenant, je pense que dans un premier temps ce sont les utilisateurs Mac qui profiterons peut être de GNUstep, vu qu'assez souvent un des objectifs est de porter sous Mac également les logiciels... on verra.
(Enfin bref t'auras compris que je reve deja d'un Chimera, KHTML et autre OpenOffice pour GNUstep... Mais cela est il envisabeable dans la pratique?)
Oui j'avais vaguement compris :) KHTML me parait une voie plus agréable que Chimera, mais c'est un avis personnel... OpenOffice c'est franchement pas mon style de logiciel (j'irais même jusqu'à dire que ça va à l'encontre de l'idée que je me fait d'une application GNUstep : c'est lourd et monolithique, du tout-en-un)
si je veux t'envoyer un mail un peu formaté je doit utiliser une poingnée d'outils pour l'éditer puis le convertir en ps/pdf/... puis le mettre en pièce jointe.
Ca serait stupide. Maintenant, envoyer un CV en HTML, bof. Le HTML permet de transmettre l'information, mais n'apporte aucune garantie quant à sa représentation. Le PDF est idéal pour ça : ce que le type verra sur son écran ou s'il imprime le CV est exactement ce qui a été prévu, et franchement pour un CV on essaie en général de soigner la présentation. Joindre un CV en HTML, *au cas ou*, pourquoi pas, mais le PDF me semble franchement mieux adapté.
Bon, explique-moi l'interêt d'avoir d'un coté un mini-HTML pour le body, et de l'autre HTML pour les attachements, sachant que lorsque tu cliques sur un attachement tu veux qu'il s'affiche directement dans le mailer ?
D'une part, en parlant de tableaux, je voyais plus le côté tableur, donc pas vraiment du html mais un document kspread ou gnumeric par exemple. Donc non, je ne voulais pas forcèment qu'il s'affiche directement dans le mailer.
Tu ne vas quand même pas me dire qu'il faudrait que les gens sauvent l'attachement et sortent leur browser pour le lire ensuite ? Allez, tu vas bien accepter que le browser soit lancé directement dans le mailer, hein ? Bon, c'est gentil.
Pourquoi sauver et sortir le browser ? cliquer dessus pour lancer le viewer associé au type mime est trop compliqué ?
Et maintenant, redis-moi à quoi sert ton mini-HTML, à part offrir une mauvaise solution à un problème déjà parfaitement résolu, et faire perdre un temps pas possible à tout le monde pour le definir, l'implementer, etc... ?
Sauf que je n'ai *jamais* parlé de foutre tout dans le mail et de tout visualiser dedans ... la plupart du temps (ie, pour autre chose que des images), il vaut mieux ouvrir le fichier attaché dans le viewer qui va bien -- au moins c'est prévu pour et tu as la place de voir ce qui t'intéresse. Une image c'est différent je pense, tout simplement parce que tu peux la retailler si besoin sans qu'elle perde tout sens (et de toute façon tu peux toujours l'ouvrir dans un viewer). Mais tout en inline, avec des tailles pas forcément suffisantes pour bien voir ton document attaché, bof.
Maintenant c'est juste mon avis, je ne force personne hein.
Oh non, pitié, pas de standards périmés ou de sous-standards !
Pourquoi ? si je parle de sous ensemble, c'est parce que mis à part ces quelques tags que j'ai cité, je ne vois pas trop d'autres trucs vraiment utiles, *pour le mail*.
Donc n'appelons pas ça du HTML (ça n'en est pas), mais, allez, XMaiL par exemple... ;)
Ca permettrait un parsing facile des mails pour les logiciels (soit pour virer les balises, soit pour les interpréter s'ils peuvent), avec surtout un rendu très simple à faire... (et léger). Pour le mail on a pas vraiment besoin d'implémenter HTML 4 + CSS !!! L'introduction de ces quelques balises permettrait un meilleur affichage des mails (mieux en tout que ce qu'on fait, cad soit rien, soit on essaye de deviner en choppant les url, les _toto_ et autres /pipo/ ...) sans alourdir plus que ça le mail ... et on aurait un affichage certain d'être propre...
je suis même pas sûr que les tableaux soient utiles (un tableau travaillé serait plutôt un attachement, et à l'extrême encourageraient les gens à faire des trucs qui seraient mieux en attachement directement dans le mail... et puis les tableaux, c'est chiant à coder :-P). Par contre des balises quote pour les niveaux de citations seraient pratiques :)
S'en tenir à ces quelques balises suffiraient pour les besoins du mail, sans complexifier beaucoup la conception de clients mail, et sans faire intervenir des problèmes de sécurité.
Au pire acceptons une norme minime pour mettre en gras, italique et souligné mais c'est amplement suffisant
Oui c'est franchement une idée qui serait pratique... proposition :
1) texte enrichi (gras, italique, souligné, etc.)
2) centrage/gauche/droite du texte
3) tableaux et liste (si possible !)
4) liens (*pas* img)
5) le nom des pièces jointes en balise correspond à une insertion de la pièce jointe à l'endroit de la balise (déjà existant dans pas mal de mailer)
A mon avis ce sous ensemble du html suffirait largement (et encore, sous-ensemble est un bien grand mot, il ne s'agit que de balises; on a pas besoin de body, header, etc.) ... Peut etre éventuellement une balise "signature" ..
Bof, j'ai plutôt l'impression que toutes les boites sont autant opportunistes sur le LL; la seule différence, c'est que certains s'en servent plus que d'autres (IBM) et donc ils s'impliquent automatiquement plus. Mais je ne crois pas qu'IBM se soit par exemple soudainement transformé en bons samaritains. Ils font ce qui leur est profitable, point. Coup de bol, ça nous arrange.
C'est la même chose avec Sun, HP, SGI ou Apple. Ne soyons pas naif.
Maintenant, sans être devenus des chantres du libres, le libre fait partie (plus ou moins) de leurs stratégies, et on a des retours (que ce soit au niveau soft, au niveau support du matériel ou une plus grande crédibilité) positifs. Donc ne crachons pas dessus et profitons en. Apple me paraît jouer le jeu, on le voit avec KHTML/Safari (ie, ils ne forkent pas et veulent participer au dev de khtml). Maintenant, la licence XFree n'oblige rien du tout, alors même si Apple pourrait prendre les devants, finalement, à qui la faute ? (y'a-t-il faute d'ailleurs ?)
Ils releasent de plus en plus de code en GPL, mais ILS NE L'ANNONCENT PAS.
Certes ... ceci dit pour Safari, ils l'annoncent hein, avec félicitations aux devs KDE pendant la keynote (avec en fond un slide style "Open Source is great" ou "we love opensource" je sais plus :) -- et oui j'imagine qu'ils doivent apprécier l'open source hein :-PP )
D'un autre côté, le code de mozilla est un peu énorme, voir alambiqué, alors que khtml est petit et bien fichu... avec une équipe de dev chez apple pour bosser à temps plein sur khtml, ça risque de bien accélérer les choses !
En effet, ils ont principalement codé des adaptateurs pour interfacer kjs (javascript) et khtml avec une gui codé pour cocoa en objective c ... donc leurs modifs de khtml pourront s'intégrer très facilement à la branche principale de khtml (du moins on le suppose, et c'est à priori le voeux des deux équipes de dev, chez apple comme chez kde). Du coup bonus direct pour nous, on doit s'attendre à une amélioration sensible de khtml.
Deuxième bonus, le fait qu'apple soit derrière incitera plus (même si juste "un peu") les devs de sites html d'être un chouilla plus respectueux des standards; on remarquera l'utilisation d'un bouton de bug report directement intégré (ça me rappelle la démarche de l'équipe mozilla pour traquer les sites webs récalcitrants, surtout genre e-commerce & banques).
Enfin accessoirement, ça nous fait un autre browser web pour GNUstep potentiel (en sus de Chimera) -- a plus qu'à attendre le support ObjC++ pour gcc ...
le titre de cette news et les propos du site ("pouvez vous faire mieux que MS") sont encore + déplacés : MS n'aurait rien à voir dans le "charityware".
Ben ils ont quand même joué le jeu et donné des sous. Maintenant, dans le "pouvez vous faire mieux que MS", c'est pas lancé en l'air à toute personne, Bram écrit : "If you are working for a company with a "double donation" scheme: Can you do better than Microsoft!?!?" ...
Donc c'est dans le cas ou par hasard tu bosses dans une boite qui encourage ce genre de pratiques (je suppose que cette pratique chez les boites ne doit par être étrangère aux ristournes d'impots qu'elles entrainent).
Ca ne s'adresse pas à tous les geek linuxiens en leur disant "voyez ! microsoft vous le mets profonds là ! qu'attendez vous ?", mais aux boites en général qui font des dons.
C'est de bonne guerre je pense, d'essayer de faire jouer un peu l'émulation ;)
L'IRC n'est pas atteint du tout par ce brevet, car il n'y a pas d'identifiant unique décorélé de la machine d'où tu te connectes
D'accord si le brevet fait le détail, mais l'article est suffisament flou dans sa formulation pour justement, aussi dingue que cela paraisse, toucher IRC. C'est ça que je voulais souligner. L'IRC n'est donc finalement peut être pas touché là, mais bon, le brevet est suffisament large pour toucher énormément d'autre systèmes...
D'ailleurs, l'IRC était lui-même préexistant au brevet et à "l'innovation" de Mirabilis-AOL.
Sans dec ? c'est pas vrai ? bah je savais pas hein, merci de le préciser. pfff.
Oui, à hauteur de 1300$ alors qu'ils consacrent 28 500 000$ pour les oeuvres de charité.
Oui c'est clair que ça fait léger... MAIS, si tu lis le mail de Bram Moolenaar, tu y lis : "Eight Microsoft employees have just contributed US $1,375 to the KCF.
Microsoft will match $1,275 of that, yielding a total of $2,650."
Pour moi je comprends ça dans le cadre de la campagne orchestrée par microsoft, un truc style, si les employés participent, on double la mise. Ca expliquerait la (faible) somme donnée, sachant qu'uniquement 8 employés ont participés.
The patent covers anything resembling a network that lets multiple IM users see when other people are present and then communicate with them.
Mais c'est de plus en plus DÉBILE ! comment peut on accorder un brevet comme ça !! franchement... l'IRC par exemple, ça me permet bien de voir quand les gens sont présents et communiquer ensuite avec eux... Donc l'IRC (RFC 1459) est potentiellement affecté par ce brevet ? on va vraiment vers la débilité la plus totale... d'autant que l'Europe a l'air sacrément décidée à rattraper son retard dans la débilité par rapport aux US (brevets, DMCA...)
Cool :)
Bon et bien tout ce qu'on peut leur souhaiter de pire c'est que ça se déroule aussi bien que l'an dernier ;-))
Si vous avez l'occasion d'y aller, faites le, c'est vraiment pas mal comme évènement... chapeau en tout cas, c'est pas un truc simple à organiser.
Ben en fait l'interface originale c'est le Wharf/Dock que tu peux avoir sous WMaker par exemple. Mais il existait un petit logiciel sympa, qui était un Shelf en bas de ton écran, ou tu avait les différentes icones de tes logiciels, le tout rangés dans des tabs. http://www.occam.com/images/pics/OS4M.gif pour un exemple (ou.. http://www.roard.com/screenshots/screenshot_panel5.png ;). Plus exactement, le Shelf devait remplacer le Dock dans la version 4 d'OPENSTEP, mais quelqu'un en avait réécrit un.
Ensuite, fabien parle d'un logiciel très sympa également, Paste It, qui permettait en fait de se "souvenir" de tous les trucs passés par le serveur de drag'n drop. Il y a un logiciel sous mac qui reprends le même principe (désolé j'ai oublié le nom...) et qui a la possibilité de poser les panneaux ou tu dépose les objets un peu partout à l'écran, et entre autre tu peux les attacher en tant que tabs sur les bords d'écran, un peu beaucoup donc comme ce que décrit la proposition de slicker (donc en gros, il s'agit d'un Shelf sur lequel tu peux déposer tout ce qui est possible de déposer en dnd, programmes, fichiers, sons, images, url, textes..., et qui permet d'attacher les différents tabs un peu partout à l'écran)
Mais bon, Slicker est un peu différent dans le concept (et puis c'est du joli photoshop transparent et antialiasé :) . Je suis assez dubitatif en fait en terme d'utilisabilitité (il me semble qu'il y a bcp trop de trucs, et pas mal s'autohident, ce que perso j'aime pas du tout.. mais bon...)
Effectivement il s'agit d'une méthode ... mais concrètement les outils se prévalant de cette notion de RAD ont surtout portés sur le prototypage visuel d'application (les visual* de microsoft par exemple), et c'est vrai qu'on à tendance du coup à parler de RAD pour des constructeurs d'interfaces graphiques (enfin moi j'ai cette tendance :) ... comme Gorm par exemple. Accessoirement comme Gorm travaille en fait vraiment sur des objets, les relie ensemble, etc. je pense qu'on est pas loin d'un outil d'aide au RAD au sens ou tu l'entends (mais je peux me planter).
il me semble que personne n'a encore tenu compte des classes d'utilistateurs...
Oui, en général on ne parle que de l'utilisateur "débutant", alors qu'on pourrait considérer une classe d'utilisateur "expert"...
je pense au interface "hall of shame"... tout d'abord, il propose pas (ou rarement) une solution...
Parce qu'il est beaucoup plus simple de se rendre compte qu'un design est mauvais que de trouver une bonne solution... :-/
Ceci dit, je suis d'accord avec toi concernant l'imitation abusive de microsoft en ce qui concerne les interfaces... mais que veux-tu, on est pas tous ergonome, et quand on ne connait pas quelque chose, on une tendance naturelle à imiter ce qu'on connait autour de nous...
Ben oui, on est pas tous ergonomes, mais justement : dans ce cas, on devrait s'en tenir à certaines règles (genre de faire un soft le plus "simple" possible en terme d'UI), écouter l'avis des utilisateurs, etc. S'inspirer de softs est logique, mais ce serait bien de s'inspirer de softs autre que ceux qui ont une UI pourrie :-/ (et je suis désolé, mais pour revenir sur le débat, Word a une UI pourrie, en particulier bien trop complexe; ce qui n'a rien à voir avec ses capacités hein)
Oui enfin il t'installes teTeX aussi (une distrib TeX), car texmacs utilise TeX pour générer ses fontes (au moins à l'écran)
Perso j'aime pas trop texmacs ou LyX, (en fait surtout parce que c'est la misère pour ensuite en sortir un document (La)TeX, histoire d'utiliser certains packages indispensables comme listings :) , mais quelqu'un m'a montré la dernière version de texmacs, et ça commence à être plutôt pas mal en fait.
Il existe bien sûr une série de recommandation (dont celle de ms, apple et... KDE!) qui dépende plus ou moins fort de l'os, mais rien de fixe
Oui enfin là on ne parle pas de guides d'interfaces, mais d'études ergonomiques; et bien que ce ne soit pas une science (loin de là), il y a quand même certains principes (dont le keep it simple, stupide :) . Après, comme il est très difficile d'évaluer la qualité objective d'une interface, ça peut dévier en querelles d'expert, c'est sûr.
Mais quelque part, des menus qui disparaissent/apparaissent tous seuls, ça me semble un comportement erratique et absolument pas intuitif; Les gens apprennent ou chercher quelque chose dans un logiciel, alors si les fonctions se déplacent toutes seuls, je vois pas ça comme un progrès. Et puis bon, le coup de "au vu sous windows du nombre de lib qui tente de mimer ce comportement (et qui se vende! ;-) j'aurais tendance à croire que ça plait aux gens... ", ça n'est surtout pas un argument.
D'une part parce que le nombre n'a pas forcèment raison (exemple : des milliards de mouches mangent de la merde, on devrait peut être essayer !), et deuxièmement parce qu'en ergonomie, il y a un gros problème : les gens achètent un produit en fonction de ses fonctionnalités ou de son design, mais pas en fonction de son ergonomie; Pourquoi ? parce qu'avant d'avoir utilisé ce produit, il est impossible de savoir s'il est ergonomique ou non...
Pensez par exemple à des magnifiques batiments dont les architectes ont gagnés énormèment de prix, mais qui à l'usage sont infects (mauvaise clim/isolation, dédale de couloirs, etc.). Il est "facile" de faire un truc design, mais très difficile de faire un truc ergonomique mais aussi avec un design sympa : les deux choses sont parfois à l'opposé. On peut reprendre un exemple du bouquin "the design of everyday thing", les portes vitrées : certaines sont très design, on ne voit que le verre. Mais elles sont du coup très peu pratique, car il n'y a pas d'indication de l'endroit ou on doit agir pour ouvrir la porte... bref.
Concernant les interfaces graphiques, jettez un oeil sur le "Interface Hall of Shame", qui contient une série de perles. Et on s'aperçoit que souvent les développeurs "copient" les uns sur les autres (et en particulier sur microsoft) en pensant bien faire, mais copient en réalité de belles conneries. On a le même problème sous linux je crois : beaucoup de softs sont fortement inspirés du monde windows, car, "s'ils l'ont fait, c'est que ce doit être bien!" ... et bien non.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 1.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 3.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 2.
Ca serait stupide. Maintenant, envoyer un CV en HTML, bof. Le HTML permet de transmettre l'information, mais n'apporte aucune garantie quant à sa représentation. Le PDF est idéal pour ça : ce que le type verra sur son écran ou s'il imprime le CV est exactement ce qui a été prévu, et franchement pour un CV on essaie en général de soigner la présentation. Joindre un CV en HTML, *au cas ou*, pourquoi pas, mais le PDF me semble franchement mieux adapté.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 1.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 1.
D'une part, en parlant de tableaux, je voyais plus le côté tableur, donc pas vraiment du html mais un document kspread ou gnumeric par exemple. Donc non, je ne voulais pas forcèment qu'il s'affiche directement dans le mailer.
Tu ne vas quand même pas me dire qu'il faudrait que les gens sauvent l'attachement et sortent leur browser pour le lire ensuite ? Allez, tu vas bien accepter que le browser soit lancé directement dans le mailer, hein ? Bon, c'est gentil.
Pourquoi sauver et sortir le browser ? cliquer dessus pour lancer le viewer associé au type mime est trop compliqué ?
Et maintenant, redis-moi à quoi sert ton mini-HTML, à part offrir une mauvaise solution à un problème déjà parfaitement résolu, et faire perdre un temps pas possible à tout le monde pour le definir, l'implementer, etc... ?
Sauf que je n'ai *jamais* parlé de foutre tout dans le mail et de tout visualiser dedans ... la plupart du temps (ie, pour autre chose que des images), il vaut mieux ouvrir le fichier attaché dans le viewer qui va bien -- au moins c'est prévu pour et tu as la place de voir ce qui t'intéresse. Une image c'est différent je pense, tout simplement parce que tu peux la retailler si besoin sans qu'elle perde tout sens (et de toute façon tu peux toujours l'ouvrir dans un viewer). Mais tout en inline, avec des tailles pas forcément suffisantes pour bien voir ton document attaché, bof.
Maintenant c'est juste mon avis, je ne force personne hein.
[^] # Re: Disponibilité d'une version bêta de X11 pour Mac OS X par Apple
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Disponibilité d'une version bêta de X11 pour Mac OS X par Apple. Évalué à 1.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 1.
Pourquoi ? si je parle de sous ensemble, c'est parce que mis à part ces quelques tags que j'ai cité, je ne vois pas trop d'autres trucs vraiment utiles, *pour le mail*.
Donc n'appelons pas ça du HTML (ça n'en est pas), mais, allez, XMaiL par exemple... ;)
Ca permettrait un parsing facile des mails pour les logiciels (soit pour virer les balises, soit pour les interpréter s'ils peuvent), avec surtout un rendu très simple à faire... (et léger). Pour le mail on a pas vraiment besoin d'implémenter HTML 4 + CSS !!! L'introduction de ces quelques balises permettrait un meilleur affichage des mails (mieux en tout que ce qu'on fait, cad soit rien, soit on essaye de deviner en choppant les url, les _toto_ et autres /pipo/ ...) sans alourdir plus que ça le mail ... et on aurait un affichage certain d'être propre...
je suis même pas sûr que les tableaux soient utiles (un tableau travaillé serait plutôt un attachement, et à l'extrême encourageraient les gens à faire des trucs qui seraient mieux en attachement directement dans le mail... et puis les tableaux, c'est chiant à coder :-P). Par contre des balises quote pour les niveaux de citations seraient pratiques :)
S'en tenir à ces quelques balises suffiraient pour les besoins du mail, sans complexifier beaucoup la conception de clients mail, et sans faire intervenir des problèmes de sécurité.
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 1.
Oui c'est franchement une idée qui serait pratique... proposition :
1) texte enrichi (gras, italique, souligné, etc.)
2) centrage/gauche/droite du texte
3) tableaux et liste (si possible !)
4) liens (*pas* img)
5) le nom des pièces jointes en balise correspond à une insertion de la pièce jointe à l'endroit de la balise (déjà existant dans pas mal de mailer)
A mon avis ce sous ensemble du html suffirait largement (et encore, sous-ensemble est un bien grand mot, il ne s'agit que de balises; on a pas besoin de body, header, etc.) ... Peut etre éventuellement une balise "signature" ..
[^] # Re: licence de XFree86 = pillage en vue
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Disponibilité d'une version bêta de X11 pour Mac OS X par Apple. Évalué à 7.
C'est la même chose avec Sun, HP, SGI ou Apple. Ne soyons pas naif.
Maintenant, sans être devenus des chantres du libres, le libre fait partie (plus ou moins) de leurs stratégies, et on a des retours (que ce soit au niveau soft, au niveau support du matériel ou une plus grande crédibilité) positifs. Donc ne crachons pas dessus et profitons en. Apple me paraît jouer le jeu, on le voit avec KHTML/Safari (ie, ils ne forkent pas et veulent participer au dev de khtml). Maintenant, la licence XFree n'oblige rien du tout, alors même si Apple pourrait prendre les devants, finalement, à qui la faute ? (y'a-t-il faute d'ailleurs ?)
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 2.
Certes ... ceci dit pour Safari, ils l'annoncent hein, avec félicitations aux devs KDE pendant la keynote (avec en fond un slide style "Open Source is great" ou "we love opensource" je sais plus :) -- et oui j'imagine qu'ils doivent apprécier l'open source hein :-PP )
[^] # Re: Apple sort un navigateur basé sur KHTML
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple sort un navigateur basé sur KHTML. Évalué à 10.
En effet, ils ont principalement codé des adaptateurs pour interfacer kjs (javascript) et khtml avec une gui codé pour cocoa en objective c ... donc leurs modifs de khtml pourront s'intégrer très facilement à la branche principale de khtml (du moins on le suppose, et c'est à priori le voeux des deux équipes de dev, chez apple comme chez kde). Du coup bonus direct pour nous, on doit s'attendre à une amélioration sensible de khtml.
Deuxième bonus, le fait qu'apple soit derrière incitera plus (même si juste "un peu") les devs de sites html d'être un chouilla plus respectueux des standards; on remarquera l'utilisation d'un bouton de bug report directement intégré (ça me rappelle la démarche de l'équipe mozilla pour traquer les sites webs récalcitrants, surtout genre e-commerce & banques).
Enfin accessoirement, ça nous fait un autre browser web pour GNUstep potentiel (en sus de Chimera) -- a plus qu'à attendre le support ObjC++ pour gcc ...
# Re: Que choisir comme environnement ???
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Que choisir comme environnement ???. Évalué à 3.
[^] # Re: Microsoft aide le charityware
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Microsoft aide le charityware. Évalué à 2.
Ben ils ont quand même joué le jeu et donné des sous. Maintenant, dans le "pouvez vous faire mieux que MS", c'est pas lancé en l'air à toute personne, Bram écrit : "If you are working for a company with a "double donation" scheme: Can you do better than Microsoft!?!?" ...
Donc c'est dans le cas ou par hasard tu bosses dans une boite qui encourage ce genre de pratiques (je suppose que cette pratique chez les boites ne doit par être étrangère aux ristournes d'impots qu'elles entrainent).
Ca ne s'adresse pas à tous les geek linuxiens en leur disant "voyez ! microsoft vous le mets profonds là ! qu'attendez vous ?", mais aux boites en général qui font des dons.
C'est de bonne guerre je pense, d'essayer de faire jouer un peu l'émulation ;)
[^] # Re: AOL brevète la messagerie instanantanée
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche AOL brevète la messagerie instantanée. Évalué à 1.
D'accord si le brevet fait le détail, mais l'article est suffisament flou dans sa formulation pour justement, aussi dingue que cela paraisse, toucher IRC. C'est ça que je voulais souligner. L'IRC n'est donc finalement peut être pas touché là, mais bon, le brevet est suffisament large pour toucher énormément d'autre systèmes...
D'ailleurs, l'IRC était lui-même préexistant au brevet et à "l'innovation" de Mirabilis-AOL.
Sans dec ? c'est pas vrai ? bah je savais pas hein, merci de le préciser. pfff.
[^] # Re: Microsoft aide le charityware
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Microsoft aide le charityware. Évalué à 5.
Oui c'est clair que ça fait léger... MAIS, si tu lis le mail de Bram Moolenaar, tu y lis :
"Eight Microsoft employees have just contributed US $1,375 to the KCF.
Microsoft will match $1,275 of that, yielding a total of $2,650."
Pour moi je comprends ça dans le cadre de la campagne orchestrée par microsoft, un truc style, si les employés participent, on double la mise. Ca expliquerait la (faible) somme donnée, sachant qu'uniquement 8 employés ont participés.
# Re: AOL brevète la messagerie instanantanée
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche AOL brevète la messagerie instantanée. Évalué à 2.
Mais c'est de plus en plus DÉBILE ! comment peut on accorder un brevet comme ça !! franchement... l'IRC par exemple, ça me permet bien de voir quand les gens sont présents et communiquer ensuite avec eux... Donc l'IRC (RFC 1459) est potentiellement affecté par ce brevet ? on va vraiment vers la débilité la plus totale... d'autant que l'Europe a l'air sacrément décidée à rattraper son retard dans la débilité par rapport aux US (brevets, DMCA...)
# Re: Interviews hebdomadaires du FOSDEM
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Interviews hebdomadaires du FOSDEM. Évalué à 10.
Bon et bien tout ce qu'on peut leur souhaiter de pire c'est que ça se déroule aussi bien que l'an dernier ;-))
Si vous avez l'occasion d'y aller, faites le, c'est vraiment pas mal comme évènement... chapeau en tout cas, c'est pas un truc simple à organiser.
quelques liens décrivant le fosdem de l'an dernier :
http://www.xdev.org/gen.php3?/2002/02/16/50,0,1,0,0.html(...)
http://www.xdev.org/gen.php3?/2002/02/19/51,0,1,0,0.html(...)
http://www.xdev.org/gen.php3?/2002/03/11/52,0,1,0,0.html(...)
[^] # Re: slicKer
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche slicKer. Évalué à 4.
[^] # Re: RAD ?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche LinuxFocus a 5 ans !. Évalué à 7.
[^] # Re: LinuxFocus a 5 ans !
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche LinuxFocus a 5 ans !. Évalué à 0.
[^] # Re: Sus aux propos puerils
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche OpenOffice.org VS Microsoft Office. Évalué à 1.
Moi j'ai déjà vu marqué LaTeX et pas Word/Excel hein :-P
[^] # Re: LinuxFocus a 5 ans !
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche LinuxFocus a 5 ans !. Évalué à 1.
Inoa ne sera pas pour demain
Comment ! pas pour lundi ? mais c'est un scandale ! :)
TSHACK va peut etre me donner un petit coup de main sur l'UI car il se dit interesse.
héhé ... :)) en attendant tschak il avance sur Tina.app (http://www.openminds.tv/software/TBook/TINA-0.1.tar.gz(...) et http://www.customercd.com/thomas/TINA-gnustep-and-osx.png(...)) hein :-P
(et contrairement aux apparences, non, ce n'est pas un carnet d'adresses)
</private>
[^] # Re: Arghh !
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche OpenOffice.org VS Microsoft Office. Évalué à 2.
Oui, en général on ne parle que de l'utilisateur "débutant", alors qu'on pourrait considérer une classe d'utilisateur "expert"...
je pense au interface "hall of shame"... tout d'abord, il propose pas (ou rarement) une solution...
Parce qu'il est beaucoup plus simple de se rendre compte qu'un design est mauvais que de trouver une bonne solution... :-/
Ceci dit, je suis d'accord avec toi concernant l'imitation abusive de microsoft en ce qui concerne les interfaces... mais que veux-tu, on est pas tous ergonome, et quand on ne connait pas quelque chose, on une tendance naturelle à imiter ce qu'on connait autour de nous...
Ben oui, on est pas tous ergonomes, mais justement : dans ce cas, on devrait s'en tenir à certaines règles (genre de faire un soft le plus "simple" possible en terme d'UI), écouter l'avis des utilisateurs, etc. S'inspirer de softs est logique, mais ce serait bien de s'inspirer de softs autre que ceux qui ont une UI pourrie :-/ (et je suis désolé, mais pour revenir sur le débat, Word a une UI pourrie, en particulier bien trop complexe; ce qui n'a rien à voir avec ses capacités hein)
[^] # Re: OpenOffice.org VS Microsoft Office
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche OpenOffice.org VS Microsoft Office. Évalué à 1.
Perso j'aime pas trop texmacs ou LyX, (en fait surtout parce que c'est la misère pour ensuite en sortir un document (La)TeX, histoire d'utiliser certains packages indispensables comme listings :) , mais quelqu'un m'a montré la dernière version de texmacs, et ça commence à être plutôt pas mal en fait.
[^] # Re: Arghh !
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche OpenOffice.org VS Microsoft Office. Évalué à 3.
Oui enfin là on ne parle pas de guides d'interfaces, mais d'études ergonomiques; et bien que ce ne soit pas une science (loin de là), il y a quand même certains principes (dont le keep it simple, stupide :) . Après, comme il est très difficile d'évaluer la qualité objective d'une interface, ça peut dévier en querelles d'expert, c'est sûr.
Mais quelque part, des menus qui disparaissent/apparaissent tous seuls, ça me semble un comportement erratique et absolument pas intuitif; Les gens apprennent ou chercher quelque chose dans un logiciel, alors si les fonctions se déplacent toutes seuls, je vois pas ça comme un progrès. Et puis bon, le coup de "au vu sous windows du nombre de lib qui tente de mimer ce comportement (et qui se vende! ;-) j'aurais tendance à croire que ça plait aux gens... ", ça n'est surtout pas un argument.
D'une part parce que le nombre n'a pas forcèment raison (exemple : des milliards de mouches mangent de la merde, on devrait peut être essayer !), et deuxièmement parce qu'en ergonomie, il y a un gros problème : les gens achètent un produit en fonction de ses fonctionnalités ou de son design, mais pas en fonction de son ergonomie; Pourquoi ? parce qu'avant d'avoir utilisé ce produit, il est impossible de savoir s'il est ergonomique ou non...
Pensez par exemple à des magnifiques batiments dont les architectes ont gagnés énormèment de prix, mais qui à l'usage sont infects (mauvaise clim/isolation, dédale de couloirs, etc.). Il est "facile" de faire un truc design, mais très difficile de faire un truc ergonomique mais aussi avec un design sympa : les deux choses sont parfois à l'opposé. On peut reprendre un exemple du bouquin "the design of everyday thing", les portes vitrées : certaines sont très design, on ne voit que le verre. Mais elles sont du coup très peu pratique, car il n'y a pas d'indication de l'endroit ou on doit agir pour ouvrir la porte... bref.
Concernant les interfaces graphiques, jettez un oeil sur le "Interface Hall of Shame", qui contient une série de perles. Et on s'aperçoit que souvent les développeurs "copient" les uns sur les autres (et en particulier sur microsoft) en pensant bien faire, mais copient en réalité de belles conneries. On a le même problème sous linux je crois : beaucoup de softs sont fortement inspirés du monde windows, car, "s'ils l'ont fait, c'est que ce doit être bien!" ... et bien non.
Interface hall of Shame : http://www.iarchitect.com/mshame.htm(...)
The Design of Everiday Things de Norman : http://www.amazon.com/exec/obidos/ASIN/0465067107/qid=1039877549/sr(...)