Ca m'a pris trop de temps a tapé, c'est dommage de l'enterrer au fond d'une thread sur linuxfr. Donc voici ma réponse à la thread:
http://linuxfr.org/2003/09/17/13961.html(...)
-----------------------------------------------------------------------
> Gnome assure une communication (et de qualité). Trop peu d'applications Gnome l'utilisent.
T'es tu demandé pourquoi ? Il y a une raison. C'est que mettre un composant bonobo en place, c'est pas aussi simple et léger que mettre un kpart en place. Dans ma vision personelle, je pousserai même jusqu'à dire que programmer une application en gtk/gnome demande un investissement significatif en temps, et que des lors, il ne reste plus beaucoup de temps au programmeur pour faire des petits trucs en plus. Ces petits trucs pouvant être de respecter correctement les HIG ou rendre son application disponible sous forme de composant. Mais laissons cet aspect controversé de côté et regardons des éléments objectifs.
Je pense que le succès plus important des composants dans KDE est lié aux points suivants:
- kpart existe depuis plusieurs années dans KDE
- c'est bien documenté et très léger à mettre en place pour un développeur
quelques références:
http://phil.freehackers.org/kde/kpart-techno/kpart-techno.html(...(...))
http://developer.kde.org/documentation/library/3.1-api/kparts/html/(...))
http://developer.kde.org/documentation/tutorials/index.html(...(...))
à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes. J'en avais cherchées il y a deux ans et un an et je n'avais presque rien trouvé. Depuis Michael Meeks a pondu quelques bonnes documentations.
- bonobo n'est arrivé à maturité que récemment
- très peu d'applications sont bonobo-aware.
- comme beaucoup d'applications utilisent déja des kpart, il est facile de trouver des exemples sous KDE. L'effet inverse joue sur Gnome
Donc en gros, il semble que la différence provienne de la maturité tardive de bonobo. Comment se fait-il que bonobo arrive à maturité aussi tard alors même que les composants faisaient partie de la vision de base d'un bureau développé par MDI (cf sa page web, vision très intéressante et qu'on peut voir réalisée aujourd'hui ... dans KDE!). Au départ, Gnome n'a qu'un an de retard sur KDE mais en terme de composants, on est a peine dans Gnome au niveau qu'on avait dans KDE 2.0
Je suis intimement persuadé que la raison de ceci est que les technologies KDE pourtant très largement critiquée en leur temps sont bien plus adaptées au problème. Le fait du partir sur du Corba a coûté très cher a Gnome en temps de développement et un complexité, pour un résultat qui n'apporte rien de plus que kpart, ou bien des choses qui ne servent à rien. Par exemple, j'aime bien cette phrase dans le tutorial de bonobo: "Finally, using a component model allows the running of your controls on other machines. There must be someone, somewhere who wants that."
D'un point de vue développeur, ce que je vois comme inconvénient à bonobo:
- peu d'applications l'utilise donc c'est dur de trouver des exemples
- l'échange d'informations par property bag est lourd à mettre en place.. Cela veut dire que le développeur Gnome doit modifier pas mal son code pour gérer la communication avec le composant bonobo. KPart de son côté remplace un appel de méthode par un appel de méthode. Et dehors du type des pointeurs qui change, migrer du code vers kpart est très rapide
- s'il y a un probleme avec bonobo, il faut descendre dans les couches basses et ça devient tout de suite très compliqué: c'est du corba. La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.
> Je n'ai jamais vu une KPart s'écrire toute seule.
Il faut moins de 50 lignes de code pour passer une application en KPart. C'est vraiment proche du "ça s'ecrit tout seul"
> rien de tel n'existe sous Gnome Office et donc le mot integration est tres tres exagere.
> Probablement exact, mais je ne vois pas en quoi ça rend KDE meilleur (juste KOffice).
Le point important, c'est que les technologies KDE sont plus avancées et permettent de faire ce genre de chose beaucoup plus facilement. Et, c'est grâce aux technologies mises très tôt en place dans KDE, sur lesquelles KOffice ne fait que s'appuyer.
> Vous n'avez pas montré que KDE était supérieur à Gnome, juste que KOffice est meilleur que Gnome Office pour certaines raisons
Ce que je veux montrer, ce n'est pas que KOffice est supérieur à Gnome Office, c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome.
On a parlé composant mais si on parle de scriptabilité, Gnome est carrément à des années lumières de retard.
Imaginons par exemple que je veux ouvrir une konsole avec trois sessions ssh vers trois différentes machines avec un script:
# launch konsole with remote dcop control enabled
konsole --script &
# process-id is used to generate the dcop name of konsole
kid=konsole-$!
echo Konsole is $kid
session="session-1"
# you need to add a small delay
sleep 0.5
dcop $kid $session sendSession "ssh machine1"
sleep 0.5
# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine2"
sleep 0.5
# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine3"
J'aimerai voir la version équivalente de ce script pour Gnome. Notons que ce genre de chose est possible depuis KDE 2.0 . Pour en savoir plus:
http://developer.kde.org/documentation/tutorials/automation/index.h(...))
> Cette affirmation serait-elle donc un troll grossier ?
Non, c'est une opinion que je suis en mesure d'argumenter.
http://linuxfr.org/2003/09/17/13961.html(...)
-----------------------------------------------------------------------
> Gnome assure une communication (et de qualité). Trop peu d'applications Gnome l'utilisent.
T'es tu demandé pourquoi ? Il y a une raison. C'est que mettre un composant bonobo en place, c'est pas aussi simple et léger que mettre un kpart en place. Dans ma vision personelle, je pousserai même jusqu'à dire que programmer une application en gtk/gnome demande un investissement significatif en temps, et que des lors, il ne reste plus beaucoup de temps au programmeur pour faire des petits trucs en plus. Ces petits trucs pouvant être de respecter correctement les HIG ou rendre son application disponible sous forme de composant. Mais laissons cet aspect controversé de côté et regardons des éléments objectifs.
Je pense que le succès plus important des composants dans KDE est lié aux points suivants:
- kpart existe depuis plusieurs années dans KDE
- c'est bien documenté et très léger à mettre en place pour un développeur
quelques références:
http://phil.freehackers.org/kde/kpart-techno/kpart-techno.html(...(...))
http://developer.kde.org/documentation/library/3.1-api/kparts/html/(...))
http://developer.kde.org/documentation/tutorials/index.html(...(...))
à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes. J'en avais cherchées il y a deux ans et un an et je n'avais presque rien trouvé. Depuis Michael Meeks a pondu quelques bonnes documentations.
- bonobo n'est arrivé à maturité que récemment
- très peu d'applications sont bonobo-aware.
- comme beaucoup d'applications utilisent déja des kpart, il est facile de trouver des exemples sous KDE. L'effet inverse joue sur Gnome
Donc en gros, il semble que la différence provienne de la maturité tardive de bonobo. Comment se fait-il que bonobo arrive à maturité aussi tard alors même que les composants faisaient partie de la vision de base d'un bureau développé par MDI (cf sa page web, vision très intéressante et qu'on peut voir réalisée aujourd'hui ... dans KDE!). Au départ, Gnome n'a qu'un an de retard sur KDE mais en terme de composants, on est a peine dans Gnome au niveau qu'on avait dans KDE 2.0
Je suis intimement persuadé que la raison de ceci est que les technologies KDE pourtant très largement critiquée en leur temps sont bien plus adaptées au problème. Le fait du partir sur du Corba a coûté très cher a Gnome en temps de développement et un complexité, pour un résultat qui n'apporte rien de plus que kpart, ou bien des choses qui ne servent à rien. Par exemple, j'aime bien cette phrase dans le tutorial de bonobo: "Finally, using a component model allows the running of your controls on other machines. There must be someone, somewhere who wants that."
D'un point de vue développeur, ce que je vois comme inconvénient à bonobo:
- peu d'applications l'utilise donc c'est dur de trouver des exemples
- l'échange d'informations par property bag est lourd à mettre en place.. Cela veut dire que le développeur Gnome doit modifier pas mal son code pour gérer la communication avec le composant bonobo. KPart de son côté remplace un appel de méthode par un appel de méthode. Et dehors du type des pointeurs qui change, migrer du code vers kpart est très rapide
- s'il y a un probleme avec bonobo, il faut descendre dans les couches basses et ça devient tout de suite très compliqué: c'est du corba. La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.
> Je n'ai jamais vu une KPart s'écrire toute seule.
Il faut moins de 50 lignes de code pour passer une application en KPart. C'est vraiment proche du "ça s'ecrit tout seul"
> rien de tel n'existe sous Gnome Office et donc le mot integration est tres tres exagere.
> Probablement exact, mais je ne vois pas en quoi ça rend KDE meilleur (juste KOffice).
Le point important, c'est que les technologies KDE sont plus avancées et permettent de faire ce genre de chose beaucoup plus facilement. Et, c'est grâce aux technologies mises très tôt en place dans KDE, sur lesquelles KOffice ne fait que s'appuyer.
> Vous n'avez pas montré que KDE était supérieur à Gnome, juste que KOffice est meilleur que Gnome Office pour certaines raisons
Ce que je veux montrer, ce n'est pas que KOffice est supérieur à Gnome Office, c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome.
On a parlé composant mais si on parle de scriptabilité, Gnome est carrément à des années lumières de retard.
Imaginons par exemple que je veux ouvrir une konsole avec trois sessions ssh vers trois différentes machines avec un script:
# launch konsole with remote dcop control enabled
konsole --script &
# process-id is used to generate the dcop name of konsole
kid=konsole-$!
echo Konsole is $kid
session="session-1"
# you need to add a small delay
sleep 0.5
dcop $kid $session sendSession "ssh machine1"
sleep 0.5
# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine2"
sleep 0.5
# create a new session
session=`dcop $kid konsole newSession`
dcop $kid $session sendSession "ssh machine3"
J'aimerai voir la version équivalente de ce script pour Gnome. Notons que ce genre de chose est possible depuis KDE 2.0 . Pour en savoir plus:
http://developer.kde.org/documentation/tutorials/automation/index.h(...))
> Cette affirmation serait-elle donc un troll grossier ?
Non, c'est une opinion que je suis en mesure d'argumenter.
> Lire le journal (56 commentaires, moyenne: 1,5).
Vous avez demandé le commentaire #271382.
Run by 
Cette page a été générée par Templeet en 0.0808s (dont 0.0076 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Ok, tu veux troller...
KDE a ses avantages, certes. Gnome aussi.
KDE est merdique sur les langues orientales, c'est pour ca que Gnome est nettement plus repandu en Asie. Gnome utilise Pango alors que le rendu de KDE en japonais est immonde, a moins de configurer comme un malade.
Et une fois que c'est configure, on est coince sur les vieilles methodes de saisie de X Windows (kinput2 pour le japonais, rien a voir avec kde malgre le nom) qui colle une fenetre par-dessus celle ou on est en train d'ecrire. Immonde, il n'y a pas beaucoup de japonais qui sont motives pour utiliser ca.
De l'autre cote, Gnome se base sur gtk-im (systeme de saisie de Gtk) qui permet d'avoir une integration complete du systeme de saisie avec l'application sous-jacente. Et avec ces bases, tandis que kinput2 n'a pas bouge d'un poil depuis des annees, en quelques mois un europeen (polonais je crois) a sorti un systeme de saisie du japonais - im-ja - qui se branche a tous les serveurs de conversion kana->kanji connus ainsi qu'a kanjipad (pour dessiner les caracteres), est configurable en clicodrome rivalise avec ce qu'on trouve sous Windows.
Donc en gros, j'ai migre de KDE que j'aimais beaucoup a Gnome que j'ai appris a aimer pour ce point particulier. Et j'ai trouve d'autres avantages a Gnome.
Conclusion : dire que Gnome est a des annees lumieres de KDE est une *connerie*, ils ont chacun leurs avantages. Mais les zealots de KDE disent ca depuis que Gnome existe et ca n'a jamais decourage ni les developpeurs ni les utilisateurs de Gnome, alors on est tranquilles.
[^]Re: Ok, tu veux troller...
Ta conclusion est fausse.
J'utilise KDE depuis le début et c'était l'époque où 95% des linuxiens (ayant un desktop KDE/GNOME) utilisaient Gnome.
KDE se faisait taper sur la gueule tout le temps en disant que c'était moche et buggué. Que c'était mal conçu. Qu'il y avait pas d'applis....
Maintenant c'est l'inverse et beaucoup de personne qui aimait Gnome 1.4 sont passé à KDE cas GNOME 2.0 était pourri au début (pas fini, buggué, pas d'appli,...). Et pourquoi ça ? Parce que Gnome avait une architecture merdique donc il a fallu tout refaire => Gnome 2
Gnome rattrape son retard "technique" et KDE son retard sur le nombre d'applis disponibles. Mais il y a des points sur-lesquels l'un est meilleur que l'autre. Ton exemple le prouve.
[^]Re: Ok, tu veux troller...
> Parce que Gnome avait une architecture merdique donc il a fallu tout refaire => Gnome 2
"Merdique". Vous pouvez pas choisir un peu mieux les termes.
Puis sur l'aspect "tout refaire", il y avais toujours gconf, corba, bonobo, esd, le panel, etc, etc... (et la boîte de sélection de fichier n'a pas changé :-)). Les grosses incompatibilités sont venue de gtk+ et libgnomeui.
Puis en 12 ou 18 mois on ne peux pas tout refaire.
> Gnome rattrape son retard "technique"
Joli troll, subtil. Ça fait depuis la sortie de Gnome que ce gentil troll existe. Ça fait depuis la sortie de Gnome qu'on dit que Gnome rattrape son retard et depuis le début il est toujours en retard...
Gnome rattrape son retard ou qu'il reste toujours en retard ?
Faudrait savoir.
De part sa conception Gnome est en avance dans certain domaine. De part sa conception KDE est en avance dans certain domaine.
[^]Re: Ok, tu veux troller...
Joli troll, subtil. Ça fait depuis la sortie de Gnome que ce gentil troll existe. Ça fait depuis la sortie de Gnome qu'on dit que Gnome rattrape son retard et depuis le début il est toujours en retard...
Gnome rattrape son retard ou qu'il reste toujours en retard ?
Faudrait savoir.
vu le nombre de devs gnome et d entreprises derriere gnome , j espere bien qu il ne peut que rattraper , le contraire serait un comble
[+] [^]Re: Ok, tu veux troller...
> vu le nombre de devs gnome et d entreprises derriere gnome , j espere bien qu il ne peut que rattraper , le contraire serait un comble
Parque même avec tout ça le retard n'est pas rattrapé. C'est désespérant...
Ta remarque est habile car comme ça tu retires les mérites du projet.
Heureusement qu'il y a SuSE et Trolltech derrière KDE...
Ha troll quand tu nous tiens.
[^]Re: Ok, tu veux troller...
Tiens, ce serait interessante de compter le nombre de developpeurs payes dans chaque projet.
Je pense honnetement qu'il ya plus de developpeurs payes sur Gnome. Entre Sun, Ximian, RedHat, Suse (et oui, suse paye aussi un developpeur Gnome), ca fait vraiment du monde.
Tout le cote ATK de Gnome notamment, a du prendre beaucoup de monde pour son developpement.
Cote KDE, le seul developpeur encore paye a plein temps pour bosser sur KDE est Waldo Bastian. Il y en 4 ou 5 qui sont payes pour bosser a mi-temps (genre David Faure) et le reste c'est des benevoles. Et il y a quelques contrats, genre le serveur Kolab.
Tiens, autre question, quelqu'un a entendu parler de contrats pour developper des fonctionnalites de Gnome, comme ca c'est passe avec Kolab ?
phil.freehackers.org
[^]Re: Ok, tu veux troller...
y a aussi lmontel chez mandrake
[^]Re: Ok, tu veux troller...
Je crois qu'il n'a plus le temps de bosser pour KDE. Il faut du packaging et basta.
phil.freehackers.org
[^]Re: Ok, tu veux troller...
c'est quoi le code ATK ?
[^]Re: Ok, tu veux troller...
Mais pourquoi tant de haine.
Le monde est vraiment trop injuste :-(
> contrats
C'est quoi ?
[^]Re: Ok, tu veux troller...
Tiens, ça serait intéressant de compter *pour de vrai* le nombre de développeurs payés dans chaque projet, c'est à dire en comptant les développeurs payé pour développer gtk+ et qt... A mon avis, t'obtiens beaucoup plus de monde payés pour développer sur kde en comptant comme ça...
Développeurs RedHat payés pour bosser sur GNOME : on va dire 2 (Alex Larsson et Jonathan Blandford), plus Havoc Pennington (même s'il est code de moins en moins pour GNOME, et de plus en plus sur des trucs comme freedesktop) et Owen Taylor (bosse sur GTK+)
Développeurs Sun : je sais pas trop, mais ils contribuent pas beaucoup de code en dehors de tout ce qui concerne l'accessibilité, et des patches par ci par là dont ils avaient besoin. Il y a quand même markmc (gnome-panel, mais c'est peut être sur son temps libre) et glynn foster (mais a priori il a pas écrit beaucoup de code ces derniers temps)
Développeurs Ximian : contrairement aux idées reçues, très peu de développeurs codant énormément sur gnome. Ils font plutot de l'evolution, du redcarpet, du mono, ... Il y a quand même Dave Camp (nautilus), et qques autres personnes qui filent régulièrement des patches.
[^]Re: Ok, tu veux troller...
Je pense qu'il y a des gens chez RedHat qui bossent sur Gtk que tu n'as pas compte.
Sun, leur contribution n'est pas aussi visible que celle de Ximian mais elle est fondamentale. L'ATK, c'est vraiment qqch qui permet de distinguer fortement linux et de renvoyer windows au fond du panier. Donc, s'il te plait, ne minimise pas cette contribution.
Cote Qt, Trolltech emploie 75 personnes il me semble, dont environ 60 developpeurs. Maintenant, ils ont 5 produits: Qt windows, Qt unix, Qt Mac, Qt Embedded et TeamBuilder. Plus le support, on doit arriver entre 15 et 20 personnes bossant sur Qt pour Unix.
Tiens, c'est vrai que ca fait probablement plus que Gtk.
phil.freehackers.org
[^]Re: Ok, tu veux troller...
> KDE se faisait taper sur la gueule tout le temps en disant que c'était moche
je te rassure, KDE c'est encore et toujours moche
[^]Re: Ok, tu veux troller...
J'utilise KDE depuis le début et c'était l'époque où 95% des linuxiens (ayant un desktop KDE/GNOME) utilisaient Gnome.
AMHA tu fais une erreur d'analyse.
KDE a commencé avant GNOME et a été intégré dans les distrib' avant GNOME... Dans les sondages il me semble que KDE a toujours été en tête sauf dans celui des développeurs de LinuxJournal (et ça vient de changer si j'me souviens bien)
95% d'utilisateurs de GNOME ? Tu as dus t'égarer dans le pavé numérique...
d'autant qu'à cette époque y'avait aussi beaucoup d'utilisateur de AfterStep (dont moi ;-) et de Enlightenment (qui a également été un des WM de GNOME certes...)
KDE se faisait taper sur la gueule tout le temps en disant que c'était moche et buggué. Que c'était mal conçu. Qu'il y avait pas d'applis....
les reproches de l'époque (99 ?) c'etait surtout que QT n'était pas libre...
moche... KDE 1 était quand meme assez moche (et assez lourd) mais c'est discutable...
Quand aux applis... j'me souviens qu'a ce moment la, ceux qui utilisaient KDE se servaient de AbiWord, Gimp, Gnumeric, Gftp, Xchat, donc des applis GNOME ou GTK+
[^]Re: Ok, tu veux troller...
Tres interessant. Pourtant Qt a passe pas mal de temps a peaufiner la gestion dans langues asiatiques dans Qt3. Il me semblait que pango et Qt3 avaient exactement les memes fonctionnalites.
> le rendu de KDE en japonais est immonde
Tu pourrais m'en dire plus sur les causes ? C'est juste un probleme de police ou c'est relativement complique a expliquer ?
> une fenetre par-dessus celle ou on est en train d'ecrire. Immonde, il n'y a
> pas beaucoup de japonais qui sont motives pour utiliser ca.
C'est ce que ma copine utilise pour taper du chinois sous windows et elle trouve ca normal :-) . Mais je crois que le chinois reste plus complique que le japonais de ce point de vue la. J'ai meme pas essaye de la passer sous linux encore, j'ai peur.
Est-ce que t'as des liens techniques a me fournir sur le sujet, ca m'interesse vraiment. Je savais que Gnome etait en avance au niveau accessilite mais vraiment, je croiyais que pour les langues asiatiques, KDE ou Gnome c'etait pareil.
Cettte histoire de gtk-im, je me demande d'ailleurs si c'est pas lie a l'accessibilite. En effet, atk necessite de changer de methode pour rentrer des caracteres.
Je vais me renseigner pour voir ce qu'on peut faire cote KDE. Evidemment, tout ce qu'il manque c'est un mec motive pour coder tout ca.
> Et j'ai trouve d'autres avantages a Gnome.
Je n'en doute pas. Contrairement a ce qu'on pense, je ne crache pas sur Gnome (sauf quand je l'utilise, c'est trop dur de travailler dans un environnement ou on est pas a l'aise ) et je pense qu'il peut fournir une bonne solution desktop et il y a de tres bonnes applications qui manquent sous KDE.
Mais les composants graphiques et la scriptabilite font partie des raisons pour lesquelles tout le monde a dit pendant la transition KDE1 / KDE2 que KDE c'etait de la merde parce qu'il n'utilisait pas Corba, que jamais ou qu'avoir un composant sous KDE serait super difficile alors que Corba allait trivialiser tout ca, avec du remote scripting et bla bla.
Donc j'aime a rappeler que sur ces plans, Gnome est vraiment (pour l'instant) un echec. C'est d'autant plus ironique que MDI croit a fond au principe des composants graphiques.
> les zealots de KDE disent ca depuis que Gnome existe et ca n'a jamais
> decourage ni les developpeurs ni les utilisateurs de Gnome
Tel n'est pas mon but. Je prefere juste souligner les differences techniques entre les deux. Je pense vraiment que KDE a fait des meilleurs choix techniques qui payent beaucoup sur le long terme.
L'utilisation d'un desktop ou d'un autre depend de beaucoup de facteurs emotionnels et subjectifs. Il y en a tres peu d'objectifs. Le hasard joue beaucoup aussi. Par exemple un jour, tu as cherche la fonctionnalite glorb et tu ne l'as pas trouve sur le desktop X donc tu es passe au desktop Y ou elle etait plus accessible et apres, tu vas cracher sur X parce qu'il n'a pas glorb alors qu'il l'a a un endroit different. Vous pouvez remplacer X et Y par Gnome ou KDE au choix. Il suffit de lire une thread slashdot pour voir plein de gens dans ce cas la :-)
phil.freehackers.org
[^]Re: Ok, tu veux troller...
> le rendu de KDE en japonais est immonde
Tu pourrais m'en dire plus sur les causes ? C'est juste un probleme de police ou c'est relativement complique a expliquer ?
Avec un environnement japonais depuis le debut, quand on veut saisir du japonais uniquement, pas de problemes. Mais si tu te loggues de temps en temps en francais et de temps en temps en japonais comme la config de langue et de police de KDE est independante de la locale (tu la choisis dans le panneau de controle) c'est le bordel.
De plus quand tu veux afficher du texte japonais alors que tu as un environnement francais, c'est souvent tres laid car les polices sont choisies bizarrement. Avec Pango il y a une table de correspondance des polices qui fait qu'il se base sur des polices "virtuelles" et choisit la bonne (voir /etc/pango/pangox.aliases).
C'est ce que ma copine utilise pour taper du chinois sous windows et elle trouve ca normal :-) . Mais je crois que le chinois reste plus complique que le japonais de ce point de vue la. J'ai meme pas essaye de la passer sous linux encore, j'ai peur.
Je ne pense pas, sous Windows l'IM est tres bien integree au reste. Le probleme est le suivant (pour le japonais c'est ca, pour le chinois j'imagine que c'est similaire) :
=> Il y a des milliers de caracteres, et pas autant de touches
La solution:
=> On ecrit en phonetique, en utilisant des caracteres romains directement convertis en hiragana (http://fr.wikipedia.org/wiki/Hiragana(...) ) et appuyer sur "espace" transforme ca en caracteres chinois ; si ce n'est pas la bonne combinaison on peut choisir dans une liste. Parfois les caracteres doivent rester en hiragana, on appuye juste sur entree pour les valider.
Quand on est en train d'ecrire un texte, il est important de savoir quelle partie du texte est "a convertir" et laquelle est "validee". Sous Windows ou sous Gtk+2, le texte "courant" est souligne en rouge. S'il est necessaire de changer la combinaison par rapport a celle qui a ete proposee, c'est une sorte de liste pop-up qui affiche la liste. Sous Win et Gtk+2, le popup utilise le toolkit en question. Pour Gtk+2 (independement de Gnome) gtk-im permet d'ecrire des modules pour gerer la saisie de la langue qu'on veut. Ainsi, les developpeurs de systemes de saisie sont independants de l'equipe de Gtk+.
http://im-ja.sourceforge.net/(...)
Trolltech ne s'est pas (encore ?) soucie de la saisie des langues asiatiques, ce sont donc les outils par defaut de X Window qui sont utilises. Pour le japonais c'est kinput2, et je pense que c'est le meme pour le chinois (mais qui se connecte a un serveur different pour faire la conversion pinyin->han ?)
http://www2.giganet.net/~mark/NetBSD/japanese.html(...)
En plus d'etre laid et peu configurable, kinput2 ne fonctionne que si les variables d'environnement correspondent a la langue que tu veux saisir. Pas pratique si tu veux un environnement francais et saisir du japonais ou du chinois de temps en temps. Avec une appli gtk+2, clic droit dans une zone de saisie => "methode de saisie" => "la methode que je veux" et c'est tout. Possible aussi de mettre la variable d'environnement GTK_IM_MODULE pour definir sa preference.
Est-ce que t'as des liens techniques a me fournir sur le sujet, ca m'interesse vraiment. Je savais que Gnome etait en avance au niveau accessilite mais vraiment, je croiyais que pour les langues asiatiques, KDE ou Gnome c'etait pareil.
Pas trop, mais je prepare un article pour linuxfrench. Pour conclure:
* En environnement monolingue, pour l'affichage c'est kif-kif
* Pour la saisie, Gtk+2 est meilleur
* En environnement multilingue, Gtk+2 est meilleur
Donc j'aime a rappeler que sur ces plans, Gnome est vraiment (pour l'instant) un echec. C'est d'autant plus ironique que MDI croit a fond au principe des composants graphiques.
Je n'aime pas MDI, il a fait de bonnes choses pour Gnome mais aussi des conneries, et surtout il en raconte beaucoup (des conneries). Je pense que Corba est plus un choix philosophique.
* Approche KDE: developper notre propre systeme de composant (KPart) sera plus facile et marchera mieux. C'est vrai.
* Approche Gnome: une norme a ete etablie par l'OMG pour l'echange de composant, c'est Corba, utilisons-la comme ca si d'autre la prennent aussi (par exemple KDE) alors il sera facile de faire des echanges entre les projets. C'est vrai aussi. Gnome n'a pas choisi la voie de la facilite, mais la voie qui leur semblait "droite".
L'utilisation d'un desktop ou d'un autre depend de beaucoup de facteurs emotionnels et subjectifs. Il y en a tres peu d'objectifs. Le hasard joue beaucoup aussi. Par exemple un jour, tu as cherche la fonctionnalite glorb et tu ne l'as pas trouve sur le desktop X donc tu es passe au desktop Y ou elle etait plus accessible et apres, tu vas cracher sur X parce qu'il n'a pas glorb alors qu'il l'a a un endroit different. Vous pouvez remplacer X et Y par Gnome ou KDE au choix.
Oui, mais en l'occurence apres des annees d'utilisations de KDE, contribution a KDE (j'ai co-redige le manuel de Konqueror pour KDE 2), je suis passe a Gnome pour une raison parfaitement objective. J'etais a Tokyo depuis plus d'un an, tout ce temps j'avais galere pour essayer de saisir du japonais ayant un environnement anglais sous KDE. Je dis bien anglais, car en francais avec les accents ce n'etait pas la peine.
J'en arrivait a utiliser Windows XP de plus en plus car il me permettait une saisie vraiment multilingue. J'en arrivait a penser que Linux etait incapable de faire du multilingue correctement, et que comme peu de gens ont besoin de melanger 2 langues differentes de l'anglais ca ne risquait pas de changer. Quand KDE3 est arrive c'etait moins laid ; mais on ne pouvait toujours pas melanger accents et kanji facilement, et la langue des menus et les polices restaient independantes des variables d'environnement. L'immonde kinput2 etait toujours la.
A l'arrivee de Gnome 2, peut-etre Gnome 2.2 en fait, il y a eu Pango qui rendait systematiquement bien les polices, et im-ja. J'ai change pour une raison parfaitement objective : ca m'a permet de virer definitivement Windows, qui etait presque redevenu mon OS principal (si si).
Mais je ne denigre pas KDE pour autant, ca reste un tres bon projet qui a ses avantages sur Gnome. Et je suis content qu'il y aie 2 desktops, car un systeme GNU/Linux n'est pas un OS unique mais un assemblage de briques ou on peut choisir chaque module. Avoir le choix n'est jamais une mauvaise chose. Ca me gene quand tu parles "d'annees lumiere", KDE n'est pas "objectivement plus avance" que Gnome, puisqu'il y a plusieurs aspects.
Concernant les avantages de Gnome sur KDE et vice-versa, chacun va s'ameliorer et d'autres points apparaitront. Ce qui restera constant c'est une difference de philosophie, surtout depuis Gnome 2 ; par exemple KDE est ultra-configurable et permet a l'utilisateur de se faconner son bureau comme il l'aime, et Gnome tends a proposer un bureau simple qui n'offre que les choix minimum a l'utilisateur pour ne pas le noyer dans les boites de dialogues, et oblige le "power-user" a bidouiller gconf s'il veut avoir des choses vraiment "a part".
[^]Re: Ok, tu veux troller...
Très intérèssant ce que tu dis. Il est vrai que j'avais remarqué ce petit menu pour configurer le mode de saisie dans les applis Gnome. C'est clair que de ce coté là Qt et/ou KDE devrait y penser.
Il n'y a rien rien de mieux que la concurrence de projets et les trolls pour mieux connaitre ce qui existe ou motiver le projet "concurrent" de récupérer les bonnes choses d'un autre :))
[^]Re: Ok, tu veux troller...
Pour la saisie du chinois, c'est vraiment compliqué. De ce que j'ai compris, il faut quatre touches pour former un caractère. Chaque touche doit donc représenter une composante.
Je vais soulever le problème de la saisie des langues asiatiques, on verra bien si il y a des réponses.
phil.freehackers.org