C'est tres simple, RedHat externalise ses resources de developpements vers la communaute pour se concentrer sur le fric. :-)
Mine de rien, c'est une bonne strategie. Ils esperent aussi probablement regagner des places en tant que distro grand utilisateur. Enfin, a pense qu'ils en ont perdu.
Qui fait tourner une RedHat pour le plaisir ici ? Perso, j'en vois pas l'interet:
- tes fan de compilation et de custojmisation: gentoo ou slackware
- t'es fan de je-fais-rien-et-ca-marche-tout-seul meme pour ma grand-mrere: Mandrake
- t'es fan de c-est-libres-a-mort-et-on-fait-pas-de-concession: debian.
Concretement, hors environemment professionnel, je ne vois pas de raisons d'utiliser une RedHat
j'ai des problemes de refroidissement sur mon bi-pro, il a tendance a freezer a cause de la montee en temperature quand je compile un paquet (vive les gentoo).
Donc, je cherche des trucs pour diminuer les vitesses de compilation :-)
Apres etre passe en -j1 sur un bi-pro, pour que un processeurs se repose quand l'autre travaille, j'envisage un hdparm optimise pour etre plus lent!
Ca va etre encore pire a mon avis, puisque justement, sa machine pedale en memoire. Le probleme, c'est que ZoneAlarm (firewall) + msn + machin + bidule + utilitaire pour le clavier en chnois + outlook + mozilla + windows XP + word , ca fait trop pour la petite machine qui est pourtant loin d'etre un escargot.
D'ailleurs, la lenteur n'est pas seulement au moment ou elle le lance, c'est aussi au niveau de l'affichage, quand elle switch d'application. Faut dire que je lui ai colle mozilla, qui est a mon avis une tres mauvaise idee car il a tendance a ouvrir facilement beaucoup de fenetres. Je vais retenter avec FireBird.
Notons que chez moi, j'ai note que firebird est aussi tres lent au niveau de l'affichage des pages (pas du rendu, de l'affichage).
Pour le coup de la barre de recherche, c'est que je voudrai que par defaut, ce soit google. Or par default, il me fait une recherche dans la page.
Pour ce qui est de XML, XUL et tout ca, certe c'est bien mais c'etait possible de produire un bon browser sans developper _tout_ au prealable. Normalement, on devrait etre capable de faire evoluer le framework et les clients en meme temps.
khtml est relativement independant de KDE, preuve en est qu'il a ete porte sous Atheos, BeOs ou pour MacOs (Safari).
Je ne retrouve plus le lien mais quelqu'un etait en train d'isoler la partie de khtml qui depend de qt/kde dans une bibliotheque, de facon a pouvoir le porter encore plus facilement. Pour info, c'est ce qu'a fait apple avec safari.
Sinon, tu peux jouer avec un gtksocketplug et qxembed pour embedder un widget kde dans une appli gtk. J'ai deja fait l'inverse (gvim dans un widget kde, cf le projet kvim) et ca marche pas trop mal.
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" :
> 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.
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
> C'est l'avantage de bonobo. Si un composant plate, l'appli reste
> 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)
Mon impression, c'est que il y a une très petite minorité de developpeurs cons ou problématiques (Neil et Mosfet par exemple) et une très grande majorité de développeurs intelligents, réfléchis, qui discutent argumentent et comme tu le dis, calme le jeu. Par exemple, j'ai un immense respect pour Waldo Bastian qui fait toujours des interventions justes.
> 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.
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.
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.
Je suis tout fait d'accord avec toi. Je pense qu'on peut comparer le programmeur a un artisan. Il met dans un programme son savoir-faire, souvent son amour-propre et sa fierte.
On se rapproche un peu de l'art, comme tout artisan. En tout cas, on a clairement un style.
Bof. J'en suis pas persuade. Tout irait plus vite si tout ce monde la bossait sur un seul projet au lieu de deux. Je ne pense pas qu'il y aurait moins d'idees.
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.
> > 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
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.
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 ?
Tiens, je voulais dire au passage que j'en ai marre qu'on crie au Troll qu'il faut tuer dans l'oeuf des qu'on parle de KDE ou de Gnome et de leurs avantages/inconvenients.
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.
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 :-)
Desole pour les repetitions. Quand on ecrit un truc long, on s'y perd un peu.
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.
> Ça casse du Gnome puis ça fait de la pub KDE.
> J'aime bien ce type de commentaire car l'auteur est "démasqué".
J'exprime mon opinion sur Gnome et KDE. Mon dieu, je suis démasqué, j'ai une opinion! T'es vraiment trop fort!
As-tu remarqué avec ta perspicacité que je fournis des arguments pour supporter mon opinion ? Ca fait une grosse différence avec ton post qui est complètement vide, genre je parle pour me rendre intéressant mais j'ai rien à dire.
> J'espère pour toi que t'y vois pas Gnome ça pourrait te rendre malade.
Si j'y vois Gnome et non, ca ne me rend pas malade car je vois aussi que Gnome a quelques années lumières de retard sur KDE et que c'est pas près de changer. Le seul point sur lequel Gnome assure, c'est sur l'accessibilité.
[^] # Re: Et si je codais un outil d'administration d'impression....
Posté par Philippe F (site web personnel) . En réponse au journal Et si je codais un outil d'administration d'impression..... Évalué à 1.
[^] # Re: Red Hat Linux annonce la naissance du projet Fedora
Posté par Philippe F (site web personnel) . En réponse à la dépêche Red Hat Linux annonce la naissance du projet Fedora. Évalué à 0.
Mine de rien, c'est une bonne strategie. Ils esperent aussi probablement regagner des places en tant que distro grand utilisateur. Enfin, a pense qu'ils en ont perdu.
Qui fait tourner une RedHat pour le plaisir ici ? Perso, j'en vois pas l'interet:
- tes fan de compilation et de custojmisation: gentoo ou slackware
- t'es fan de je-fais-rien-et-ca-marche-tout-seul meme pour ma grand-mrere: Mandrake
- t'es fan de c-est-libres-a-mort-et-on-fait-pas-de-concession: debian.
Concretement, hors environemment professionnel, je ne vois pas de raisons d'utiliser une RedHat
[^] # Re: Pour un boot encore plus rapide de Linux...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
Je sais qu'au moment de KDE 2, ils s'etaient tues les meninges pour trouver quoi enlever et comment faire pour le lancer plus vite sans rien retirer.
[^] # Re: Pour un boot plus rapide de Linux
Posté par Philippe F (site web personnel) . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 3.
j'ai des problemes de refroidissement sur mon bi-pro, il a tendance a freezer a cause de la montee en temperature quand je compile un paquet (vive les gentoo).
Donc, je cherche des trucs pour diminuer les vitesses de compilation :-)
Apres etre passe en -j1 sur un bi-pro, pour que un processeurs se repose quand l'autre travaille, j'envisage un hdparm optimise pour etre plus lent!
[^] # Re: Red Hat Linux annonce la naissance du projet Fedora
Posté par Philippe F (site web personnel) . En réponse à la dépêche Red Hat Linux annonce la naissance du projet Fedora. Évalué à -1.
[^] # Re: about:config
Posté par Philippe F (site web personnel) . En réponse au journal Mozilla Firebird. Évalué à 1.
D'ailleurs, la lenteur n'est pas seulement au moment ou elle le lance, c'est aussi au niveau de l'affichage, quand elle switch d'application. Faut dire que je lui ai colle mozilla, qui est a mon avis une tres mauvaise idee car il a tendance a ouvrir facilement beaucoup de fenetres. Je vais retenter avec FireBird.
Notons que chez moi, j'ai note que firebird est aussi tres lent au niveau de l'affichage des pages (pas du rendu, de l'affichage).
[^] # Re: Mozilla Firebird
Posté par Philippe F (site web personnel) . En réponse au journal Mozilla Firebird. Évalué à 1.
Pour ce qui est de XML, XUL et tout ca, certe c'est bien mais c'etait possible de produire un bon browser sans developper _tout_ au prealable. Normalement, on devrait etre capable de faire evoluer le framework et les clients en meme temps.
[^] # Re: par logiciel ?
Posté par Philippe F (site web personnel) . En réponse au journal interview du PDG de Trolltech: transcription. Évalué à 1.
Donc, toujours pas de volontaires ? snif. A part Pascal evidemement.
[^] # Re: Alternative à GtkHtml2 ?
Posté par Philippe F (site web personnel) . En réponse au journal Alternative à GtkHtml2 ?. Évalué à 2.
Je ne retrouve plus le lien mais quelqu'un etait en train d'isoler la partie de khtml qui depend de qt/kde dans une bibliotheque, de facon a pouvoir le porter encore plus facilement. Pour info, c'est ce qu'a fait apple avec safari.
Sinon, tu peux jouer avec un gtksocketplug et qxembed pour embedder un widget kde dans une appli gtk. J'ai deja fait l'inverse (gvim dans un widget kde, cf le projet kvim) et ca marche pas trop mal.
[^] # Re: On va me dire que je triche, mais...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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.
[^] # Re: HS, mais je sais pas trop où troller là dessus
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. Évalué à 1.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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 Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: La programmation est un art
Posté par Philippe F (site web personnel) . En réponse à la dépêche La programmation est un art. Évalué à 2.
On se rapproche un peu de l'art, comme tout artisan. En tout cas, on a clairement un style.
[^] # Re: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. Évalué à 1.
[^] # Re: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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 Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Ok, tu veux troller...
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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: Gnome Office et KOffice
Posté par Philippe F (site web personnel) . En réponse au journal Gnome Office et KOffice. É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 1.0
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME Office 1.0. Évalué à -1.
> J'aime bien ce type de commentaire car l'auteur est "démasqué".
J'exprime mon opinion sur Gnome et KDE. Mon dieu, je suis démasqué, j'ai une opinion! T'es vraiment trop fort!
As-tu remarqué avec ta perspicacité que je fournis des arguments pour supporter mon opinion ? Ca fait une grosse différence avec ton post qui est complètement vide, genre je parle pour me rendre intéressant mais j'ai rien à dire.
> J'espère pour toi que t'y vois pas Gnome ça pourrait te rendre malade.
Si j'y vois Gnome et non, ca ne me rend pas malade car je vois aussi que Gnome a quelques années lumières de retard sur KDE et que c'est pas près de changer. Le seul point sur lequel Gnome assure, c'est sur l'accessibilité.