Raphael Junqueira a écrit 337 commentaires

Enfin sortir des applis non majeures c facile aussi.

Sinon pour arts c un peu Normal que ca utilise pas Kde car c une fondation de celui-ci :)

Tu n'a rien compris a la programmation par composant vu ton discours :(

Et pourquoi ne pas ajouter le support d'impression dans la calculatrice ? Et un composant bonobo pour utiliser la calculatrice sous evolution ? etc...

Tape kcal dans une console et tu comprendras.
Et gnucash il aurait pas justement besoin d'un composant calculatrice ?

Regarde tout ce qui est utilise par galeon, evolution, gnucash, etc. S'il y a des doublon ils sont peu nombreux

Archi Faux, quasiment chaque appli qui en vient a editer du texte fait un toolkit custo base sur le toolkit editeur de GTK. Meme chose pour la gestion des previsus, etc ...

Tu peux imprimer le résultat de la calculatrice (définir les marges et tout). Tu peux dire à la calculatrice que les données proviennent d'une source réseau ( http://labas/calcul_a_faire(...) ), additionner les numéros de téléphone dans le carnet d'adresse. C'est ... fascinant.

Le but n'est pas de mettre des fonctionnalites "debiles" a des briques de bases, mais de fournir ses briques de bases a d'autres applis qui en auront le besoin (et oui le composant calculatric il peut etre reutiliser, j'en ait deja eut besoin)

En tout cas, c'est du beau troll

Mici ;)

Les applis GTK+ sont pas GNOME parce qu'elles utilisent pas Bonobo, GConf & co

Non, si c juste pour dire que tu utilise deux widgets et que tu link sur gnomeui, je suis desole ca n'est pas une applis GNOME mais juste une applis GTK+ avec une lib de widgets en plus.

Evolution qui utilise Bonobo et les biblios GNOME n'est pas une appli GNOME
Non dans ce cas c'etait une appli GTK+ qui utilisait bonobo comme pseudo integration (en gros essayer de tripatouiller les settings gnome sur les associations et autres). Maintenant ca n'est plus la cas, la version 1.4 est assez bien integree (au sens vrai application gnome)

Galeon c'est pas une appli GNOME parce que ça utilise Mozilla, totem non plus parce uqe ça utilise Xine...

Celles la si, maintenant le fait que Galeon et totem n'utilisent pas reelement bonobo fait que ca va etre dur de reutiliser les "composants" developes a l'interieur :(

Si un développeur n'a besoin que de gtk+, pourquoi utiliser gconf s'il n'a rien comme config, pourquoi utiliser bonobo si ça n'a aucun intérêt, pourquoi utiliser gnomeprint s'il ne fait pas d'impression, etc, etc.

Ben elle est la ton "erreur" d'appreciation. Je peut t'assurer qu'un appli qui ne possede pas de conf c du n'importe quoi: tout utilisateur voudra toujours a un moment donne pouvoir configurer un comportement (pour ton info meme la calculatrice microsoft est "configurable" c'est pour dire). Maintenant tout appli qui developpe un "module" qui pourrait etre utiliser par une autre appli (et croit moi que ca parrait con des fois mais c'est presque toujours le cas) devrait faire du bonobo pour l'exporter pour les autres (et dans le cas ou le composant existe deja du bonobo pour le recuperer). Le plus gros probleme que je trouve dans gnome c ca, le fait que de nombreux gens ne cherchent pas a partager et donc d'autres sont oblige de refaire (voir par exemple la gestion des editions de "textes")

Le plus grand principe de kde est de ne jamais croire que ce que tu fait dans ton coin ne peut etre reutiliser par quelqu'un d'autre (le dernier exemple hallucinant etait un composant editeur hexadecimal qui subbitement c retrouve utiliser par une dizaine d'applis).

Tu vas pas me faire croire que TOUTES les applis KDE utilise TOUTES les facilité KDE.

Ben si, meme la calculatrice, le notepad, knotes, klipper, ... ;)
Tu apprendrait beaucoup a voir ce qui a pu etre partager et comment certaines applis sont concues (les must dans les domaines archi qui font mal sont kate, koffice et kdevelop).

Tu vas pas me faire croire qu'il n'y a que des applis KDE et aucun applis qui n'utilisent que Qt.

Non y a pas mal d'applis Qt a vocations d'etre multi-plateformes. Mais surtout bcp moins integre donc bcp moins utiliser que les applis kde equivalentes.

C'est un défaut ?

Non c justement un des principaux interets des applis GTK+ et Qt pures.

Tant mieux pour KDE. J'ai rien à dire sur KDE. Si KDE est hyper balaise, tant mieux pour eux. J'utilise Gnome, mais je ne vais pas critiquer KDE.

hmmm. Je ne critiquait pas reelement gnome je cherchait juste a rectifier les choses sur le fait qu'actuellement (et encore plus sur la future version) KDE possede un ensemble coherent et presque complet plus riche que gnome (et cela en etant parfaitement objectif). Les points ou KDE est justement tres mauvais sont les points sur lesquels justement les applis gnome sont "parfaites" (donc personne ne s'est amuser a les refaire du cote kde)

Et encore un troll.
Comme evolution ou gnucash ?

Evolution c un cas tres particulier car pas vraiment une appli gnome en terme d'integration (uniquement a partir de la version 1.4 et encore avec des lacunes d'interoperabilite). Pendant tout le temps que je l'ai utilise, il a presque pas varier et actuellement, face a la combinaison kdepim de kde (CVS kde) il fait pale figure.

Gnucash c sympa mais y a la meme chose cote kde, et vu que j'utilise pas ce genre d'appli...

glade utilise gnome :

Au temps pour moi

Et réfléchit un peu, glade utilise forcément Gnome puisqu'il permet d'utiliser les widgets gnome en wysiwyg

Au lieu d'etre "aggressif" , c toi qui ferait mieux de te renseigner. QtDesigner arrive bien a gerer tous les widgets KDE en wysiwyg alors que c'est une application Qt pure et moi je pensait innocement que ils avaient reussi a faire glade (et GTK) de facon suffisement dynamique pour etre capable de la meme chose.

Je suis sidéré. Il y a mieux ? Peut-être GVD.
Mais celà rend ddd "difficilement utilisable sur du vrai debuggage".

Et merci de me remettre en mémoire qu'il y a GVD qui utilise gtk :-)

C vrai que deja GVD c mieux, mais bon un debuggeur comme celui integre dans eclipse ou kdevelop sont nettement plus adapte a une utilisation sur de gros projets.

Vi mais la majorite des applis gnome n'utilsent que partiellement les APIs gnome (pour ne pas trop perdre en portabilite) et bien d'autres ne sont en fait que des applis GTK+ etendues ;(

une seule application (dcop and co.) qui generent en plus un flux de donnees sur la console)

T'est pas objectif la, gnome a le meme defaut avec ORBit/bonobo. Maintenant si tu lance que des applis gtk+ c autre chose. Et pour ton infos les traces tu ne les as que sur un niveau debug de KDE ou bien si tu as active les canaux de traces (cf kdebugdialog pour les desactiver)

C'est sous gnome qu'on trouve souvent les meilleurs applis :
- evolution
- galeon
- gnucash
- gnomemetting
- etc

Au lieu de troller comme des oufs...


Et c toi qui parle de trolls...
Regarde un peu ce que kde nous prepare pour la 3.2 avec:
- kmail, korganiser, kalendar, kontact
- koffice
- konqueror
- kdevelop
- kaboodle
- kopete
- kpovmodeler
- k3b

et on en reparlera des tes "appliquettes" gnome
Les seules applications qui me plaisent bien dans le style gnome sont glade et gimp (meme si elles sont a la base natives gtk+)

PS: anjuta c'est pas un IDE digne de ce nom, emacs il fait bien mieux pour les meme fonctionnalites. Et ddd c'est difficilement utilisable sur du vrai debuggage.

Par contre, il reste toujours le problème d'un manque de documentation correctes pour bien des interfaces. Peut-être qu'on a pas donné assez de pognon à MS. Ou alors j'ai pris l'habitude d'avoir la documentation gratuitement avec Linux ... (oui oui c'est un troll :) )

Faut regarder le code de wine, c souvent bien plus clair ;)

Petit précision, ce qui correspond à COM du côté GNOME c'est bonobo

Vi excuse moi pour ce "raccourci", pour moi c naturel car je voit mal qqu'un faire de l'ORBit pur ;)
Enfin bonobo a toujours ce defaut de montrer trop les couches CORBA, donc trop lourd a manipuler.

Est-ce qu'on ne peut pas standardiser les langages de scripting des applications sous Nux ? KOffice, GNOME Office, OpenOffice.org, tout le monde a à y gagner, à avoir des scripts portables d'applis en applis.

Justement pas mal d'applis commencent a pouvoir etre scriptables et en regardant le langage majoritaire semble etre le python. Le plus drole c que meme des grosses applis bien commerciales l'utilise aussi (maya, ...). Ca peut faire un standard de fait. Maintenant l'interet du libre c aussi de laisser le choix alors je suis plutot partisan du principe de moteurs de scripts integres aux desktop sur lequels viennent se plugger des langages de scripts.

Je vois mal Apple et MS tenter de standardiser quoique ce soit, puisque pour eux, c'est un argument de vente : "les autres n'ont pas"...

Tu aurais tord de penser cela, Apple commence a mettre de l'applescript partout dans leurs applis et MS eux ils foutent du VBA un peu partout aussi (on peut meme scripter IE et l'explorateur avec)

- des interfaces spécifiques non accessible de l'extérieur (The Gimp, GnuCash, Emacs...)
- rien (OpenOffice.org...)


Normal les applis que tu cite ne sont pas integres a un desktop (nii kde, ni gnome, ni gnustep, ...) donc ne profitent pas des possibilites de ceux-cis.
Maitenant a part pour The Gimp, les autres ont des equivalents bien mieux integres.

D'autre part, si on veut que son appli soit scriptable dans n'importe quel langage, il faut que l'appli aie accès à une interface commune à tous les interpréteurs. Cette interface doit permettre de:
- lister tous les interpréteurs dispos
- pour chaque interpréteurs, de lister les scripts étendant l'application pour ce langage
Ce qui donne (par exemple):
COM <-> Python <-> interpréteurs <-> application <-> COM

Ben justement le moteur kparts/scripts de kde fait justement ce que tu dis la. Le but est de pouvoir facilement ajouter un langage de scripts qui utilisera les interfaces kparts (de memoire c surtout kdevelop qui l'utilise)

Pour ton info QSA et kparts sont complementaires et non "identiques". Corba ne correspond qu'a un equivalent de kparts.

QSA n'etant qu'un acces scripte a Qt, alors que kparts et ORBit (le corba de gnome) sont des "equivalents" a DCOM

Et bien que COM te semble simple, je peut t'assurer que c clairement pas le cas des que tu veut l'utiliser reeleement. Et pour l'implementation d'un composant COM tu rigole bien aussi.

Essaye donc kparts (et meme ORBit) et je peux t'assurer que tu toucheras plus a COM :)

Perso j'essaie de faire marcher need for speed porsche ces jours-ci.. Je m'e approche mais j'ai besoin de plusieurs DLL Windows natives il me semble :/ Je vait voir ce que ca donne, mais je pense que Lionel (vu que si je me rappelle bien c un jeu pre dx8) sera surement plus apte a t'aider tu as une url de googlethread ? :) http://www.winehq.com/index.php?issue=122#Quartz.dll%20Removal http://www.winehq.com/hypermail/wine-devel/2002/05/0040.html http://www.winehq.com/hypermail/wine-devel/2002/08/0438.html

Meme probleme, meme solution PS: D'apres toi les installeurs ils utilisent la base de registre ?

pour le dernier ils disent d aller voir sur winehq , pourtant j ai beau faire leur truc proprio "emule" beaucoup mieux office/outlook/explorer qu avec wine .

Fait un test, install un wine officiel et rentre a la mimine l'ensemble des cles de la base de registre necessaire aux applis (tu peut les trouver sur un windows deja installer, mais tu doit en modifier certaines). Tu verras ca marchera pareil.

perso je met codeweavers et transgamming dans le meme panier ils font du proprio et du "libre".

Ou tu voit que TG fait du libre ?
et en quoi une boite comme CodeWeavers qui vent un support, une conf plus qques utilitaires facilitant la conf te choque ?
Si qu'un boite cherche a faire de l'argent te gene je peut rien pour toi.

Ah, OK. Et ça ne pose pas de problèmes avec la LGPL ? Leurs softs me font tout de même l'effet d'être des produits dérivés, non ?

Non, pcque en fait ils livrent juste un .reg bien complet (avec les cles de registres d'ie, toshop, office, ... qui vont bien), le .config et un executable pour gerer le tout.
Maintenant il faut savoir que les modifs du .reg de codeweavers ne seront jamais dans wine car c du pur bypass. En clair, ils preentrent des clefs dans la base de registre qui devraient etre initialisees par install shield lors des installs des dites applications.

Pourquoi ? Au contraire, je soulignais l'effort que toi et les autres avaient fournis. Je ne vois pas très bien ce que tu trouves choquant. M'enfin bon, je suppose que c'est juste une lecture un peu hâtive...

Desole, j'etait un peu a cran :(

En tout cas, merci quand même pour le boulot que tu as fourni. Pour ce qui est des nombreux (jeux ?) qui marchent très bien, ceux que j'ai passent effectivement pas mal, mais ils sont assez vieux, je te crois donc sur parole...

Merci, Tu peux remercier toute l'equipe sur la ml :)
Pour des jeux "recents" qui marchent assez bien je teste principalement (les demos vu que j'ai pas bcp de jeux complets): UT2003, MaxPayne, war3, mafia (tous des jeux directx8)
Sinon pour info on est a deux doigts de faire marche unreal2 (on bloque sur l'init du son apres la demo du debut)
Maitenant, il d'autres jeux marchent assez bien mais vu que les users ne font des retours (et pas toujours) que lorsque l'on regresse...

Au fait, pour ce qui est des protections anticopie, y a-t-il quelque chose de prévu (puisqu'apparemment, ça fait tiquer certains) ?

En fait, la principale limitation actuelle c le fait que l'on n'a plus d'implementation de directshow (cf l'ancienne thread sur la demande de suppression du code quartz du tree wine par le developpeur de celui-ci) alors que transgaming l'a "gardee" (ce qui est, pour moi, le plus choquant de la part de TG).
Et on est sur le point de reavoir une version qui marche (cf les premiers patch dshow sur le cvs)

Pour la protection anticopie, le probleme n'est pas si "dur" que ca (mais pas simple non plus), il suffit juste de fixer les bugs/lacunes de la gestion des lecteurs CD (lecture,identifiction,...) afin de le rendre parfaitement identique a windows. TG a prefere sur ce point avoir acces au code d'un des plus gros fournisseurs de ses systemes de protections pour corriger le necessaire.
Nous, on devra y aller aux tests de reverse engeneering comme d'hab.

Raphael

hmmm

On va clarifier la situation:
- transgaming ne "donne" a wine que le minimum (et souvent avec interet cf le code de com/dcom afin d'avoir l'aide de devs de wine)
- la version cvs sur sourceforge de transgaming ne contient que peu de choses de la version livrees au clients de ceux-ci (tu peut facilement le voir que regulierement ils parlent de synchro entre leur tree interne et celui de sf)
- pour codeweavers tout leur code redescend dans wine regulierement (ie qd leur tree est stable alors AJ synchronise avec le tree wine officiel)
- les produits de codeweavers ne sont uniquement que des packages wines pre-configures (et c'est ca qu'ils font paye, libre a toi de faire la conf de ton wine tout seul)

Sinon CodeWeaver n'a pas cherche a mettre des "batons dans les roues" de Transgaming, ils voulaient (comme pas mal de gens et de boites qui tourne autour de wine) que transgaming partage aussi (ce qui ne les enchantait pas).

Sinon, ton info, il y a actuellement pas un mais plusieurs developpeurs qui travaillent sur directx (et d3d) qui n'etait pas a l'abandon mais n'existait presque pas et de nombreux marchent tres bien actuellement. De plus traiter cela de tache ingrate de ta part me semble bien deplacer.

Je veux pas etre me-disant mais je pense qu'il ne vaut mieux pas :)

En fait c'etait bien plus que du VRML. A cryo-networks ils faisaient tous les jeux avec (ce qui explique pas mal de choses).

Mais au final c un bon petit language, proche du caml mais qui possed un framework sympa.

PS: qq'un sait si y a le debugger integre ?

il est introspectif par nature, permet de gerer assez facilement la serialisation (car il gere une sorte de versionning).

Au final c le deuxieme langage objet ayant des origines C mais qui lui a garder le plus de racines avec son "ancetre" tout en evitant certaines des grosses failles de son petit frere. (qui lui reste malgre tout ses defauts le plus puissant)

toutes les fonctionnalités du svg sont implémentées dedans ?

Ben aux dernieres nouvelles, les developpements sur svg se sont mechament calme car il y a encore 4 mois c'etait le top 1 en nombre de commits/mois sur le cvs kde :)
Donc ca laisse presager qu'ils sont bons, surtout que la libart qui sert de base aux moteurs de rendus svg de gnome et kde a semble t il aussi ralenti au niveau du developpement

surtout gnome et kde sont en train de baser toutes leurs icones standards sur du svg (et meme ajouter un pseudo-moteur vectoriel pour des wolis effets)

Pour le moment, il n'existe aucun browser pour visualiser du SVG tranquillement sous Linux.

bouhh, cette denigration:
essaye donc mozilla+mozilla-svg ou alors konqueror

non non ksvg n'est pas que pour konqueror.
il sert aussi aux icones: et vi depuis la 3.1 une bonne parties des icones sont en svg qui sont rendus en plusieurs tailles de png au demarrage de kde.
de plus si je me rappelle bien koffice utilise ksvg dans leurs programmes de dessins vectoriels.