C'est quoi ton problème ?
L'extention ajouté par gtk+ est pourtant très "C++".
L'explication sur le + est donnée par le développeur de gimp/gtk et non par un développeur Gnome. Cette extention est définitivement un plus. Afin, les extensions gtk+ sont pour tout les programmes qui utilisent gtk+ et non pour Gnome. Le but de Gnome est de faire un bureau et offrir des fonctionnalités pour le développement d'appli (evolution, galeon, gnucash, xchat, gnomemeting, etc...). C'est principalement des extensions pour les developpeurs d'appli et non uniquement pour Gnome. D'ailleur, les widgets spécifiques gnome se trouve dans gnome-lib et non dans gtk+.
je n'ai aucun probleme, Gtk+ est de l'assez bon c OO (en non oriente c++)
maintenant il faut etre realiste sur le fait que c'est surtout la volonte d'un tk puissant comme base de gnome qui a entraine le split. Le fait qu'il peut aussi etre utiliser en dehors de gnome, c'est vrai aussi le but de Gtk+ n'etait pas de devenir le tk de gnome, mais plutot le tk utilise comme base par gnome. On peut faire le meme parrallele sur certaines evolutions de Qt (ex: le changement de licence) qui ont etes a l'origine entrainees par l'utilisation de Kde puis pouvant etre reutilisees par les autres projets.
> dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide)
Développé par RedHat dans le cadre du projet Gnome, et en C. Y a même un binding python :-)
Oui, c'est bien vrai, mais surtout essentielement developpe par une seule personne (veritable tour de force)
-- Troll detected --
que sous-entend tu par "re-coder un mini-WM dans les widgets" ?
sinon pour ton info les MDI peuvent se fait tres simplement avec kde mais je voit pas le lien entre les MDI et les menus flottants ;(
Personnellement, je pense que l'option UI IDEAI de kdevelop est bcp plus ergonomique que des menus flottants. A qd cette fonctionnalite dan the gimp (avec aussi un vrai support des calques digne de ce nom) ?
> Ben je pense que la problematique du "power user" qui veut pouvoir customizer son envirronement sans necessairement etre admin est un vrai probleme.
Ben trouve moi un cas où tu as besoin de connaitre l'existence de gconf pour customizer ton environnement.
gconftools est pour fixer les valeurs par défauts aux nouveauxcomptes ou imposer des valeurs (par exemple pour un proxy). gconftools est donc pour les admins (d'ailleur il faut être root pour modifier des valeurs).
Sous gnome, je ne pourrait pas te sortir d'exmple, maintenant sous kde vu que le control-center ressemble plus a un tableau de bord d'un cockpit d'avion, il est grand temps de separer le "vital" de ce qui n'est que de l'"ultra customizable eye-candies and features"
> lorsque je lance gnome
Damned, pour quelqu'un qui n'arrête pas de critiquer gnome. Mais je pense que tu veux dire "lorsque je lance des applis gnome".
Faut pas croire, je ne critique pas essentielement gnome, meme si cela y ressemble. Je cherche juste a equilibrer les choses par rapport au gros pre-juges (trolls?) sur kde (je remonte aussi gnome de nombreuses fois).
Maintenant il m'arrive bien de lancer gnome (avec le desktop et tout et tout) lors de tests d'integration ou regulierement quand je casse mon kde avec mes devs.
> Et surtout que ca prouve le changement de mentalite des devs gnome
Oh lala. Gnome n'est pas contre le c++. Faut arrêter avec cette légende. Ils se sont imposer la contrainte de pouvoir faire des bindings ce qui n'est pas très compatible avec le C++. C'est tout.
> au debut pas moyen d'avoir ne serai-ce une dependance c++
fam n'ajoute aucune dépendance c++ pour quelqu'un qui veut développer sous Gnome. Sinon, prouve le.
Si apache était écrit en C++, tu n'ai pas obligé de faire un navigateur en C++. Faut pas mélange librairie et protocole. fam est utilisé via un protocole. XFree peut-être réécrit en C++ que Gnome s'en battrait l'oeil. La seul chose qui compte pour les objectifs de Gnome c'est que la partie cliente soit en C. Pour corba, au début, Gnome utilisait une implémentation C++. Ce n'était pas un problème car il y a une librairie cliente était en C et que corba est un protocole.
Justement les devs de gnome s'etaient mis comme contrainte d'avoir gnome sur les plus de plateforme possible (et ils y ont mieux reussi que kde) donc le fait de dependre actuellement sur une lib en c++ (meme si la dependance n'est pas nivo code, il faut pouvoir compiler fam) me fait "sourire" ;)
Ils n'ont jamais ete fondatelement contre, ils avaient juste eviter l'utilisation du c++ qui limitait a l'epoque (et c'etait vrai), le portage sur certaines plateformes
> selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
Gcc tourne partout. Moins bien sous windows mais la cible de Gnome n'est pas Windows. Enfin, pour compiler KDE sous HP-UX par exemple, il te faut gcc ou le compilateur HP est suffisant ?
hmmm tu t'avance trop, gcc ne marche pas partout, je ne le sait que trop bien malheureusement ;( De plus le but de kde, n'est pas d'imposer un version specifique de compilo pour compiler (ca serait du delire).
Pour ton information:
- sur HP-UX, kde il ne compile pas top actuellement qque soit le compilo (mais pas du au compilo, j'ai encore essaye dernierement), alors que Qt lui il compile niquel dessus avec le compilo HP. (le pire compilo c++ que j'ai jamais rencontre etant celui d'AIX)
- pour le support du c++, je pense qu'actuellement les compilos qui sont encore maintenus le supportent assez bien (surtout des grosses ameliorations ces 2 dernieres annees, meme si je continu a penser que si tous les grands fabriquants devraient plutot investir sur gcc que sur leur version perso) Pour la norme ansi, il faut avouer que vc++7 ne doit pas en etre tres loin.
Qt est sous GPL. Il ne permet pas l'écriture de programme proprio.
Normallement c'est par dessus les libs kde (en LGPL, si tu veut comparer a qquechose d'equivalent a Gnome ne prend pas Qt) que tu devrait develloper une appli.
Qt n'a un interet que pour avoir une appli totalement multi-plateforme et la si tu vendre ton appli tu donnera qques pepettes a Qt pour contribuer indirectement au libre ;)
Enfin, j'aimerai que tu me trouves un programme "correcte" qui utilise un binding de Qt ou KDE. Pour te donner un exemple, tous les programmes de configuration redhat utilisent le binding python (redhat-config-packages, up2date-gnome, redhat-logviewer-0.8.3-2).
actuellement il y a surtout des progs qui veulent cohoperer avec kde:
xmms (le plugin en sortie art), gstreamer (le plugin arts), etc...
maintenant la majorite des petits prog sont en c++ (car pkoi s'imposer le c qd tu peut utiliser le c++). Pour les langages de script, kdevelop est le plus gros utilisateur de ceux-ci (pour la conf, etc...)
Arrêtes de dire que Gnome n'aime pas le C++.
Je n'ai jamais dit ni sous entendu cela. J'ai juste preciser que vu les contraintes de depart ils avaient eviter son utilisation.
Il me semble qu'ils ont abandonné ORB parce que c'était trop lourd, quelques core dev se sont lancé dans un projet de remplacement (DCOP), si je me souviens bien ils avaient fait une version utilisable en quelques jours (par utilisable je veut dire qui faisait effectivement quelque chose, une démo technologique).
ok, j'avait vraiment pas trop suivi a cette epoque ;(
Bon, DCOP ça fonctionne bien dans KDE, mais quand on veut lancer un prog KDE à partir d'un autre environnement c'ets un peu lourd qu'il lance automatiquement un serveur DCOP.
Malheureusement, c un mal necessaire que tous les DE ont (gnome lui lance aussi ORBit au besoin)
Un utilisateur "normal" n'a pas à être au courant de l'existance de gconf. Donc l'usabilité n'est pas très importante. C'est un outil pour le developpement, l'administration.
Ben je pense que la problematique du "power user" qui veut pouvoir customizer son envirronement sans necessairement etre admin est un vrai probleme. J'en connait un bon paquet qui sans connaitre grand chose au fonctionnement et la configuration systeme d'un os, aiment pouvoir hautement personnaliser leur environnement.
> sinon depuis qd ils utilisent fam ?
J'ai un RH 8.0, donc Gnome 2.0, qui utilise fam.
oki, j'avait meme po remarquer que gnome utilisait FAM. Bon, c'etait dur vu que, lorsque je lance gnome, j'ai tjs une ou plusieurs applis kde qui tournent.
J'ai rien contre C++.
> je ne voit pas ce que ca change au probleme.
C'était un troll, private jock. Le projet Gnome pour ces librairies de base évite l'utilisateur de C++ car çà rend les bindings languages difficile.
Donc en général, il est considéré comme "mal" d'utiliser du c++ pour un librairie de base Gnome.
j'ai honte mais, j'ai pas pu me retenir ;)
Dans le cas de fam, il n'y a aucun problème à l'utilisation de c++ puisque c'est un serveur. Pour faire une analogie, qu'Apache soit écrit en C ou C++ ne change rien pour les clients (le navigateur). C'est le protocol http qui compte.
Et surtout que ca prouve le changement de mentalite des devs gnome (celle que je pensait qu'elle aurait du mal a partir): au debut pas moyen d'avoir ne serai-ce une dependance c++ dans gnome car selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
PS: petit historique: ibm et sgi sont des utilisateurs de c++ dans des couches assez basses depuis fort longtemps ;p
PS-2: perso, pour apache en c++, je suit pas top pour: ca apporterait rien et ca alourdirait un peu l''execution si jamais tu venait a vouloir faire du bel objet
je le sait fort bien mais, j'avait surtout preciser que Gnome est plus facilement themable car tu peut facilement utiliser des fichiers descriptifs, des scripts, ... pour les themes. Et meme aller jusqu'a les faire en c (surtout c++;p) si tu veut.
Maintenant, actuellement, kde t'impose le c/c++ pour le devellopement de themes (excepte via les bindings mais bon la ca devient gore)
PS-perso: pourtant tu devrait commencer a apprecier le c++, Gael
si tu veut tu peut tjs te former la main a faire un theme engine kde (oupsss gnome) ;)
Justement, je fais aucun reproche, je trouve juste que l'environnement kde est incomplet car la majorité des apps sont des apps gtk, cela semble s'égaliser avec la cooker(kxine, k3b), esperons que la 9.1 gardera ces applis...
en fait ce n'est pas du a Mandrake: actuellement, il y a en proportion bcp plus d'applis Gtk+/Gnome que d'application Qt/KDE meme si c'est ecart tend a diminuer (enfin je trouve ca tjs pas tres pertinent d'avoir 40 applications graphiques sur chaque DE pour la meme chose, chiffre non contractuel)
Surtout k3b qui est la killer app du gravage
c'est vrai que k3b est pas mal, mais cdbakeoven et kaudiorecord aussi (et vi 3 applis pour la gravure de cd dans le cvs kde, sans compter celles qui traine dans kdenonbeta)
vi, j'aurait une preuve formelle ecrite de MDI ou autre pionnier de gnome sous la main, je te l'aurait sortie. Maintenant le "ont pu" s'approche plus de l'affirmation que du conditionnel, mais ne cherchant a faire le sujet par en troll, je modere ...
Mais, malgre ma faible experience avec certains "managers" americains je peut te confirmer cette tendance fruit du merveilleux sentiment de protectionisme americain (on a aussi nos defauts mais nous generalement on se "tire" essentiellement dessus entre-nous, de la a dire que l'on "descend" des ambulances ...)
Mandrake a tjs soutenu les deux desktops de maniere egale. Maintenant je ne pense pas que Mandrake ait plus favorisee kde avec plus de devs car je ne pense pas qu'ils etaient plus nombreux que ceux associes a gnome, mais ils etaient surtout plus important au niveau de gestion du projet kde (david Faure, ...)
Maintenant il est vrai que Mandrake a joue, surtout au debut, sur le fait d'etre une "pseudo-RH" avec kde (ce que RH refusait totalement de faire, bien que gnome balbutait encore et que l'installation de rpms binaires KDE sur une RH tenait souvent de l'exploit ... j'en avait fait les frais).
mouais, enfin le tout le monde etait assez limite a cette epoque. Je ne pense pas qu'ils auraient investi dans le dev de Gtk+ si gnome n'en avait pas besoin.
Mouais. Je rappèle que Gnome veut dire Gnu Network Object Model Environment. Dès le début (le nom le prouve) ils voulaient utiliser Corba (accès à distance de composant). KDE n'utilisait pas d'équivalent à Corba à l'époque qu'ils estimaient inutile.
nuance enorme KDE avait aussi vocation a devenir "Object Model" mais ils jugaient les implementations de ORB existants a l'epoque tres lourdes et tant que l'integration d'un systeme "Object" n'etait pas necessaire (tant que le framework de base n'est pas suffisement riche c de la branlette intellectuelle de mettre un ORB a l'interieur) ils ont juges bon d'attendre.
Ce n'est juste que pour la version 2.0 que la necessite s'est imposee, et a l'epoque ils ont meme mis d'enormes espoirs dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide) au point d'y mettre pas mal de developpement pour l'integrer.
Je ne me rappelle plus ce qui a fait que ORBit soit abandonne alors que pas mal de devs y avait ete consacre (j'etait pas "a jour" a cette epoque) mais il me semble que c'etait une grosse limitation technique. Ils se sont donc tournes vers un protocole plus light: ICE et la naissance de DCOP
Ce n'est pas pour lancer un troll, mais sur de nombreux PC équipés de Redhat, j'ai constaté que KDE met au moins 10 fois plus de temps à se lancer que GNOME+sawfish (la faute à tous ces services lancés par kde au démarrage, probablement).
sisi c'est bien un troll que tu lance.
Mais je vait te repondre sans retroller;)
Effectue donc une recherche sur les discussions autout des problemes entre kde, g++ et ld (ca avait fait le tour de la planete a la sortie de kde3.0).
Ensuite une doc sur le prelink de g++ (option -z combreloc si je ne m'abuse).
Enfin au final pose toi la question pkoi, selon ce que tu semble dire, RH n'utilise pas cette option...
ouais enfin de ce cote Gnome est bcp plus facilement themable meme si au final KDE peut aller beaucoup plus loin dans ses themes (l'avantage d'avoir des plugins en c++)
maintenant en etant honnete j'apprecie de plus en plus certains details de design et de finitions de gnome (bon de nombreux details me genent aussi un peu comme la taille des boutons playskool par defaut).
C'est bourre de petits trucs purement graphiques (non logiciel, souvent des choix de couleurs, des bitmaps bien pensees, ...) qui rendent caduques (ou comme certaines mauvaises langues disent feintent) de complexes effets logiciels.
Si les designers de kde pouvaient suivre le chemin (le parti pris de kde est de develloper tout les effets logiciel, le prob est qu'au final peu de dev les utilisent)
po mal, enfin ce me plait pas top en terme d'usabilite (meme si je pense que c'est utilisable, il doit surement avoir plus optimal en reflechissant bien)
Sinon moi ce qui m'interresse c plus les evolutions effectuees au niveau des fondations, des ameliorations de l'architecture, ... qqu'un a des infos ?
sinon depuis qd ils utilisent fam ? pcque fam c'est du c++, po bieeeen ;)
Syndrome du NIH : Not Invented Here ?
Je ne dis pas ça pour confirmer la raison, mais je pense que c'est un argument qui a pu (aurait pu ?) jouer.
A mon avis, ca a jouer pas mal au debut, lors du "raccolage" des permiers devellopeurs.
Maintenant, heureusement, ca n'est plus du tout le cas (mis a part qques Hac*erzz completements debiles).
Tu ne peux pas dire çà. C'est pas sérieux, grotesque et honteux.
Ben vi on etait au 20eme siecle, et des considerations aussi stupides ont pu jouer un grand role.
Mais il faut savoir ce genre de considerations sont tjs d'actualite, perso je travaille dans une boite qui livre un tres gros logiciel extrement innovant et adapte aux besoins de clients maintenant il a marche aux etats unis pcque c ibm qui le vend et qu'au debut ils ont un peu cacher le fait qu'il etait develloper par une boite francaise ... et vi de quoi halluciner.
Enfin quand j'entend les nombreuses rumeurs sur les "pratiques de la nsa" et autres moyen de pression "economique" americain, on est en droit de se poser de reelles questions sur le manque total de "protectionnisme europeen"
si et meme beaucoup trop (j'en fait encore tous les jours d'ailleurs)
Ben il faut me montrer çà. Car je ne sais pas comment faire pour détecter le type à l'exécution (du moins en C) surtout que les structures utilisées sont les mêmes que Qt. A moins que dans le binding, chaque structure est encapsulé dans une structure qui indique le type.
Beaucoup plus simple, le code des bindings est en c++, donc il utilise les controle de validite de type via les cast c++
en va consulter les sources. Il n'y a pas de controle de type car tout passe par des (void *)
j'ai jamais considerer le c comme faisant du controle de type, celui ci doit etre fait si c'est possible en pre-conditon dans les fonctions (dans le binding Qt-c il y a un test implicite dans les casts)
les noms de fonctions sont parfois non significatif ( toto1() , toto2() )
il y en a peu, car c'est uniquement les methodes surchargees qui generent des chose comme celle la mais c vrai que c'est un probleme
La partie gtk est terminée depuis des lustres. Par contre ce qui tarde a être complet c'est la partie gnome.
personnelement, je l'avait attendu pas mal de temps, maintenant c vrai que ca fait pas mal de temps qu'elle est dispo (ca me rend pas plus jeune tout ca)
C'est vrai. Mais c'est de l'histoire ancienne. De plus, la volonter de "tuer KDE" était liée à la license de QT qui a changée depuis ... au moins si ce n'est plus.
pas tout a fait exact. En simplifiant pas mal, a l'origine, gnome etait la pour contrer kde sur trois fronts:
- la plus honteuse: kde c'etait et c'est encore un projet essentielement europeen (appuye pas mal par Suse a l'origine d'ou redhat chez gnome)
- kde est developpe en c++ qui etait a l'epoque assez mal supporte par la majorite des plate-formes
- la plus noble: la license ce Qt n'etait pas libre
tiens j'ai oublie de repondre a ca ... meme si ca ressemble a un troll qui se cache
> il aurait ete plus logique de se concentre sur Harmony.
C'est juste. Néanmoins, Gnome a, dès le debut, voulu être indépendant du language de programme pour que les pro-C, pro-C++, pro-python, etc... puissent utiliser Gnome/Gtk. Je sais qu'il existe des bindings pour Qt ou KDE. Malheureusement ils n'ont pas le niveau des bindings de Gtk/GNOME (même si ceux-ci sont encore perfectible). J'ai regardé le binding C de Qt mais il n'est pas réellement exploitable. Il y a maintenant beaucoup de petits/moyennes applis écritent avec gtkmm ou python-gtk, etc... Les binding Gtk/Gnome sont une réalité car utilisé. Néanmoins KDE offre DCOPS (je suis pas sure du nom) qui est interessant pour faire de petit scripts.
le binding c de Qt est aussi utilisable que gtk, c meme assez ressemblant au final. Maintenant c'est vrai que generalement il est plus simple et agreable de code en c++ donc la majorite des applis sous kde sont dev en c++.
Alors que du cote de gtk+, comme le binding reelement c++ OO a tarde, je pense que les devs ont preferes les langages de scripts
Faut pas oublié que Qt a été fait avant Gtk. Donc au début Qt était fort logiquement meilleur que Gtk.
hmmm si je me rappelle bien gtk (noter l'absence de + => pas gtk+) en bien plus vieux que Qt (gtk etait un tk devellope a la base pour gimp, il est "devenu" gtk+ plus tard pour les "besoins" du projet gnome)
Déjà qu'ils avaient de l'avance. Si en plus ils vont plus vite...
on peut pas dire qu'ils avancent plus vite, disont juste que leur mehtodologie de dev permet d'avoir une convergence rapide et une plus grande reutilisation du code au niveau des fondations de base.
En clair, ils semble "progresser plus vite" sur l'ensemble des libs et du DE (progression verticale), alors que du cote gnome les progressions se font plutot en horizontale: extension des capacites des applis, et des differents niveaux.
J'ai utilisé Gnome 0.99. Je peux confirmer que pour le "portage", ils se sont plantés.
le portage datait des balbutiements de gnome (MDI n'etait pas chaud la dessus d'ailleurs) et a ete vite abandonne du fait de la difference de philosophie (a l'origine) entre Qt et Gtk.
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
L'extention ajouté par gtk+ est pourtant très "C++".
L'explication sur le + est donnée par le développeur de gimp/gtk et non par un développeur Gnome. Cette extention est définitivement un plus. Afin, les extensions gtk+ sont pour tout les programmes qui utilisent gtk+ et non pour Gnome. Le but de Gnome est de faire un bureau et offrir des fonctionnalités pour le développement d'appli (evolution, galeon, gnucash, xchat, gnomemeting, etc...). C'est principalement des extensions pour les developpeurs d'appli et non uniquement pour Gnome. D'ailleur, les widgets spécifiques gnome se trouve dans gnome-lib et non dans gtk+.
je n'ai aucun probleme, Gtk+ est de l'assez bon c OO (en non oriente c++)
maintenant il faut etre realiste sur le fait que c'est surtout la volonte d'un tk puissant comme base de gnome qui a entraine le split. Le fait qu'il peut aussi etre utiliser en dehors de gnome, c'est vrai aussi le but de Gtk+ n'etait pas de devenir le tk de gnome, mais plutot le tk utilise comme base par gnome. On peut faire le meme parrallele sur certaines evolutions de Qt (ex: le changement de licence) qui ont etes a l'origine entrainees par l'utilisation de Kde puis pouvant etre reutilisees par les autres projets.
> dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide)
Développé par RedHat dans le cadre du projet Gnome, et en C. Y a même un binding python :-)
Oui, c'est bien vrai, mais surtout essentielement developpe par une seule personne (veritable tour de force)
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
que sous-entend tu par "re-coder un mini-WM dans les widgets" ?
sinon pour ton info les MDI peuvent se fait tres simplement avec kde mais je voit pas le lien entre les MDI et les menus flottants ;(
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
Ben trouve moi un cas où tu as besoin de connaitre l'existence de gconf pour customizer ton environnement.
gconftools est pour fixer les valeurs par défauts aux nouveauxcomptes ou imposer des valeurs (par exemple pour un proxy). gconftools est donc pour les admins (d'ailleur il faut être root pour modifier des valeurs).
Sous gnome, je ne pourrait pas te sortir d'exmple, maintenant sous kde vu que le control-center ressemble plus a un tableau de bord d'un cockpit d'avion, il est grand temps de separer le "vital" de ce qui n'est que de l'"ultra customizable eye-candies and features"
> lorsque je lance gnome
Damned, pour quelqu'un qui n'arrête pas de critiquer gnome. Mais je pense que tu veux dire "lorsque je lance des applis gnome".
Faut pas croire, je ne critique pas essentielement gnome, meme si cela y ressemble. Je cherche juste a equilibrer les choses par rapport au gros pre-juges (trolls?) sur kde (je remonte aussi gnome de nombreuses fois).
Maintenant il m'arrive bien de lancer gnome (avec le desktop et tout et tout) lors de tests d'integration ou regulierement quand je casse mon kde avec mes devs.
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 0.
> Et surtout que ca prouve le changement de mentalite des devs gnome
Oh lala. Gnome n'est pas contre le c++. Faut arrêter avec cette légende. Ils se sont imposer la contrainte de pouvoir faire des bindings ce qui n'est pas très compatible avec le C++. C'est tout.
> au debut pas moyen d'avoir ne serai-ce une dependance c++
fam n'ajoute aucune dépendance c++ pour quelqu'un qui veut développer sous Gnome. Sinon, prouve le.
Si apache était écrit en C++, tu n'ai pas obligé de faire un navigateur en C++. Faut pas mélange librairie et protocole. fam est utilisé via un protocole. XFree peut-être réécrit en C++ que Gnome s'en battrait l'oeil. La seul chose qui compte pour les objectifs de Gnome c'est que la partie cliente soit en C. Pour corba, au début, Gnome utilisait une implémentation C++. Ce n'était pas un problème car il y a une librairie cliente était en C et que corba est un protocole.
Justement les devs de gnome s'etaient mis comme contrainte d'avoir gnome sur les plus de plateforme possible (et ils y ont mieux reussi que kde) donc le fait de dependre actuellement sur une lib en c++ (meme si la dependance n'est pas nivo code, il faut pouvoir compiler fam) me fait "sourire" ;)
Ils n'ont jamais ete fondatelement contre, ils avaient juste eviter l'utilisation du c++ qui limitait a l'epoque (et c'etait vrai), le portage sur certaines plateformes
> selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
Gcc tourne partout. Moins bien sous windows mais la cible de Gnome n'est pas Windows. Enfin, pour compiler KDE sous HP-UX par exemple, il te faut gcc ou le compilateur HP est suffisant ?
hmmm tu t'avance trop, gcc ne marche pas partout, je ne le sait que trop bien malheureusement ;( De plus le but de kde, n'est pas d'imposer un version specifique de compilo pour compiler (ca serait du delire).
Pour ton information:
- sur HP-UX, kde il ne compile pas top actuellement qque soit le compilo (mais pas du au compilo, j'ai encore essaye dernierement), alors que Qt lui il compile niquel dessus avec le compilo HP. (le pire compilo c++ que j'ai jamais rencontre etant celui d'AIX)
- pour le support du c++, je pense qu'actuellement les compilos qui sont encore maintenus le supportent assez bien (surtout des grosses ameliorations ces 2 dernieres annees, meme si je continu a penser que si tous les grands fabriquants devraient plutot investir sur gcc que sur leur version perso) Pour la norme ansi, il faut avouer que vc++7 ne doit pas en etre tres loin.
Qt est sous GPL. Il ne permet pas l'écriture de programme proprio.
Normallement c'est par dessus les libs kde (en LGPL, si tu veut comparer a qquechose d'equivalent a Gnome ne prend pas Qt) que tu devrait develloper une appli.
Qt n'a un interet que pour avoir une appli totalement multi-plateforme et la si tu vendre ton appli tu donnera qques pepettes a Qt pour contribuer indirectement au libre ;)
Enfin, j'aimerai que tu me trouves un programme "correcte" qui utilise un binding de Qt ou KDE. Pour te donner un exemple, tous les programmes de configuration redhat utilisent le binding python (redhat-config-packages, up2date-gnome, redhat-logviewer-0.8.3-2).
actuellement il y a surtout des progs qui veulent cohoperer avec kde:
xmms (le plugin en sortie art), gstreamer (le plugin arts), etc...
maintenant la majorite des petits prog sont en c++ (car pkoi s'imposer le c qd tu peut utiliser le c++). Pour les langages de script, kdevelop est le plus gros utilisateur de ceux-ci (pour la conf, etc...)
Arrêtes de dire que Gnome n'aime pas le C++.
Je n'ai jamais dit ni sous entendu cela. J'ai juste preciser que vu les contraintes de depart ils avaient eviter son utilisation.
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
ok, j'avait vraiment pas trop suivi a cette epoque ;(
Bon, DCOP ça fonctionne bien dans KDE, mais quand on veut lancer un prog KDE à partir d'un autre environnement c'ets un peu lourd qu'il lance automatiquement un serveur DCOP.
Malheureusement, c un mal necessaire que tous les DE ont (gnome lui lance aussi ORBit au besoin)
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 2.
Ben je pense que la problematique du "power user" qui veut pouvoir customizer son envirronement sans necessairement etre admin est un vrai probleme. J'en connait un bon paquet qui sans connaitre grand chose au fonctionnement et la configuration systeme d'un os, aiment pouvoir hautement personnaliser leur environnement.
> sinon depuis qd ils utilisent fam ?
J'ai un RH 8.0, donc Gnome 2.0, qui utilise fam.
oki, j'avait meme po remarquer que gnome utilisait FAM. Bon, c'etait dur vu que, lorsque je lance gnome, j'ai tjs une ou plusieurs applis kde qui tournent.
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 2.
> je ne voit pas ce que ca change au probleme.
C'était un troll, private jock. Le projet Gnome pour ces librairies de base évite l'utilisateur de C++ car çà rend les bindings languages difficile.
Donc en général, il est considéré comme "mal" d'utiliser du c++ pour un librairie de base Gnome.
j'ai honte mais, j'ai pas pu me retenir ;)
Dans le cas de fam, il n'y a aucun problème à l'utilisation de c++ puisque c'est un serveur. Pour faire une analogie, qu'Apache soit écrit en C ou C++ ne change rien pour les clients (le navigateur). C'est le protocol http qui compte.
Et surtout que ca prouve le changement de mentalite des devs gnome (celle que je pensait qu'elle aurait du mal a partir): au debut pas moyen d'avoir ne serai-ce une dependance c++ dans gnome car selon leurs dires le langage c++ etait supra mal supporte sur la majorite des os
PS: petit historique: ibm et sgi sont des utilisateurs de c++ dans des couches assez basses depuis fort longtemps ;p
PS-2: perso, pour apache en c++, je suit pas top pour: ca apporterait rien et ca alourdirait un peu l''execution si jamais tu venait a vouloir faire du bel objet
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 1.
Maintenant, actuellement, kde t'impose le c/c++ pour le devellopement de themes (excepte via les bindings mais bon la ca devient gore)
PS-perso: pourtant tu devrait commencer a apprecier le c++, Gael
si tu veut tu peut tjs te former la main a faire un theme engine kde (oupsss gnome) ;)
[^] # Re: Mdk pro kde !
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 2.
en fait ce n'est pas du a Mandrake: actuellement, il y a en proportion bcp plus d'applis Gtk+/Gnome que d'application Qt/KDE meme si c'est ecart tend a diminuer (enfin je trouve ca tjs pas tres pertinent d'avoir 40 applications graphiques sur chaque DE pour la meme chose, chiffre non contractuel)
Surtout k3b qui est la killer app du gravage
c'est vrai que k3b est pas mal, mais cdbakeoven et kaudiorecord aussi (et vi 3 applis pour la gravure de cd dans le cvs kde, sans compter celles qui traine dans kdenonbeta)
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
vi, j'aurait une preuve formelle ecrite de MDI ou autre pionnier de gnome sous la main, je te l'aurait sortie. Maintenant le "ont pu" s'approche plus de l'affirmation que du conditionnel, mais ne cherchant a faire le sujet par en troll, je modere ...
Mais, malgre ma faible experience avec certains "managers" americains je peut te confirmer cette tendance fruit du merveilleux sentiment de protectionisme americain (on a aussi nos defauts mais nous generalement on se "tire" essentiellement dessus entre-nous, de la a dire que l'on "descend" des ambulances ...)
[^] # Re: Mdk pro kde !
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
Maintenant il est vrai que Mandrake a joue, surtout au debut, sur le fait d'etre une "pseudo-RH" avec kde (ce que RH refusait totalement de faire, bien que gnome balbutait encore et que l'installation de rpms binaires KDE sur une RH tenait souvent de l'exploit ... j'en avait fait les frais).
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 0.
mouais, enfin le tout le monde etait assez limite a cette epoque. Je ne pense pas qu'ils auraient investi dans le dev de Gtk+ si gnome n'en avait pas besoin.
Mouais. Je rappèle que Gnome veut dire Gnu Network Object Model Environment. Dès le début (le nom le prouve) ils voulaient utiliser Corba (accès à distance de composant). KDE n'utilisait pas d'équivalent à Corba à l'époque qu'ils estimaient inutile.
nuance enorme KDE avait aussi vocation a devenir "Object Model" mais ils jugaient les implementations de ORB existants a l'epoque tres lourdes et tant que l'integration d'un systeme "Object" n'etait pas necessaire (tant que le framework de base n'est pas suffisement riche c de la branlette intellectuelle de mettre un ORB a l'interieur) ils ont juges bon d'attendre.
Ce n'est juste que pour la version 2.0 que la necessite s'est imposee, et a l'epoque ils ont meme mis d'enormes espoirs dans ORBit (qui on peut l'avouer est la permier implementation d'ORB digne de se nom et fichtrement rapide) au point d'y mettre pas mal de developpement pour l'integrer.
Je ne me rappelle plus ce qui a fait que ORBit soit abandonne alors que pas mal de devs y avait ete consacre (j'etait pas "a jour" a cette epoque) mais il me semble que c'etait une grosse limitation technique. Ils se sont donc tournes vers un protocole plus light: ICE et la naissance de DCOP
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
RTTI cf static_cast, dynamic_cast
[^] # Re: Disponibilité de Gnome 2.0 pour Solaris
Posté par Raphael Junqueira . En réponse à la dépêche Disponibilité de Gnome 2.0 pour Solaris. Évalué à 1.
sisi c'est bien un troll que tu lance.
Mais je vait te repondre sans retroller;)
Effectue donc une recherche sur les discussions autout des problemes entre kde, g++ et ld (ca avait fait le tour de la planete a la sortie de kde3.0).
Ensuite une doc sur le prelink de g++ (option -z combreloc si je ne m'abuse).
Enfin au final pose toi la question pkoi, selon ce que tu semble dire, RH n'utilise pas cette option...
[^] # Re: Disponibilité de Gnome 2.0 pour Solaris
Posté par Raphael Junqueira . En réponse à la dépêche Disponibilité de Gnome 2.0 pour Solaris. Évalué à 2.
je vait pouvoir defoncer CDE, cette chose immonde qui devient ingerable avec trop de fenetre et qui bouffe comme pas permis
demain au buro je vait passer ca sur tout les suns ;)
par contre je serait pas contre un konqueror sur solaris (et rapide pcque le compilo c++ sun c'est pas encore ca)
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 5.
maintenant en etant honnete j'apprecie de plus en plus certains details de design et de finitions de gnome (bon de nombreux details me genent aussi un peu comme la taille des boutons playskool par defaut).
C'est bourre de petits trucs purement graphiques (non logiciel, souvent des choix de couleurs, des bitmaps bien pensees, ...) qui rendent caduques (ou comme certaines mauvaises langues disent feintent) de complexes effets logiciels.
Si les designers de kde pouvaient suivre le chemin (le parti pris de kde est de develloper tout les effets logiciel, le prob est qu'au final peu de dev les utilisent)
[^] # Re: Gconf pour les nuls ... et les hackers
Posté par Raphael Junqueira . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 0.
http://www.gnome.org/learn/admin-guide/2.2/gcon(...)
po mal, enfin ce me plait pas top en terme d'usabilite (meme si je pense que c'est utilisable, il doit surement avoir plus optimal en reflechissant bien)
Sinon moi ce qui m'interresse c plus les evolutions effectuees au niveau des fondations, des ameliorations de l'architecture, ... qqu'un a des infos ?
sinon depuis qd ils utilisent fam ? pcque fam c'est du c++, po bieeeen ;)
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
Je ne dis pas ça pour confirmer la raison, mais je pense que c'est un argument qui a pu (aurait pu ?) jouer.
A mon avis, ca a jouer pas mal au debut, lors du "raccolage" des permiers devellopeurs.
Maintenant, heureusement, ca n'est plus du tout le cas (mis a part qques Hac*erzz completements debiles).
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 2.
Ben vi on etait au 20eme siecle, et des considerations aussi stupides ont pu jouer un grand role.
Mais il faut savoir ce genre de considerations sont tjs d'actualite, perso je travaille dans une boite qui livre un tres gros logiciel extrement innovant et adapte aux besoins de clients maintenant il a marche aux etats unis pcque c ibm qui le vend et qu'au debut ils ont un peu cacher le fait qu'il etait develloper par une boite francaise ... et vi de quoi halluciner.
Enfin quand j'entend les nombreuses rumeurs sur les "pratiques de la nsa" et autres moyen de pression "economique" americain, on est en droit de se poser de reelles questions sur le manque total de "protectionnisme europeen"
Question TrollTech, c'est Européen?
Vi, norvegien
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
si et meme beaucoup trop (j'en fait encore tous les jours d'ailleurs)
Ben il faut me montrer çà. Car je ne sais pas comment faire pour détecter le type à l'exécution (du moins en C) surtout que les structures utilisées sont les mêmes que Qt. A moins que dans le binding, chaque structure est encapsulé dans une structure qui indique le type.
Beaucoup plus simple, le code des bindings est en c++, donc il utilise les controle de validite de type via les cast c++
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
en va consulter les sources. Il n'y a pas de controle de type car tout passe par des (void *)
j'ai jamais considerer le c comme faisant du controle de type, celui ci doit etre fait si c'est possible en pre-conditon dans les fonctions (dans le binding Qt-c il y a un test implicite dans les casts)
les noms de fonctions sont parfois non significatif ( toto1() , toto2() )
il y en a peu, car c'est uniquement les methodes surchargees qui generent des chose comme celle la mais c vrai que c'est un probleme
La partie gtk est terminée depuis des lustres. Par contre ce qui tarde a être complet c'est la partie gnome.
personnelement, je l'avait attendu pas mal de temps, maintenant c vrai que ca fait pas mal de temps qu'elle est dispo (ca me rend pas plus jeune tout ca)
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 3.
pas tout a fait exact. En simplifiant pas mal, a l'origine, gnome etait la pour contrer kde sur trois fronts:
- la plus honteuse: kde c'etait et c'est encore un projet essentielement europeen (appuye pas mal par Suse a l'origine d'ou redhat chez gnome)
- kde est developpe en c++ qui etait a l'epoque assez mal supporte par la majorite des plate-formes
- la plus noble: la license ce Qt n'etait pas libre
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 1.
> il aurait ete plus logique de se concentre sur Harmony.
C'est juste. Néanmoins, Gnome a, dès le debut, voulu être indépendant du language de programme pour que les pro-C, pro-C++, pro-python, etc... puissent utiliser Gnome/Gtk. Je sais qu'il existe des bindings pour Qt ou KDE. Malheureusement ils n'ont pas le niveau des bindings de Gtk/GNOME (même si ceux-ci sont encore perfectible). J'ai regardé le binding C de Qt mais il n'est pas réellement exploitable. Il y a maintenant beaucoup de petits/moyennes applis écritent avec gtkmm ou python-gtk, etc... Les binding Gtk/Gnome sont une réalité car utilisé. Néanmoins KDE offre DCOPS (je suis pas sure du nom) qui est interessant pour faire de petit scripts.
le binding c de Qt est aussi utilisable que gtk, c meme assez ressemblant au final. Maintenant c'est vrai que generalement il est plus simple et agreable de code en c++ donc la majorite des applis sous kde sont dev en c++.
Alors que du cote de gtk+, comme le binding reelement c++ OO a tarde, je pense que les devs ont preferes les langages de scripts
PS: c'est DCOP (sans le s)
[^] # Re: Trollesque ??
Posté par Raphael Junqueira . En réponse à la dépêche Création du Desktop Linux Consortium. Évalué à 3.
hmmm si je me rappelle bien gtk (noter l'absence de + => pas gtk+) en bien plus vieux que Qt (gtk etait un tk devellope a la base pour gimp, il est "devenu" gtk+ plus tard pour les "besoins" du projet gnome)
Déjà qu'ils avaient de l'avance. Si en plus ils vont plus vite...
on peut pas dire qu'ils avancent plus vite, disont juste que leur mehtodologie de dev permet d'avoir une convergence rapide et une plus grande reutilisation du code au niveau des fondations de base.
En clair, ils semble "progresser plus vite" sur l'ensemble des libs et du DE (progression verticale), alors que du cote gnome les progressions se font plutot en horizontale: extension des capacites des applis, et des differents niveaux.
J'ai utilisé Gnome 0.99. Je peux confirmer que pour le "portage", ils se sont plantés.
le portage datait des balbutiements de gnome (MDI n'etait pas chaud la dessus d'ailleurs) et a ete vite abandonne du fait de la difference de philosophie (a l'origine) entre Qt et Gtk.