Raphael Junqueira a écrit 337 commentaires

on ca a rien a voir.

J'avait un proto ou tu scrollait tout en ayant un effet de zoom et non un changement d'icone a la volee comme kicker. Le must c'etait la taskbar avec la miniature d'une fenetre qui zoomait et l'icone de l'appli en surimpression :)))

Bon fo vraiment que je le refasse pcque c'etait un code pas tres catholique derriere. Mais ca me fait chier d'avoir de la fausse transparence pcque c tout lent, et le zoom de pixmap en software c pas glop non plus.

excuse-moi, deviation professionnelle :)

En fait actuellement des devs des deux suites "rattachees" aux deux DE travaillent sur le split des modules d'import/export de OO en des modules separes.

En gros ils veulent unifies le travail des trois suites sur des modules "standards" qui sortiront du xml "standardise". Y a du boulot, c pas motivant, mais ca avance. Le probleme va etre, je pense, de limiter les dependances de ses modules au max (pcque si ca depend de la glib+moitie de OO+... ca va pas le faire).

Slicker est une interface graphique inovente, qui pourrait trés bien étre porter pour Gnome.

Ben pour ca, ca sera tres dur. A la limite la refaire "from scratch" pour gtk+ serait plus realiste car slicker est surement un des codes que j'ai vu utiliser le plus "finement" les specificites de Qt.

Sinon pour karamba, ca doit etre vraiment tres simple de le porter sous gtk+ car le code vraiment critique c presque du code X natif :)

excellent :)

bon des que g un peu de temps je vait aussi jouer avec

Ca me donne l'envie de mettre la taskbar "a la macosx" par dessus tout ca: slicker + karamba ;)

Vi c assez connu ce probleme. c d'ailleurs pour des problemes comme celui-la qu'il est conseille d'avoir des disques raid-SCSI pour tout ce qui est critique.

Si tu le croix ... Reiserfs et xfs ont des qualités fortes. Mais pas ça. Et aucun fs n'a ça. Fais un arbre binaire, par exemple, et tu véras que ça n'existe pas. C'est des graphes leurs structures de donnees. Apres le fait qu'ils utilisent les "forets" pour leur utilisation cela va de soit. J'avait bien lu les docs sur la reiserfs et je peut t'assurer que tu ne risque vraiment pas (sauf si bug tres critique qui a mon avis se verrait rapidement) de destabiliser ta structure de donnee. Et maintenant c'est la faute de fsck... Non la faute premiere a ete du fs, fsck n'a fait que donne le coup de grace en essayant vainement de recuperer une structure qui etait totalement morte :( Si ext3 est naze, il ne serait pas autant utilisé. Redhat qui est pointu dans le domaine des fs, et très prudent sur la fiabilité, n'a pas choisi ext3 pour ces performances (qui sont correcte mais parfois moindre que ReiserFS) mais pour sa fiabilité. J'ai jamais dis qu'il etait nase juste qu'il pouvait, dans qques cas extremes j'en suis conscient, etre pas aussi sure que les nouveaux filesystemes (ce qui est logique en soit car ils ont ete developpe avec l'experience industrielle acquise par les gros du monde unix sur la coherence et la resistance a l'erreur). Je suis tout a fait d'accord sur le fait que l'implementation de la couche ext3fs contient nettement moins de bugs que celle des autres fs tout en etant bien rodee et performante. D'ailleurs je comprends tjs pas l'interet des fsck sur les fs xfs et reiserfs car theoriquement ils n'en ont pas le besoin (mis a part pour reparer des conneries du a des bugs)

Sympa ca faisait longtemps que j'avait decroche de ce logiciel il a bien avance :) Enfin a mon avis l'ideal serait un mix de celui-ci (nivo ergonomie, philosophie) avec les 2-3 logiciels phares du graphisme qui etaient sous BeOs (souvent d'ancien de l'amiga) avec la puissance de photoshop. Ca doit clairement etre faisable,

Je suis pas si certain que toi, c vrai qu'actuellement le framework .Net est bcp plus complet que celui de mono mais il faut relativiser en voyant que les personnes competantes chez ms on surtout travailler sur le compilatuer et la vm (+JIT). Sachant qu'en general le libre developpe du code en general bien meilleur que celui proprietaire, je serait pas etonne que ms utilise des portions des fw mono au fur a mesure dans .Net histoire d'avoir du code plus fiable, etc... Maintenant en l'etat actuel ils peuvent clairemetn pas utiliser grand chose

t'inquiete ils voulaient aussi travailler sur un clone de VB, apres integration dans evolution je pense que certains vont vraiment s'amuser .) Bon l'avantage c'est qu'au pire on se fera pourrir un compte user, mais on ne sait jamais ...

OO est un gros machin, certe, mais justement, en mettant des hackers competents familiers avec le logiciel libre, on devrait reussir a rendre ce truc utilisable. Je suis d'accords, mais je pense que vu l'etat de OO, il serait plus interressant de separer le code interessant (les modules d'import/export) pour les integres dans les suites bureautiques de linux qui sont, selon moi, bcp mieux pensees, plus souples, plu legeres et surtout bcp plus ergonomiques. Le hic venant de la portabilite de la chose (mais g des doutes sur ximian OO au vue de ce qu'ils veulent faire) Mon plus gros reproche a OO, outre sa lenteur, c'est son manque total d'integration dans le desktop. Je ne peux pas configurer mon imprimante (0.0001% des fonctionnalites de kprinter dans leur 'print panel'), le polices sont pas AA, plein de trucs sont bizarre. Vi en gros tout ce que font bien les applis citees dans mon autre commentaire :) Je vais accueillir avec joie la version de Ximian. Moi j'attends de voir, je l'acceuillerait aussi bien si elle marche a iso-fonctionalites sous windows et macos (sans de cochonneries de pseudo-serveur x) ... ils ont un clone de Mono... lol Mono clone de mono :_ Plutot un clone du compilateur C# et une reimplementation du framework .Net :)

Sur le fond je suis d'accord. Mais je crois que tu sous estime un poil l'intérêt d'OOo pour la communauté. Que cet intérêt soit justifié ou pas , la question est trollesque. un poil trollesque je le concoit mais je voulait pousser une geulante car je trouve pas ca pertinent. Le fait est que OOo apparait comme une possibilité de substitution à MS Office, qu'il commence à être connu pour cela, est que l'améliorer pour rendre cette alternative encore plus crédible est logique. OO n'est pas trop connu, staroffice l'est. Maintent le rendre plus credibble je suis d'accord que c'est une solution pour ceux qui veulent s'appuyer sur les (petite il faut l'avouer) reconnaissance de StarOffice. La question qu'on peut se poser est: pourquoi Koffice, Kspread, Gnuméric, ... n'apparaissent pas comme des possibilités de substitution ? Justement ces logiciels sont bien souvent bien plus ergonomques et mieux penses que O (et aussi bien mieux integre aux DE et a linux en general) leurs seuls gros defauts comme tu les cites seraient: la faible compatibilite avec les format MS, la maturite (relative) de ceux-ci et la portabilite Hors pour la premiere solution les devs koffice, g-office pensaient utilser des librairies de compatibilite partagees (qui seraient d'ailleurs basees et partagees par OO) donc au final, vu que je pense qu'ils sont proche d'arriver a une version stables des logiciels, le seul interet de OO serait l'utilisation a l'identique sur tous les OS. Mais vu les changements que veulent faire ximian g des doutes que le comportement de OO serait tjs a l'identique sur toutes les plates-formes.

Ce qui me fait halluciner c'est ca faculte a tjs changer de point de vue (changer de chemises ?) rapidement. Ce qui m'a plus choquer en lisant cet interview, c'est la facon dont il met ximian a fond sur OO qui soyons realiste est un gros machin qui marche pas trop mal mais qui est demesure par rapport a ce qu'il fait. Alors que en regardant du cote des suites bureautiques gnome ou kde, on voit des applis tres legeres (par rapport a MS office ou OO) tout en etant pas tres loin du niveau fonctionnel de OO voir de MS Office pour certaines applis. Le fait que dire que OO est plus apte actuellement a convenir au client est realiste, mais le fait qu'il va faire pas mal de dev dessus avant de livrer sa version de ximian oo, j'aurait preferer qu'il mette ses ressources sur gnumeric/abiword ou koffice qui auraient pu ainsi atteindre le meme niveau. Surtout quand on voit que ce qu'il veut ajoute a oo, les deux suites sus-citees l'ont deja depuis fort longtemps. c'etait mon coup de geule de la journee, car je supporte pas de la demultiplication d'effort que je trouve inutile comme celle-la :(

partiellement d'accord avec toi. Je pense que la LSB aurait du se focaliser sur l'organisation hierarchiques de linux: conf, binaires sys, etc ... afin de rendre plus facile la transition d'un distrib a une autre et faciliter l'installation de "RPMS" (beurk) tierce multi-distribs. XFree (ou tout autre couche graphique) n'etant qu'un prerequis pour toute application graphiques. En clair, j'aurait plus vu des couches LSB du genre: - couche systeme (/sbin, /bin, /etc, /var, /tmp, ...) - couche user (/home, /usr/bin, ~/tmp, ~/Desktop, ...) - couche graphique (/usr/<layer graphique>/bin, ...) ou chacune une homgeneite qui "etende" la definition de la couche inferieure Sinon je suis clairement partisans de ne pas appuyer XFree mais appuye sur le "nouvel XFree" via les differentes ouvertures apparues depuis peu. C maintenant que l'on peut jouer un role et essaye de contribuer a qquechose qui ne pourra qu'etre mieux que l'existant :)

Si j'ai tout suivi, le problème n'est pas d'imposer XFree face à autre chose, mais d'imposer XFree tout court. Pour un serveur, ça ne se justifie pas du tout. Vi le fondement du probleme vient de la. Maintenant meme si une couche graphique est facultative pour un serveur, elle pourrait tjs etre acceptable si seulement elle etait supra legere (ce que n'est vraiment pas du tout XFree autant que celle de windows NT)

Ouiiiiii je me demaidait ce que j'allait pouvoir faire de mes soirees dernierement vu qu'il commencait a faire beau et que l'abus soleil n'est pas compatible avec mes yeux. Maintenant je saiy, au lieu d'essayer vainement de developper :) Sinon treve de plaisanterie il a quelle geule le code ? c jouable d'en faire qquechose de bien ? Raphael, deprimie pcque le proxy/filtre de sa boite ne le laisse pas le downloader :(

la majorite des tres grosses cartes graphiques haut de gamme ont des driver livres avec pour tous les unix (dont linux) Oui mais pour celles-là il faut hypothéquer sa maison ;-) Ca pour sur, mais vu que j'en ai qqu'unes de dispo au boulot je peut confirmer :) Sinon j'ai pu aussi remarquer que meme ces cartes haut de gammes n'implementent pas toutes les specs OpenGL en hardware (deja c souvent que la version 1.2 des specs en plus + qques ajouts fabricants)

Il me semble que dans le cas d'OpenGL, c'est l'API complète qui a été pensée dès le départ, pour être entièrement câblée de manière matérielle Vi c vrai, maintenant il faut savoir qu'en fait comme les GPU actuels sont programmables ce sont les drivers qui implementent ce qui etait precedement cable en dur dans les CG haut de gamme (enfin bien sur pas les primitives de calculs 3d et autres choses de bas niveau). Ce qui explique pkoi deja les cartes actuelles coutent moins cher: - sont moins complexes a fabriquer car moins de "hard path" des algos - plus evolutives et plus programables via l'utilisation de l'experience acquise sur les CPU et les DSP - ... Enfin il faut aussi savoir que pas mal de fonctions openGL (d'ou mes 30% restant) sont laisses a la charge de l'implementation par defaut de l'API (quand le fabricant de CG ne veut pas l'implementer) car ce sont souvent soit: - des fonctionnalites tres peu utilise - des fonctionnalites trop compliques a etre implementees via le GPU. Donc souvent dur a utiliser tout court, donc souvent peu utilisee (ex: la gestion des polygones n-aire) - des fonctionnalites "deprecated"

Ce que j'ai bien aimé, c'est que derrière le poisson d'avril, il y a une vraie revendication quant aux dérives du standard LSB : imposer xfree86, ou un format de paquetage (le RPM), est-ce bien raisonnable ? N'est-ce pas rendre «standard» une certaine idée de ce que devrait-être une distribution linux ?

Tout a fait d'accord [+]
maintenant:
- pour le cas de xfree malheureusement le choix est faible (le temps que berlin ou que le nouvel xfree arrive...).
- pour le format rpm c'est vrai que cette recommendation est totallement "biaisee" car ne suit pas la voie prise par les distribs reputees par leurs gestion des packages (surtout debian et gentoo) mais suit la majorite (c-a-d les distribs commerciales) qui d'ailleurs ne sont pas reelement compatible entre elles meme si elles sont LSB-compliant.

Le LSB a plutot chercher le juste milieu ("ponderer" en fonction de l'importance de l'user base semble t il) entre tout les distribs et n'a pas chercher a reelement ameliorer les choses en forcant une vrai organisation propre et homogene (ca semble etre revu dans les passes actuelles mais bon).

A mon avis, un truc comme Photoshop disponible sous Linux ca serait une bombe atomique. Les developpeurs de Gimp seraient encore plus demotives.

Je suis bien d'accord sur ce point. Mais ca donnerait un tel coup de boost a l'utilisation de linux dans le monde pro car de tres grosses boites de prod, post-prod, etc... doivent actuellement avoir un parc heterogene windows/mac - unix et le fait de tout pouvoir faire sous linux...
Je sais que certains vont me dire que c'est juste qques boites, pas representatifs de la majorite et qui utilisent deja de l'unix. C vrai mais si les boites qui servent d'avant-garde au monde de la prod et du graphisme passent au full linux, les autres boites du domaine finiront par suivre (et ca sera le bon debut d'un effet boule de neige).

Y a-t-il un projet de ce genre dans les poches des developpeurs de KDE ?

Y a plusieurs logiciels de graphisme sur le cvs koffice mais ca vaut pas grand chose.
Personnellement, j'avait commence dans mon coin a en faire un, surout avec une vrai gestion hierarchiques des calques (hmmm les groupes) et pour les formats videos mais c'etait rester a l'etat de proto (j'avait que l'aspect gui bien rode avec la base des calques) quand mon fs m'a lache (je suis alors retourne a la 3d) :(

M'enfin je veux bien contribuer :)

malheureusement non :(
d'ou "wine"
D'ailleur faudrait petitioner pour que nous aussi on ait le droit de perdre du temps a autre chose que geeker :)

Enfin c vrai qu'a part les jeux 3d sous win et les gors logiciels CAD/3D je vois pas trop comment on pourrait avoir interet a des drivers acceleres en 3d.

Faux. Question, tu utilise des disques IDE ?

non Full SCSI. ce n'est pas un prob hardware.

Pour ext3 comme...

non justement les nouveaux fs ne fonctionnement plus par hierarchie mais par une structure de graphe ou il n'y a pas de tete hierarchique a perdre.

Le truc c que si fsck marchait mieux j'aurais pu recuperer une bonne partie de mon fs ... sniff

g mieux: http://bellard.org/qemu(...)
en gros c'est un JIT x86 portable qui marche pas trop mal (tip: il utilise gcc), maintenant contribue :)

+1 pcque je le merite bien :)

J'ai lu quelquepart que le module pour le noyau était un gros binaire "emballé" dans un code source dont le rôle est de "coller" le module au noyau et au système (compilateur+noyau+glibc) donc les drivers Nvidia ne sont pas libres et même pas livrés sous forme de code source.

Vi c vrai, mais meme comme ca il y a suffisement de code au sujet de la gestion AGP pour que ca aide. Bon a part le projet agpgart peu on du chercher a comprendre mais c'est tjs interressant de voir comment des pros du domaine depuis tres longtemps gerent cela.

Par contre Nvidia est le _SEUL_ fabricant de GPU qui porte ses drivers sous Linux et c'est pour ça que j'ai acheté une Nvidia.

hmm, je crois qu'ATI suit aussi le mouvement, s3 fournit les specs.
Sinon la majorite des tres grosses cartes graphiques haut de gamme ont des driver livres avec pour tous les unix (dont linux)

Certes, certes ... Mais tu es donc toujours incapable de me démontrer que le simple fait de fournir les specs donne la possibilité à un concurrent de recopier la puce.

desole, je l'ait dit plus loin, mais pas en reponse a ton commentaire.
En clair tu est pas capable de faire un CPU a partir des spec et encore moins un GPU (car plus complexe que les CPU)

...l'ouverture du code des pilotes sont complètement cons.

La, je suis pas d'accord cf mes autres commentaires.
Mais c clair que je suis partisans de l'ouverture, meme partielle, de ceux-ci. Malheureusement je me fait peu d'illusions, a moins que tous les fabriquants de cg deviennent les meilleurs amis du monde et promettront d'arreter le coup bas (on peut tjs rever).