gnumdk a écrit 7502 commentaires

>Dommage tout de même que cela passe par le retrait de code

Tu as lu trop vite ;)

La méthode simplekde passe par un retrait de code mais je pense que c'était l'objectif du developpeur.

La méthode kubuntu elle se sert des fichiers *rc pour simplifier les barres d'outils et les menus...

La seconde méthode est vraiment bien vu que l'on peut charger des profiles à la volé via une simple variable d'environnement.

http://jabber.apinc.org/

Wai, et ca a pété le serveur jabber de l'apinc :( Leur serveur de secours en plus vu que le serveur principal n'etait toujours pas remis en route (il est tombé y'a pas longtemps). J'espere que c'est rien de grave.

http://forum.jabberfr.org/viewtopic.php?pid=2424#p2424

Bref, fait chier :(

Il faut insaller le moteur de theme correspondant à ton theme?

Oui, sauf que dans le cas de debian, c'est différent, tu offres un systeme de packages à un outils qui n'en a pas.

Dans le cas de gentoo, c'est quand meme une distrib qui s'inspire des ports BSD donc c'est quand meme moins évident de voir un réel interet.

>Parce que de nombreux sites FTP n'allouent qu'un nombre de connection
>limité par adresse IP

Ou tu as vu que Konqueror faisait differement?

Si tu ouvres un fichier texte sur un ftp depuis konqueror avec kate, il y'aura deux connexion ftp distantes. C'est effectivement un gros problème actuellement et il serait bien que kio soit capable de partager ses connexions entre toutes les applis. Idem pour gnome-vfs d'ailleurs.

Tu as cru que le comportement de konqueror était de télécharger en local parce que lorsque le .desktop d'un programme contient %f ou %F, konqueror en déduit que ce dernier n'est pas capable de télécharger depuis une url distante et donc il fait une copie locale avant de passer le fichier au programme en question. Mais ce n'est pas le comportement que l'on retrouve avec la plupart des programmes Kde qui utilise kio.

Euh, la blague c'est celle de l'auteur du journal, parce que "Open Source vs. GNU, Debian Hurd - hahaha - vs. FreeBSD", c'est le nom de l'utilisateur...

Mwai, enfin Xegl il reutilise 80% du code de Xorg, c'est juste le serveur qui est différent. Il va pas faire 50Mo le serveur X.

On parle de Xgl la, un serveur X uniquement basé sur OpenGL.

Mais bon, David parle du long terme la, d'ici que Xegl soit pret, y'aura plus une carte sans processeur 3d de vivante... Et puis cela n'empechera pas d'utiliser Xorg si il te reste une vieille carte 2D.

La chose la plus importante que je note est quand meme que les prochains driver nvidia vont faire fonctionner compiz avec Xorg comme il fonctionne actuellement avec Xglx. Déjà ca va faire beaucoup de tord au projet :(

Mais j'espere que David va pas se décourager, c'est quand meme le seul à vouloir vraiment tenter une grosse évolution de X et il a peut être raison en pensant que la meilleur solution est de toute basé sur OpenGL.

Les arguments de Nvidia sont en gros: On veut pas Xgl, ca va tout casser ce qu'on a dans nos drivers, y'a pas moyen...

Il reste toujours la solution de mettre le repertoire courant à la fin de la variable PATH. Mais bon, le gars peut etre joueur et faire des scripts: lq, ld, lz et lx en esperant une fautre de frappe.

Bon, apres, faut pas avoir peur de se faire choper par l'admin...

>C'est que quand tu y vas avec Konqui il t'affiche la page Firefox.html

Mozilla/5.0 (compatible; Konqueror/3.5)

C'est ptet pour ca non?

Le seul probème, c'est que pour le moment, Etoilé, c'est Gnustep avec un theme, donc bon, j'aurais préféré voir un truc totalement différent, basé sur les libs de Gnustep. Pour le moment, vu les screenshot, je ne vois pas ce qu'il y'a de repensé...

>C'est comme quand la police tire, il faut pas oublier les actes du délinquant et les
>28 niveaux de sommation qu'il a pas entendu.

Ah oui, sympa l'exemple, effectivement, vive les flics qui se donnent le droit de tirer sur les gens tout ca parce qu'ils les ont prévenu avant ...

http://www.freedesktop.org/wiki/Xegl

Pour avoir vraiment voulut utiliser GNUSTEP en me foutant totalement de l'aspect graphique, j'ai eu beau insister, j'ai trouvé ca inutilisable.

Le systeme de menu est tout simplement insupportable. Les applications ont elle un comportement type année 80, ayant bossé 3 ans sous CDE, je peux te dire que GNUSTEP m'y fait fortement penser.

En clair, je serais vraiment etonné que ce projet dépasse un jours le stade de joujou pour geek pro Objectiv-C :)

C'est dommage pourtant, ils ont une bonne base, il leur faudrait juste quelqu'un avec une vision, pas forcement celle de copier ce que Apple a fait de cette base avec MacosX, mais au contraire, en essayant d'innover...

>les même perfs mais avec le client Xorg générique et non un client
>spécifique.

Nan, c'est serveur Xorg, les clients ce sont les applications :)
Oui, je sais, avec Xglx, c'est moins évident à differencier :)

>C'est peut etre pour ca que tu définis serveur X et client X comme ca ?

Non, c'etait juste pour apporter une précision à ca:

>c'est une architecture avec 2 grandes variantes

Ce qui n'est pas vrai, il n'y pas deux variantes de l'architecture Xgl, il y'a juste deux implémentations(l'une coté client: xglx et l'autre coté serveur xgl).
C'est tout ce que je voulais dire meme si xglx est à la fois client et serveur si j'ai bien compris.

Ben quand tu auras essayé expose ou la version compiz, tu comprendras mieux pourquoi ce n'est pas utilisable ;)

Je viens de finir la lecture du document de Nvidia. Déjà, il est interessant, sur ce point, y'a pas à dire.

Le gros probleme qui se pose à Nvidia est donc comment fournir des extension si ils n'ont plus de control sur le driver X (pas celui du kernel).

En particulier tout ce qui est TwinView et autres spécificité des cartes Nvidia. Il leur semble que Xgl ne permet pas de permettre à ce genre de fonctionnalité d'être implémtenté proprement (voir d'être implémenté tout cours).

On notera qu'il ne s'agit que de suppositions (we believe).

Ensuite, ils essayent de démontrer que tout ce qui est faisable avec Xgl est faisable avec l'architecture actuelle.

Il serait tres interessant d'avoir une réponse de David Reveman afin d'avoir d'autres arguments que ceux de Nvidia.

Il n'empeche que Novell est en mauvaise position pour imposer sa technologie si les constructeurs de cartes graphiques ne sont pas prêt à les suivre...

Tres bon résumé!

C'est toi qui aurait du faire un journal ;)

>Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le
>but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de
>driver X.... vous comprenez la connerie ?

Sur ce point, je pense que l'auteur du journal n'a pas compris que Xgl est avant tout une architecture et que Xglx est juste un moyen de tester rapidement cette architecture, mais Xglx a toujours été condamné à disparaitre. Mais Xegl et Xglx sont deux implémentation de la même architecture, l'une coté serveur, l'autre coté client.

Je pense surtout que ce qui va faire la différence entre les deux approches (traditionnel ou X sur OpenGL) va surtout être au niveau des perfs. Pour le moment, Xglx semble montrer que les perfs sont bien meilleurs qu'avec un serveur X normal (surtout que auncun driver ne supporte encore la fameuse extension et que c'est donc toujours fait en software par mesa).

Moi je pense que ce qui fait le plus peur à Nvidia avec Xegl se trouve dans l'introduction...

"to driver developers to expose vendor-specific features"

Et oui, avec Xegl, tout le monde sera logé à la meme enseigne et la différence se fera vraiment sur la qualité du matériel à executer des requetes OpenGL.

On comprend mieux ce qui les fait chier...

>Ah, ouais... C'est certainement pour ca que tu t'y retrouves pas quand il y a six
>faces alors... :D

C'est bien, tu sais lire, c'est exactement ce que je viens dire.

Mais dans le principe, ca ne reste pas plus incompréhensible que le fonctionnement à plat actuel...

>C'est sur que le cube c'est choli, ca epate la galerie, mais ca sert strictement
>a rien et ca gave au bout de 10 changement de workspace.

C'est marrant, mois c'est l'effet inverse, grace à cette animation, je me sens plus à l'aise pour changer de bureau via le clavier. De plus ca tombe bien, je n'utilise que 4 bureaux! Par contre, j'ai essayé de monter le nombre de bureaux à 6 et vu que l'on continue à voir un cube, la ca casse tout le principe et ca redevient, pour moi, incompréhensible.

Sinon, pour répondre à ploum:

>Les utilisateurs non-geeks sont à milles lieues de nos préoccupations.

Bah, alors moi c'est marrant, mais Xgl, c'est bien chez les non geeks que j'ai vu le plus de gens interessés: "et comment j'ai ca sous windows?".

>Ma mère : Et OpenOffice sera moins lent avec tout ça ?

Ben tu peux lui répondre que oui, sur une machine ou X avait des lagues affreux avec gtk, genre tu bouges une fenetres par dessus mozilla et tu as une belle trainée bien immonde, ben je n'ai plus du tout ce probleme avec Xgl.

Le seul probleme actuel de Xgl, c'est que si le cpu est trop occupé, ca rame (probleme des applis openGL). Il y'a bien l'option sync to vblank dans les drivers nvidia mais elles ne fonctionne pas sur ce pc, je ne sais pas pourquoi.

Mais reste que Xgl, c'est juste une démo de l'architecture Xgl, l'avenir c'est Xegl et le plus important, c'est les meilleurs perf que cela va donner par rapport à un serveur X classique. Parce que actuellement, je ne compte plus les personnes qui se plaignent des trainés laissées par les fenetres lors de leur déplacement , probleme inexistant avec Xgl.

http://www.kde-apps.org/content/show.php?content=12570

Je répond mais vraiment plein le cul des boulets pas capable de lancer une recherche sur google et qui passent leur temps à pourir les forums :(

>L'utilisation d'une vieille version de Mozilla est pitoyable, l'affichage est laid
>et lent (c'est du gtk1).

Bah, déjà, je ne porte pas trop de crédit à ce genre de phrases... Gtk 1 laid je veux bien, mais plus lent que gtk2, ah ah, la bonne blague...