Raphael Junqueira a écrit 337 commentaires

essaye kdevelop3 (et n'hesite pas a envoyer des rapports de bugs si ca te dis d'ameliorer le parseur) :)
tu peut meme garder ton emacs avec (bon fo le vouloir mais tu peux)

> 1 - on est oblige d'utiliser windows pour envoyer 1 mail,

Ca c'est pas de la faute a windows, si c un os avec une bonne gestion de desktop integre (sous linux on a gnome et kde, mais sous SUN...). Et ne me parle pas de mailx ...

> 2 - regarde la CXR9SP3 par exemple, regarde la gestion des display list, les
> variables utilisees pour savoir si l'on doit effacer les displayLists ne sont utilisees
> que pour nvidia (c'est la qu'on passe le + de temps CPU sur Sun).

Demande donc plutot pourquoi SUN ne se sont pas integrer a la chose sur la CXR9. Je ne pense pas que NVIDIA quand ils ont "integre" ca il allaient supporter SUN :)
Enfin, je pense que ca doit etre fixer depuis, je verifierait demain

> 3 - ENOVIA = compile en debug sur Sun (rechercher DUMMY dans les Imakefile ...)

Celle la je savait pas, funny :)

> 4 - ça fait 3 mois que j'essaye d'integrer les mime types pour Gnome, on m'envoie
> gentillement chier.

Comment ca ?

> 5 - pour les Spreadsheat, CATIA ne s'interface qu'avec Office, c'est Sun qui doit
> faire l'interfacage avec StarOffice/OpenOffice, le dev ne connait meme pas SO/OO.

Meme probleme que le 1, En fait le code n'utilise pas explicitement Office mais du COM pour l'integration au desktop. Le jour ou SUN installera/activera d'office Gnome (ou kde) et OO (le tout bien integre) le support devrait etre fait.

> Je ne parle meme pas de tous les modules qui sont compile sur toutes les
> machines et qui ne sont utilises que pour Windows (la reciproque n'est pas vrai),

Des noms ?

> des dev qui testent des patchs perfo sur une SB150 EN DEBUG,

Normallement faux, sur SUN tu n'a pas besoin d'etre en DEBUG pour ca.

> des 5 secondes passees pour commencer a pouvoir faire 1 appel a certaines lib,
> car on fait des centaines d'appels pour savoir qu'elle version de la lib on utiliserait
> si on etait sur windows. ...

??

>Néanmoins, je suis d'accord avec toi concernant l'avenir de Catia sous Unix. Un
> commercial de Dassault m'a dit qu'ils envisageaient tout simplement de stopper le
> portage sous ces OS à moyen terme (d'ici quelques années).

Et la marmotte ...
Faudrait dire ca a IBM, le partenaire de DS, pour voir ce qu'ils en pensent d'un affirmation comme celle la :)
Je ne dis pas que certains Unix seront delaisses ce qui risque d'arriver fort vite vu que meme les constructeurs derriere ceux-cis les delaissent mais TOUS les Unix ca risque pas d'arriver (surtout que IBM y tient a son AIX)

Vi CATIA utilise l'OpenGL (renseignez vous avant de parler), et non IBM, n'a pas rajoute des merdes pour NIVDIA mais uniquement pour leus stations AIX et autres specialites de leurs grosses stations PC.
NVIDIA sont assez grands pour rajouter du code eux-memes, ce qu'il font mais surement plus proprement que IBM.

> C'est clair que Dassault est HYPER pro-microsoft.

Ca c archi faux. Actuellement deux os sont bien plus avantages que les autres: Sun et windows pour de grosses raisons techniques relatives au systemes.
Maintenant, comme les gros PC ont qd meme des performances assez monstrueuses a cote des Sun, il se troue que pas mal de clients preferent passer sur windows.

En fait ca n'est pas reelement vrai, sur certaines operations la SUN va bien plus vite que la station x86 a deux fois la frequence de la premiere (bon c'est vrai que c sur juste un tout petit petit subset d'algos mais y en a encore)

Mais OOOOUUUUIIIIII. D'ailleur 80 % des projets ont au moins la taille d'evolution.

Et alors, ai je parler de taille de code ?
Je parlait en terme d'impact, d'applis qui feront que le libre marchera (suites office, logiciel de communication/gestion intranet, grosse applications metiers)
et la actuellement dans le libre il y en a tres peu.

Alors pour toi kdevelop est un gros projet et evolution, galeon, gnucash de petit projet.

kdevelop oui, car il un IDE de ce niveau ca commence a devenir ce qu'un developeur logiciel (et un gestionnaire de projets) attend.
Pour evolution je pense qu'il est sur la voie de devenir un bon logiciel de "workflow" (le nom est pas terrible mais comme lotus ou exchange quoi) meme si, perso, je trouve qu'il a qques lacunes assez genante (que n'ont pas l'ensemble kmail/korganiser/kontact du cvs kde)

Voyons ça. Ma référence, les src.rpm d'une distribution redhat 9 :
- galeon : 3.9M
- kdevelop : 6.6M
- gnucash : 8.2M
- evolution : 13M

Comme dit plus haut ce n'est pas la taille du code qui fait une grande appli.
Car a ce moment selon les chiffres, le notepad de microsoft serait une appli qui "ecrasereait" ton galeon.

Ajoutons dans le projets plus gros que kdevelop :
- gnumeric
- abiword
- gimp

Ai je dit que gnumeric ou abiword etaient moins "gros" que kdevelop. Connait tu le sens du mot "exemple".

Puis regardes : http://ftp.rhnet.is/pub/redhat/linux/9/en/os/i386/SRPMS/(...(...)) . Même galeon qui est le plus petit cité est dans les 25 % plus gros projet (il y a 75 % de projet plus petit).

Super, tu est heureux quand une appli mal concue depasse les centaines de milliers de lignes alors qu'elle devrait a peine en faire une dizaine ?

Je doute. Celà veut dire :
1- KDE propose un wrap pour tout les fonctions/types de Qt (j'en doute grave).
2- Il suffit de faire un wrap d'une librairie GPL (même un wrap très sommaire, en se limitant à des changement de noms des fonctions/type/constantes) pour inhiber une licence GPL d'une librairie.

1- Non pas vraiment, mais kde fournit une API de plus haut niveau ce qui evite, en general, de faire du Qt bas niveau. Donc de linker explicitement avec Qt
2- Oui tu peut le faire, et meme mieux tu peut meme avoir les memes noms de fonctions,etc... a condition que tu reecrive tout from scratch. Par contre tu dois sortir ton code sous une licences GPL compatible.
Le meme principe est utiliser par Linux: noyau GPL, libc LGPL, applis Proprios
Ou wine: wine core libs GPL, wine ext libs LGPL, applis Proprios
Il faut juste faire super attention aux conditions de links

Non.

Sisi, je t'assure.

Comme galeon, evolution, gnucash, etc. Mais OOOUUIIIIIIII. Troll detected.

La majorite des applis que tu cite la sont pour moi des petits logiciels (ptet evolution et encore). Kdevelop, OO, ... ceux-la sont des gros logiciels.

Sur ce point je suis d'accord. Par contre les perceptives d'avenir sont énormes car Motif est pratiquement mort.

Vi d'ailleurs j'aimerait bien qu'au taf on utilise plus motif sous unix ;(

Je suis d'accord. Je pense la même chose pour HP-UX (mais moins rapidement).

Je pense qu'avant ils vont fusionner les deux pour ce rendre compte que c inutil ;)

kdelibs est LGPL mais comme Qt est GPL (au mieu) le programme (et non la libriairie) est forcément GPL.

Non, justement tu peux faire un programme juste au dessus de Kde (et uniquement kde qui lui utilise Qt en background) donc dans la licence que tu veux

Les kdelibs peuvent être LGPL alors qu'elles sont basées sur une lib (Qt) qui est GPL??

Et oui c'est ce qu'on appelle un Licence GPL-compatible ;)
Bon toute modif sur Qt et kdelibs doit etre redistribuer mais ton appli tu peut la faire par dessus kde (et que kde) sans filer les sources

Gnome sera livré en standard dans Solaris 10 ... qui n'est pas encore sorti...

Tu va rire (ou pleurer selon ton humeur) mais bien que gnome soit liverer de base sur solaris 10, ce sera toujours CDE le bureau par defaut .SUN ne voulant pas destabiliser ses utilisateurs qui l'utilisent depuis des annees (et oui).

Troll detected. Gtk est autant utilisé que Qt. Si Gtk n'existe pas, Qt n'existe pas.

En fait Gtk+ est bien plus utilise par des (petits) projets libres que Qt (et c logique car bcp de projets libres ne sont code qu'en C). Maintenant c'est vrai que sur les "gros" projets les deux se valent (meme si je pense que ce genre de projets sous Qt commencent a etre un peu plus nombreux).
Maintenant dans le cadre IRL de l'industrie informatique (le monde proprietaire si tu prefere) Qt est a peine existant (il commence a emerger) et Gtk+ il est inconnu.

Sur ta planète on n'est pas très informé. OSF est devenu DecUnix qui est devenu Tru64 qui existe toujours :
http://www.tru64unix.compaq.com/(...(...))

Enfin moi aussi je lui donne pas longtemps, je pense qu'il va y avoir une fusion HP/UX True64 rapidement vu que les deux sont assez complementaires (et ca serait complement debile pour HP/Compaq d'avoir le cout de dev des deux Unix).
Sinon on sait jamais ils pourraient meme tout laisser et passer au full Linux (ca serait pas mal d'avoir les devs d'HP et de Dec sur Linux).

Ibm semble autant interressé par Gnome que KDE :
http://www-1.ibm.com/servers/aix/products/aixos/linux/rpmgroups.htm(...))

Enfin IBM est surtout interesser par Linux, pour les desktops Unix, IBM n'a pas reelement de marche pour ca actuellement (enfin si 1 mais la ils peuvent pas se permettre de changer radicalement l'ancienne interface user: CDE).

Java peut maintenant utiliser Gtk.

Ca c vraiment bien, ca evitera des flickering a deux balles ;)

HP le propose aussi et a un partenariat avec Ximian (comme ibm : http://www.ximian.com/about_us/partners/profiles.html(...(...)) ).

Ca j'ai toujours pas compris pourquoi ils ont signe avec Ximian vu qu'ils on tjs pas de stations avec gnome. Enfin si ca les amuse

Il y a IBM qui propose Gnome et KDE.

j'attends de voir pourquoi ils appuyent les deux projets. Pcque actuellement c comme HP et SUN: wait and see.

Lorsqu'il faudra développer de nouvelle appli, Motif ne sera pas utilisé. Il y a principalement Qt et Gtk. Qt est GPL, donc il faut fournir les sources. Je m'en plaind pas mais c'est pas forcément du goût d'IBM, etc.

Justement ce qu'il faut savoir c que generalement les grosses boites ne faisaient/font/feront plus de logiciel uniquement basee sur le tk mais plutot sur l'ensemble des libs desktops (avant CDE, maintenant Gnome/KDE), un peu comme sous windows.
Or ces libs (gnomelibs/kdelibs) sont LGPL donc ta problematique est resolue assez simplement ;)

Gtk est LGPL et c'est un plus pour eux.

Comme dit plus haut ca ils s'en foutent, c'est plutot les licences des gnomelibs et kdelibs qui les interessent.

Ou alors Trolltech vend des licences proprios et c'est retour à la case Motif.

Je voit pas pourquoi. Trolltech leur fournit les sources de Qt avec les licences et la version GPL est interchangeable avec la version QPL. La comparaison avec Motif n'a aucune raison d'etre.

Et si c'est un succès, on peut se demander si Trolltech va beaucoup bosser sur la version GPL...

Pour ton info la version GPL et la version QPL sont les memes (memes sources, meme tree, ...) la seule difference etant que quand ils packagent la version GPL il passent un script qui "efface" les fichiers relatifs a la version windows (et jusqu'a peu la version macosx aussi).

Mais j'arrête. Ici on aime qu'un boîte vende des licences proprios et j'ai mes XPs qui parte en fumé.

Arf, le probleme c'est que tu as du mal a comprendre que sur certains developpement tu ne peut vendre du service. Le service ne peut reelement etre rentable que sur des logiciels utilisateurs necessitant de la configuration, du tuning, du dev. Quand tu vend un librairie (de surcroit en fournissant les sources) a des developpeurs (je parle des petits, pas de grosse boites) il faut bien se rendre compte que rarement ils vont telephoner et que si ils ont moyen de l'avoir pour rien ... (je parle par experience)
De plus si ils ont les sources tu peut presque etre sur qu'ils risquent pas de trop renouveler la licence.
Dernier point, je connait plusieurs boites que ca derange vraiment pas d'avoir a utiliser une lib GPL pour des outils internes (ils s'en foutent c pas exporter).

Bon j'arrete aussi pcque mes XP aussi jouent aux montagnes russes.

Pas de chance, je connais motif, j'ai beaucoup développé avec.

Ben alors pkoi tu dis que certains widgets Qt sont rempompes de Motif ?

Dans le logiciel libre pas de support comme tu l'entends. </>i

Ben vi, a un moment pour une boite ou je travaillait, on cherchait un tk sous unix pour plus utiliser motif et personne n'assurait un support pour Gtk+ (et meme RH) qui nous statisfesait (et non ca n'etait pas moi qui choisisait sinon me serait pas pris la tete)

Question : T'es un porte parole de MS, du logiciel proprio ?

De MS non je laisse ca PBPG ;)
Maintenant je t'avoue je travaille la semaine dans une boite qui ne fait que du proprio.

Et pourquoi xiniam ou redhat ne peuvent pas faire ça ? Et pourquoi ce qui marche si bien pour gcc, Linux, Apache, PHP, MySQL, PostgreSQL, etc, etc ne peut pas marché pour Gtk.

Entre assurer un support sur une application a des utilisateurs et une librairie a des developpeurs le besoin n'est pas du tout le meme. Quand tu comprendra ca tu pourra alors voir que RH et consorts eux ne s'occupent quasi uniquement que de la premiere categorie car:
- les clients sont moins chiants (moins pointilleux, ne cherchent pas comprendre les bugs, ...)
- ca rapporte plus au niveau support (toujours qquechose a configurer, a deve par dessus, ...)

À part dire "vire le logiciel proprio" et casser le modèle du logiciel libre en entreprise je ne vois pas où tu veux en venir

Je te laisse delirer sur ce que tu as cru comprendre de ce que je disait (et la je t'avoue que je comprends pas).

C'est vrai que vu comment Qt3.2 est assez bien avance (en phase beta) et que on peut voir de nombreuses references a Qt4 partout dans le code, je pense que Qt4 doit etre assez bien avance. En plus je ne pense pas que les gens de cygwin pourront aller aussi, voir plus vite que les gens de trolltech/kde sans leur aide. Donc soit Trolltech contribuera a livrer un Qt GPL pour win, soit ca va etre la course.

C'est vieux. Gtk a été développé nettement après Qt. C'est normal. Puis il y a aussi Gtk 1.2 qui est un très bon toolkit (voir le nombre d'excellentes applis qu'il l'utilisent).

J'irait pas a dire jusqu'a "tres bon", Gtk 1.2 est un bon toolkit mais pas extraordinaire par rapport a Qt2 il avait vraiment bcp trop de lacunes.
De plus ton argument que c'est un "tres bon tk" juste pcque on a un nombre consequent d'excellentes applis qui l'utilisent ne tien pas. Car sinon ou pourrait dire que le tk win32 est extraordinaire ce que personne n'oserait jamais sortir (comme quoi malgre bcp de limitations et avec bcp d'imagination on peut en faire des choses).

C'est normal, Gtk est arrivé après Qt. Je connais pas très bien Qt, mais Gtk doit aussi avoir des widgets qui lui sont propres. Puis ce type de commentaire ne mène à rien :-) . Je peut dire : "Un certain nombre de widgets de Qt sont copiés de Motif".

Tu ne dirais pas ca si tu connaissait motif ;)
En fait la grosse majorite des widgets Qt ont justement ete cree par Qt et souvent, je l'avoue, en suivant les idees "prototypees" par les widgets NextStep. Et en etant honnete Gtk+2 a bien "pompe" les widgets de Qt2 (et encore pas tous ce qui est un peu dommage) mais face a Qt3+kdeui ca fait toujours un peu limite (meme si on compte les widgets gnomeui qui ne sont que dans la majorite des extensions des widgets de base).

Il y a "graphics".
Pis, je suis désolé, mais c'est pas cool de dire que tu n'as pas de support avec Gtk car c'est GPL. Il y a du support pour Linux/gcc/etc et c'est GPL. Donc du support ça se trouve (voir Xiniam aussi : http://www.ximian.com/support/premium.html(...) ). Si le support dont du parle c'est du bugfixe courant, toute les distributions le font (bien que rare car Gtk est assez stable) comme il le font pour Linux/Apache/Php/evolution/etc.

Ca c'est particulierement FAUX. Je pense que tu situe mal ce qu'un boite attends comme support d'une autre leur fournissant une lib.
Pour ton info, les clients veulent pouvoir te joindre a n'importe quel moment pour comprendre un truc qui leur parait flou, les aider a debugger leur code "glue" (qui utilise la lib vendue) qui foire (souvent due a un probleme de comprehension), que tu leur developpe un code (par ex, dans notre cas un widget) qu'ils n'arrivent pas a faire (manque de temps, probleme de comprehension, ...), ...
Et ca personne ne le fait pour Gtk+ (a moins que tu embauche un dev principal de Gtk+).
Maintenant ca n'est pas pcque il est mauvais juste que le service et oriente differement.

PS: sinon je confirme gtkmm est vraiment pas terrible du tout, je prefere nettement faire du Gtk+ natif dans du code c++. Et c vrai que Gtk+2 c'est sympa, mais ca le serait plus si ils avaient pas decoupe ca en 5 libs.

Vi Mais de nombreuses boites on acheter la licence Qt pour faire des applications a usage interne sur de multiples plateformes. (cf nombreuses licences dans le domaine du montage et des effets videos). Or si ils ont moyen d'avoir la meme chose pour rien ...

les gens pourront utilisé les logiciels gpl/qt3 sous win32 ... et s'habituer à ceux-ci et après, ils n'auront plus aucune raison de ne pas passer à linux, car en plus ces log tournent bien mieux sous x !!! Justement moi je voit plutot que ca va entrainer l'effet inverse. Ce qui fait que linux s'impose c'est l'ensemble des applis qui sont autour et non uniquement le noyau. Si jamais on porte les applications phares de linux sous windows les utilsateurs "lambdas" ils ne verons surement pas l'interet de passer a linux juste pour le noyau et deux trois trucs en plus si il a deja un windows qui marche avesc les meme applis.

Je vait me repeter mais, quel est l'interet de porter kde sous win ? Et surtout de faire un Qt GPL sous win qui serait assez mauvais pour la sante financiere de trolltech ?

consistant en le portage euh.. lol fo remettre les mots dans le bon ordre: portage le consistant en ;) ayant commencé quelques mois auparavant rapide. euh.. faudrait peut-être relire non ? je ne comprends pas tout... C'est pourtant tres clair ;p

Il n'empeche : quand je lance deux applications equivalentes, l'une sous Gnome, l'autre sous KDE, (attention, estimation personnelle de moi en tant qu'utilisateur), l'application Gnome se lance generalement plus rapidement et semble mieux se satisfaire des systemes limites en ressources.

Oui, l'ensemble dcop/kdecore est un plus lent a se lancer qu'ORBit.
Maintenant il y a un truc en plus, c qu'ORBit une fois lancer ne s'arrete pas (il reste en demon) meme si l'appli qui l'avait "lancer" se termine alors que dcop lui se termine avec la derniere application qui l'utilise.
Ca n'est pas le meme comportement mais je peut pas juger lequel est le plus intelligent

en tout cas, merci pour l'info de kdebugdialog : j'en prends bonne note

De rien

Apres, il est possible que les configs que j'utilise aussi ne sont pas celles pour lesquelles ces environnements sont utilises, et je le comprends. C'est aussi pour cela que je suis content quand des applications se restreignent a gtk ou qt ou motif, et qu'elles font leur boulot efficacement !

En fait si tu veux utiliser des applis KDE (sans le desktop) il est conseiller de demarrer les demons kde, sinon c pas "utilisable" (flood de traces, lenteur de demarrage,...)


C'etait mes deux centimes d'euro

Voila les miens

lol
excellent

Finalement je crois que tu te fous de ma gueule. kdevelop utilise kdbg pour le debugguage. C'est vraiment pas au niveau de ddd. A côté de ddd, kdbg c'est ... oublions je ne veux pas être méchant.

Faux, teste donc gideon et tu verra que que kdbg (qui servait il y a longtemps comme plugin de kdevelop2) c rien.

Questions :
As-tu sérieusement utilisé ddd ?

Vi pendant qques annees, et il m'arrive encore de l'utiliser.

N'as-tu pas honte de critiquer un projet alors que tu ne l'as pas utilisé ?

Je ne critique pas ce que je ne connait pas.

Si eclipse c'est du même niveau que kdbg, il y a pas photo, ddd reste le roi des debuggeurs et de très très loin.

Renseigne toi avant de sortir des affirmations comme celle la. Eclipse et kdevelop c'est d'un tout autre niveau qu'un pauvre debuggueur texte qui peine deja a demangler automatiquement les symboles c++.

PS: oui kdevelop utilise gdb comme background mais essaye un peu et tu comprendras.

En fait y a truc qui s'appelle xparts qui permet de faire passerelle via X de kparts. Donc ca permet d'embeder du bonobo, du gnustep, ... maintenant c pas ce que peut appeler un truc facile d'acces

et merde vous m'avez pas attendu ;(
Pas grave je repart

Vi c un service, pas trop equivalent a esd mais plutot a une sorte de gstreamer-deamon. Maintenant sache que kdelibs ne compile pas sans arts.
Tu peut desactiver le serveur, mais les APIs arts sont necessaires surtout pour kdemultimedia.

C'est pour ça qu'elle est beaucoup utilisée. mais oui ...

Justement, le probleme c'est qu'elle toujours que partielement utilisee (generalement c surtout l'aspect GUI/HIG qui est tres utilise). Pour moi le fait que bonobo ne soit pas utilise par au moins la moitie des applis gnome ca choque.

> les developpements sont bien plus lent qu'avec d'autres framework.
Comme Windows tu veux dire ?

Arf
Je pense qu'il parlait surtout des frameworks Java, *Step, MacosX (cocoa, carbon), BeOS, KDE... qui sont surement ceux les plus complets et les plus homogenes a l'heure actuelle (g d'ailleurs une preference pour celle de BeOS).

Il y a le feu au projet KDE pour que vous développiez tout ce FUD. Si KDE c'est génial "y tout", il sera utilisé. Si Gnome c'est de la merde, il ne sera pas utilisé.

Non y a pas le feu, ca avance tres (voire trop) rapidement a ce demander si ils prennent des vacances :)
De plus je ne pense pas que Gnome soit de la merde ou que Kde soit genial. Les deux ont une belle architecture et ne font que s'ameliorer au fil du temps. Mais ce que je trouve desolant c qu'autant gnome possede des capacites interressantes au niveau de ses fondations (ORBit/bonobo, ...) souvent bien plus puissantes que les equivalents Kde autant elles sont trop souvent peu utilises et cela sans aucune excuses valables (bonobo c ptet pas simple au premier abord mais c rapidement comprehensible)

Sinon d'un point de vue exterieur, je t'assure que Kde progresse bien plus vite que gnome surtout au niveau des "grosses applications" (office, IDE de dev, IDE web, gravure, ...) qui etaient encore inexistantes il y a un an et qui maintenant sont proches d'etre "releasees" au public (cf kdeextragear* sur le cvs kde). Alors que justement ce point la etait clairement a l'avantage des applis gnome.

PS : Je ne pense pas que Gnome va "exploser" KDE et d'ailleurs je m'en fous complètement.
Moi aussi, et meme chose pour le contraire. Je suis pour la co-existance des deux Desktop qui sont complementaires.

Non non il boude bien.

Il ne fait plus reelement parti de "l'equipe moteur" de l'architecture gnome. Maintenant pour ton ifon, le gros interet de mono est que toute classe devient un composant et la ca fera sauter le blocage de pas mal de personnes de ne pas faire des composants (a condition qu'ils utilisent mono).

D'ailleurs le vrai Quanta (pas l'ancien Quanta Plus) est maitenant une appli totalement native KDE.