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.
Journal Gnome Office et KOffice
18
sept.
2003
# Re: Gnome Office et KOffice
Posté par Austin . Évalué à 4.
- "c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome."
- "Gnome est carrément à des années lumières de retard."
Gnome a aussi des trucs qui rox à mort.
Maintenant si c'est ton avis est que Gnome est à des années lumières de retard (année lumière est une unitée distance et non de temps), tu devrais faire un journal pour expliquer pourquoi il y a autant de bonnes applis sous Gnome et pourquoi il y a autant de développeurs maso pour bosser sous Gnome. Ça serait très intéressant pour mieux connaitre la psychologie du hacker.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 2.
Je ferai un autre journal sur les autres elements en effet, ca promet d'etre interessant. Par exemple il y a eu pas mal de FUD sur KDE, repandu par la communaute du logiciel libre.
[^] # Re: Gnome Office et KOffice
Posté par Austin . Évalué à 4.
Je vais t'aider pour les arguments de ton prochain journal :
http://kdemyths.urbanlizard.com/(...)
# Ok, tu veux troller...
Posté par Erwan . Évalué à 3.
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...
Posté par Infernal Quack (site web personnel) . Évalué à 1.
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.
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: Ok, tu veux troller...
Posté par Austin . Évalué à 4.
"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...
Posté par Prosper . Évalué à 1.
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...
Posté par Austin . Évalué à -1.
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...
Posté par Philippe F (site web personnel) . Évalué à 1.
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 ?
[^] # Re: Ok, tu veux troller...
Posté par Prosper . Évalué à 1.
[^] # Re: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Ok, tu veux troller...
Posté par Nap . Évalué à 1.
[^] # Re: Ok, tu veux troller...
Posté par Austin . Évalué à 0.
Le monde est vraiment trop injuste :-(
> contrats
C'est quoi ?
[^] # Re: Ok, tu veux troller...
Posté par Christophe Fergeau . Évalué à 3.
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...
Posté par Philippe F (site web personnel) . Évalué à 1.
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.
[^] # Re: Ok, tu veux troller...
Posté par Christophe Fergeau . Évalué à 5.
je te rassure, KDE c'est encore et toujours moche
[^] # Re: Ok, tu veux troller...
Posté par j (site web personnel) . Évalué à 1.
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...
Posté par Philippe F (site web personnel) . Évalué à 2.
> 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 :-)
[^] # Re: Ok, tu veux troller...
Posté par Erwan . Évalué à 3.
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...
Posté par Infernal Quack (site web personnel) . Évalué à 1.
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 :))
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: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . Évalué à 1.
Je vais soulever le problème de la saisie des langues asiatiques, on verra bien si il y a des réponses.
# Re: Gnome Office et KOffice
Posté par ploum (site web personnel, Mastodon) . Évalué à -1.
Il avait presque pas servi !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Gnome Office et KOffice
Posté par Nap . Évalué à 3.
La prochaine fois, n'achete pas n'importe quoi sous pretexte d'un prix avantageux. En plus tu soutiens la délocalisation des usines dans les pays ou la main-d'oeuvre est moins chère.
Ca fait longtemps que tous les trollometres bas de gamme ont été décimés sur ce site, on en trouve plus que sur les forums hardwarefr et sur le chat de caramail, et encore. Il n'y a plus que les modèle en titane renforcé, avec armatures en cryptonite, qui resistent ici (mais pour combien de temps ?? le mien date d'à peine un mois et il est déjà fissuré de partout, et j'ai pas payé l'extension de garantie, c'est exorbitant pour ces machins là)
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 3.
Oui, les gens ont des opinions assez forte sur KDE et Gnome. Mais si les opinions sont argumentees et constructives, je ne vois pas pourquoi on devrait se taire. Au contraire, le debat est tres enrichissant et on apprend tous des choses.
Evidemment, faut eviter de ressasser les memes arguments toutes les semaines mais une fois de temps en temps, ca fait du bien.
[^] # Re: Gnome Office et KOffice
Posté par Nap . Évalué à 1.
sinon gnome roxx
(désolé j'ai pas pu m'en empécher)
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 1.
D'un autre cote:
- le fait d'avoir deux desktop a permis de voir deux technologies differentes, c'est interessants.
- il y a des developpeurs Gnome que je ne voudrai jamais voir coder pour KDE tellement ils sont obtus.
- les bonnes idees de l'un poussent l'autre a s'ameliorer. Mais rien ne dit que avec un seul projet, ce genre de bonne idee n'arriverait pas aussi.
[^] # Re: Gnome Office et KOffice
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Gnome Office et KOffice
Posté par Austin . Évalué à 1.
Il y a aussi des mecs chez KDE qui calme le jeux. Je me rappèle du "scandale" qu'avait fait la RH8.0. Pourtant il y avait des devs de KDE qui comprenaient la position de RedHat et estimais qu'il était ridicule de se facher avec RedHat. Par contre il y a un "troupeau" de supportaire inconditionnel qui ne veux pas prendre 3 mm de recul.
Je me rappèle aussi le "scandale" qu'a fait un développeur SuSE alors qu'il voulais simplement utiliser glib pour arts.
Mais finalement je crois que depuis freedesktop.org jamais Gnome et KDE n'ont autant bossé ensemble.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 1.
> Par contre il y a un "troupeau" de supportaire inconditionnel qui ne veux pas prendre 3 mm de recul.
Il faut dire que Red Hat a un passé très très chargé avec KDE:
- FUD sur les premières licences de Qt
- refus de distribuer les premiers KDE
- pas de packaging des release KDE en dehors des release RedHat
- des bugs qui rendent KDE inutilisable en autre chose qu'anglais
- des modifications qui font que l'utilisateur qui suit la documentation n'arrive pas à faire fonctionner son matériel (KDE)
- un commercial qui propose un stand à KDE à une expo linux et ensuite nous envoie chier comme des malpropres.
- renommage en série de pleins de composants du Kontrol Center, ce qui les rendait potentiellement incompatible avec une appli exterieure voulant les utiliser
- suppression du 'About KDE' qui, s'il est légal, n'est certainement pas très apprécié.
- développement d'un <<faux KDE>>, c'est à dire un panel avec les icones KDE mais où aucun des programmes lancé n'est KDE.
Et plein d'autres petites broutilles. Donc à chaque fois qu'on parle de RedHat, tout le monde sur KDE se méfie. Si on pouvait éviter de packager KDE pour RedHat, je pense qu'on le ferai. Malheureusement, ils ont tout le marché d'amérique du nord. Une chose est claire en tout cas, les utilisateurs de KDE sous RedHat utilisent en général une sous-version.
Pour ce qui est des mecs de Gnome, j'ai pas beaucoup aimé l'attitude de pas mal d'entre eux au moment des flameware et autres soucis des release de Gnome. Mais je ne pourrai pas vous donner de noms.
[^] # Re: Gnome Office et KOffice
Posté par Christophe Fergeau . Évalué à 1.
?
tu veux dire par rapport au changement de l'ordre de bouton, à l'interface pour neuneu et tout ça ?
Bon, c'est vrai que sur ce point là, y en a probablement un certain nb qu'ont adopté une attitude "on a décidé que c'était comme ça, maintenant arrêter de faire chier" mais faut dire que c'est quand même assez saoulant à force ce genre de critiques venant de qques mecs, donc c'est compréhensible même si c'est pas très subtil comme comportement :)
[^] # Re: Gnome Office et KOffice
Posté par Erwan . Évalué à 1.
Elle ne seront pas toutes applicables, car si on fait un choix d'architecture on se ferme certaines portes.
[^] # Re: Gnome Office et KOffice
Posté par Christophe Fergeau . Évalué à 2.
En tout cas ce qui est marrant, c'est que j'ai l'impression que c'est toujours des mecs de chez KDE qui lancent ce genre de trucs "KDE c'est plus mieux, les technos GNOME sont pourries", "c'est degoutant, GNOME ils sont aidés par des grosses boites, c'est pour ça qu'ils avancent vite", ... Et à force, c'est lassant, à quoi ça sert de tirer dans les pattes de l'autre. Autant soit bosser, soit aller boire des coups tous ensemble, mais ce genre de discussion n'est pas super intéressante.
[^] # Re: Gnome Office et KOffice
Posté par Austin . Évalué à 0.
KDE est à des années lumière en retard de Gnome technique. Mais ça a toujours été comme ça, les technologies Gnome ont toujours étés supérieures et en avances sur les technologies KDE.
Je pense même que programmer une application en Qt/KDE 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.
Le point important, c'est que les technologies Gnome sont plus avancées et permettent de faire des choses beaucoup plus facilement.
Question : C'est un troll ?
Si la réponse est "oui", alors tu trolles.
Juste pour info sur l'utilisation de bonobo :
$ rpm -e --test libbonoboui 2>&1 | wc
54 380 4296
[^] # Re: Gnome Office et KOffice
Posté par wismerhill . Évalué à 2.
[^] # Re: Gnome Office et KOffice
Posté par j (site web personnel) . Évalué à 1.
un exemple (parmis d'autres) dans ton cas :
http://linuxfr.org/comments/186800,1.html(...)
(extrait de http://linuxfr.org/2003/03/24/11795.html(...) )
# Re: Gnome Office et KOffice
Posté par Vivi (site web personnel) . Évalué à 4.
à côté, Gnome a relativement peu de références sur bonobo, et elles sont très récentes.
entièrement d'accord. À mon avis, ils ont fait une grosse erreur là. Y'a plein de gens qui aimerait développer des trucs bonobo mais qui ne comprennent pas trop les techniques. Y'a 2-3 tutoriaux de quelques lignes qui traînent mais en pratique ça ne sert pas beaucoup.
Corba a coûté très cher a Gnome en temps de développement et en complexité,
bof, toute la couche CORBA est cachée dans bonobo, la complexité sous-jacente n'apparaît pas quand on programme une appli bonobo.
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.
humpf, je sais pas trop : rien ne t'empêche de définir des méthodes CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.
La simplicité d'implémentation de kpart (bibliothèques partagées) fait que le debuggage est grandement simplifié.
A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que tu peux avoir le composant dans un processus séparé.
c'est que les technologies KDE sont supérieures et en avances sur les technologies Gnome
mouais. supérieures ? tu nous dis "Bonobo, c'est compliqué et y'a pas de docs, kparts c'est plus simple. Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop". De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 1.
> > complexité,
> bof, toute la couche CORBA est cachée dans bonobo, la complexité
> sous-jacente n'apparaît pas quand on programme une appli bonobo
Oui, mais cacher cette complexite a pris beaucoup de temps, et c'est pour ca que bonobo est aussi peu developpe a l'heure actuelle.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Tant que t'as pas d'exemple concret, ca veut rien dire. Perso, j'ai apprecie de pouvoir comprendre comment fonctionnait kpart en lisant du code pendant une demi-heure, alors que je ne connaissais rien a KPart et aux bibliotheques partagees.
> humpf, je sais pas trop : rien ne t'empêche de définir des méthodes
> CORBA pour manipuler ton composant si tu n'aime pas les property bags il me semble.
Moui, mais tout de suite, c'est plus complique. Avec un kpart, une fois que tu as remplace ton pointeur MyApplicationWidget par MyApplicationKPart, toutes les methodes a appeler restent les memes donc n'as pas plus de code a changer.
> A prioiri, je dirais que le debuggage est plus simple avec bonobo vu que
> tu peux avoir le composant dans un processus séparé.
Ce n'est qu'un a priori, qui s'est revele faux dans la pratique. Le fait d'avoir un processus separe fait que tu as peu de controle quand qqch plante, et il reste des processus qui tournent en arriere plan, parfois sans que tu t'en rendes compte.
Avec un kpart (dixit David Faure, qui a bosse a la fois sur la partie Corba de KDE a l'epoque ou KDE faisait du corba et sur la parti KPart), c'est beaucoup plus franc. Ca plante, tu le vois tout de suite et tu as un core pour debugger.
Debugger un kpart est egalement plus simple parce que, quand tout est dans le meme processus, tu peux poser un breakpoint et faire tourner ton debuggeur sans souci. Avec plusieurs processus, il te faut pas mal de debuggage en parallele, pas forcement facile a mettre en place: un pour le serveur corba, un pour le composant, un pour l'hote du composant. Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.
> Bonobo a techniquement plus de possibilités mais ça ne sert à rien pour le desktop".
De fait. Et certaines manquent pour le desktop. Combien de temps faut-il pour lancer un processus et pour charger une bibliotheque partagee a ton avis ? Qu'en est-il de l'occupation memoire ? Et je me repete mais le fait que l'api soit plus complexe a utiliser est penible.
> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops. Superieur dans l'absolu ne veut rien dire. Superieur dans le cadre d'une utilisation en desktop oui.
[^] # Re: Gnome Office et KOffice
Posté par Austin . Évalué à 2.
C'est l'avantage de bonobo. Si un composant plate, l'appli reste utilisable (avec une fonctionnalitée en moins).
> Superieur dans le cadre d'une utilisation en desktop oui.
Gnome et KDE c'est pour le desktop.
Ce n'est pas un serveur web et ça ne sert à rien pour faire le café ou prendre sa douche.
[^] # Re: Gnome Office et KOffice
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Ca explique peut-être ça :
http://shift.free.fr/trash/nautilus1.png(...)
L'application plante mais continue puis replante mais continue et re-re-plante mais continue.............. et se termine en feu d'artifice qui prends 100% du cpu et de la mémoire :)
/o\ Non je trolle 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: Gnome Office et KOffice
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Gnome Office et KOffice
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Gnome Office et KOffice
Posté par Austin . Évalué à 2.
J'ai un peu faux car maintenant bonobo peut aussi être utilisé avec des librairies (fichier .so).
Gnome 2.4 utilise ça.
La description des composants disponibles est ici :
/usr/lib/bonobo/servers
L'avantage visible c'est la vitesse.
> http://shift.free.fr/trash/nautilus1.png(...)
Joli
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . Évalué à 1.
> utilisable (avec une fonctionnalitée en moins).
En général, l'appli n'est pas très utilisable sans son composant. Mais pense au cas inverse, où l'appli plante mais le composant continue à tourner en arrière plan comme un malade.
Ce genre de truc est une horreur à debugger. KDE en a souffert et ca les a motivé a passer a kpart. Gnome en a souffert aussi (décolé, j'ai plus les liens mais on trouve qqs references dans les gnome foundation meeting)
[^] # Re: Gnome Office et KOffice
Posté par Vivi (site web personnel) . Évalué à 1.
certes ;)
Mais pense au cas inverse, où l'appli plante mais le composant continue à tourner en arrière plan comme un malade.
bah, le composant c'est un serveur, si personne ne l'utilise il toune pas "comme un malade", il ne fait rien, comme n'importe quel daemon. Et puis ORBit est capable de détecter si une connexion est coupée et peut donc arrêter le composant.
[^] # Re: Gnome Office et KOffice
Posté par Vivi (site web personnel) . Évalué à 1.
deux process à debugger: un pour le composant, un pour l'appli.
Il faut s'attacher en cours de route au processus qui a ete lance par le serveur, etc etc.
non pas forcèment : tu lances le serveur sous contrôle du débuggeur, c'est tout.
> De là à conclure que les technos KDE sont "supérieures", je vois pas trop. Plus adaptées au desktop peut-être.
Ben c'est la meme chose non ? KDE et Gnome, c'est des desktops.
Hum, pas sûr. GNOME c'est un desktop ET une plateforme de développement. Les applis développées avec les bibliothèques GNOME peuvent avoir besoin des capacités réseau des composants par ex. Il se trouve que le desktop construit avec les bib. GNOME n'en tire pas parti parce qu'il n'en a pas trop besoin.
Moi, perso je m'en fout un peu du desktop : j'utilise qq applis GNOME, un peu le panel. Par contre c'est bien d'avoir des bibliothèques de développement puissantes et flexibles.
# HS, mais je sais pas trop où troller là dessus
Posté par Christophe Fergeau . Évalué à 2.
J'avais juste quelques remarques:
* Je n'ai pas vu à quel endroit la doc indiquée conseille d'utiliser du c++
* La doc date de l'an 2000, la glib 2 et gnome 2 sont de toute évidence prévus pour un lointain futur...
Sinon ça serait sympa d'éviter le FUD quand tu tentes de montrer que kde est plus mieux que gnome, la moitié de ce journal contient essentiellement des affirmations totalement non argumentées comme quoi kde est mieux que gnome...
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Aucun sens de l'humour ici..
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par Vivi (site web personnel) . Évalué à 1.
on est d'accord
While producing a wrapper is quite easy for C, maintaining it is very burdensome, because every maintainer must add manually all the wrapping code. As gnome and gtk evolves, this turns out to be quite painful. This why many wrapper only do gtk and/or wrap old versions of Gtk or Gnome.
Y'a eu beaucoup de changements lors du passage Glib/GTK -> Glib2/GTK2. Maintenant les API sont beaucoup plus régulières et une trés grande part du wrapping peut se faire automatiquement.
While producing a wrapper for C++ is initially harder, once you have done it, you can automate most of the task.
je vois pas pourquoi ça serait plus facile qu'en C.
Since KDE is written in a higher language than Gnome, there is less need to program in another easier to use language.
merci de me laisser choisir le langage dans lequel je veux développer
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par Philippe F (site web personnel) . Évalué à 1.
> Maintenant les API sont beaucoup plus régulières et une trés grande part du wrapping peut se faire automatiquement.
Je ne suis pas sur que les binding aient déjà switché vers le nouveau système.
Aller, puisqu'on dit que je suis trop trolleur avec Gnome, je vais vous parler des défauts de KDE:
- il y a un binding python maintenu en dehors de KDE
- en théorie, il y a un binding java qui est généré automatiquement mais il n'est pas utilisé et ne marche jamais
- un binding ruby a été généré en one-shot mais il n'est pas maintenu (à ma connaissance)
- il y a le super système développé par David pour les binding perl, pour automatiser la génération des bindings mais je ne pense pas qu'il soit utilisé
- il y a un binding c-sharp mais là encore, je ne sais pas où il en est et je ne crois pas qu'il utilise le truc de David
Bref, c'est le bordel et la situation est loin d'être fantastique. Le seul truc bien, c'est que les binding Qt et KDE sont en général nickel.
> > While producing a wrapper for C++ is initially harder, once you > > have done it, you can automate most of the task.
> je vois pas pourquoi ça serait plus facile qu'en C.
Parce que le C++ donne un certain nombre d'informations dans sa syntaxe:
- quels sont le membres publics ou privés
- quels sont les constructeurs ou les desctruteurs
- y a-t-il un rapport d'héritage avec une autre classe
- certains fonctions doivent pouvoir être surchargées
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par Christophe Fergeau . Évalué à 1.
Pour les bindings gtk+, ceux pour le c++ et le python sont à jour et maintenus (à jour == y a une version wrappant gtk 2.0 stable)
Y en a aussi pour perl et ruby, ils wrappent gtk2/gnome2 mais je sais pas trop à quel état d'avancement ils en sont.
Et il y a bien évidemment gtk#.
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par Vivi (site web personnel) . Évalué à 1.
# On va me dire que je triche, mais...
Posté par Christophe Fergeau . Évalué à 1.
gnome-terminal --window --execute "ssh blah"
gnome-terminal --tab --execute "ssh bleh"
gnome-terminal --tab --execute "ssh bloh"
La version pour gnome est beaucoup plus courte que ton script, ça prouve indéniablement que gnome est infiniment supérieur à KDE ;)
Sérieux, y a mieux à faire que lancer des débats stériles sur X est supérieur à Y
[^] # Re: On va me dire que je triche, mais...
Posté par wismerhill . Évalué à 1.
[^] # Re: On va me dire que je triche, mais...
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: On va me dire que je triche, mais...
Posté par Philippe F (site web personnel) . Évalué à 1.
http://cvs.gnome.org/lxr/source/gnome-terminal/src/terminal.c(...)
Ce qu'il en ressort, c'est qu'il faut faire:
gnome-terminal --window --execute "ssh blah" --tab --execute "ssh bleh" --tab --execute "ssh bloh"
Le grosse difference par rapport a KDE, c'est que on peut controler un terminal au moment ou on le lance, mais il n'est pas possible de controler un terminal une fois qu'il est lance.
Pour etre honnete, dans cet exemple precis, je ne vois pas bien de situation ou on pourrait vouloir modifier un terminal existant en lui rajoutant des sessions ssh.
Cependant, cet exemple illustre bien mon point sur le technos KDE et Gnome:
- gnome-terminal n'utilise pas de technos particuliere et on est restreint a passer des arguments en ligne de commande. Il faut ecrire pas mal de code pour parser la ligne de commande.
- konsole utilise la techno dcop et expose ainsi un certain nombre de methodes. Tout ce qu'il a fallu rajouter au code pour permettre ca, c'est la definition d'une "interface" :
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/konsole/konsole/ko(...)
Les methodes qui sont listees ici sont les methodes utilisees de facon interne par konsole pour gerer ses sessions et fenetres.
C'est en rendant l'utilisation de ses technos avancees aussi simple que KDE prend a mon avis un leadership technologique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.