Pinaraf a écrit 3674 commentaires

Oui ça avance, bientôt les modifs mineures nécessaires à X.org pour qu'il puisse lancer Looking Glass devraient être acceptées. Pour l'instant on a besoin d'utiliser un serveur X.org patché fourni par Looking Glass, donc ça veut dire qu'après on pourrait avoir Looking Glass au même titre que KDE ou gnome dans kdm/gdm alors que c'est actuellement un peu chiant...

Pour ma part, j'aurais jamais pu autant participer à LG3D sans le SoC, donc forcément je pense pas qu'on puisse dire que c'était du mercenariat :)

Pour info, t'es pas le seul étudiant à avoir continué les contributions au projet après le summer of code.
C'est mon cas avec Looking Glass, mais plusieurs autres étudiants qui continuent à contribuer même après le summer of code... Notamment ceux qui ont contribué à wine (si je me souviens bien des newsletters de wine)

Les ntfstools permettent ceci, sans dll de windows.
Cette méthode est valable depuis plusieurs mois.

Et si tu fais la commande suivante :
netstat -apn | grep "tcp"
Qu'est-ce-que tu obtiens comme processus ?

Ça sert à rien de voter, les devs de kopete bossent déjà dessus !
Va sur IRC : #kde-fr (@freenode), c'est en passe de devenir #kopete-fr :)

Avec un serveur X traditionnel, tu peux très bien faire des fenêtres en 3D. Cf ma signature :)

Ça n'a rien à voir parce que la transparence est gérée dans la puce 3D pour les jeux 3D, et surtout que tout a lieu dans la même application !
Les serveurs X n'utilisant pas encore l'openGL, la transparence est gérée par XRender. Or render n'est pas accélérable avec XAA, l'architecture d'accélération "traditionnelle" de X. Les drivers nVidia savent l'accélérer car ils n'utilisent pas XAA.
EXA, la nouvelle architecture d'accélération, est capable d'accélérer Render. Les drivers n'ont que certaines fonctions à fournir.
Mais y'a pas sur la carte graphique une puce "transparence", une puce "faire des cubes", une puce "faire des sphères"... Ça serait bien trop coûteux !

Salut

J'ai un Acer Aspire 1692 wlmi, et il marche presque à 100% sous linux (kubuntu breezy ou suse 10.1 alpha 4). Presque... il faut juste télécharger une DSDT corrigée sur http://acpi.sourceforge.net afin d'avoir l'indicateur de batterie opérationnel.
L'ACPI et les DSDT pourries signées par le compilateur de microsoft sont les principaux problèmes que l'on puisse avoir avec un portable...

Y'a déjà un truc ici, si ça t'intéresse :
ftp://ftp.trolltech.com/qt/source/qtcanvas-opensource-4.1.0.(...)

Néanmoins, je cite le README :
QtCanvas is Qt 3's canvas module with a Qt 4 style API.

QtCanvas is a port to Qt 4 of Qt 3's QCanvas module. It is intended to be used in porting projects from Qt 3 to Qt 4. QtCanvas differs from the Qt3Canvas classes of the Qt3Support module in that the API has been updated to Qt 4 style. Hence, it facilitates "clean" Qt 4 ports which do not require Qt3Support.

It should be noted that this module is not recommended as the long-term choice for new Qt 4 projects, as Qt 4.2 is expected to provide a replacement for QCanvas, based on Qt 4's powerful new 2D paint system.

Regarde sur le site d'X.org, sur la page EXAStatus : y'a déjà des infos sur le support d'EXA dans le driver nv !
http://wiki.x.org/wiki/ExaStatus

Pour nvidia le problème est plus complexe.
Actuellement, ils n'utilisent pas EXA, mais ils n'utilisent pas non plus XAA !
Ils ont leur propre architecture d'accélération, qui permet déjà d'accélérer Render. Mais cette accélération est moins fiable et moins bonne que EXA. La prochaine version du driver nVidia devrait apporter une accélération bien meilleure, mais ça reste à confirmer.
De plus, EXA ne change toujours pas un problème avec Composite activé : l'OpenGL ne marche pas, sauf dans les drivers nVidia si on active la bonne option !

Faux.
Composite n'a pas à être accéléré. Un bureau avec composite activé ne rame pas. Un bureau avec un compmgr va ramer si ce compmgr utilise Render !
C'est Render qui est accéléré par EXA.

Ne te fie pas au ""benchmark"" de Rasterman.
J'ai pendant les vacances travaillé sur les performances de Looking Glass. Je souhaitais tester les performances du WM de Looking Glass par rapport à KWin par exemple. LG3D a un WM clairement plus lent que KWin.
Or le test de rasterman dit que looking glass est largement plus rapide que kwin !
En fait, le problème c'est que les WM n'ont pas d'obligation vis à vis de leur comportement. Kwin décide d'afficher *tout*, ce qui fait que lors du "benchmark" de rasterman il affiche sa centaine de fenêtres, alors que le WM de Looking Glass a pas le temps d'afficher une fenêtre qu'elle est déjà fermée !
Donc ne vous fiez pas à un benchmark que vous ne comprenez pas entièrement !

mais glxgears ne me donne pas de chiffre, l'état expérimental du driver en est probablement la cause
glxgears -printfps
Parce que les FPS de glxgears c'est pas un benchmark, donc il faut décourager les gens...

Non je ne pense pas, car lorsque j'utilise la transparence dans des jeux, soit natif sous Linux, soit utilisant Wine/Transgaming, la transparence fonctionne parfaitement.
Ça ne veut rien dire, et n'a rien à voir.
C'est comme dire que dans une page web, la transparence marche => pourquoi ne marcherait-elle pas sur des fenêtres ?

C'est déjà le cas avec KDE 3.4.
Par contre la stabilité du serveur X quand un *ompmgr tourne dépend de la qualité des drivers. Les drivers nVidia 81xx sont bien plus stables qu'avant, et ils supportent en plus l'OpenGL avec composite activé (ils ne permettent pas de faire du rendu de l'appli OpenGL "off screen", donc ça permet pas de faire des applis OpenGL transparentes)

Sinon Ubuntu breezy était déjà presque prête pour le passage à X11R7, et dapper a déjà une partie de X.org 7.0

Une chose est sûr : ça sera pas sur la 4.0.
Certains développeurs de KDE parlent d'utiliser la version 4.2 qui devrait être sortie d'ici la sortie de KDE 4, afin d'avoir un truc plus stable, plus rapide et plus complet (QCanvas...) dès l'apparition de KDE4.

Pour ma part, je préfère un truc tout con : installer un serveur ssh, et me connecter à distance dans konqueror avec fish://utilisateur@hote

T'as des bindings : python-gnome2 pour gnome-vfs (j'ai pas testé), et pykde (intégré dans kdebindings depuis KDE 3.4) avec les pykdeextensions pour simplifier la tâche : http://www.simonzone.com/software/pykdeextensions/

j'ai un peu honte d'être originaire d'un pays ou le débat public se fait à la machette, à grand coups de désinformations tant d'un coté que de l'autre.
Si tu le dis...

Va dire a la maman du petit enfant qui souffre d'un déficit d'une enzyme particulière que le plan d'OGM produisant cette enzyme a été arraché "pour le bien de l'humanité", et "avec l'aval de la justice".
Tiens... ne serait-ce pas là de la propagande utilisée par des pro-OGM ?
Ça me fait aussi penser à un certain JT de france 2, dont j'ai parlé ici : http://linuxfr.org/~PieD/19246.html

Ben tu sais dans la licence pour msn il est écrit qu'il faut être majeur pour utiliser msn, donc forcément la protection des enfants c'est pas franchement nécessaire.

Pour info, j'ai réussi à faire fonctionner looking glass sans la JVM de Sun : la JVM 5.0 d'IBM n'a eu aucun problème.
Ok, ça reste proprio. Mais au moins, ça prouve que Looking Glass ne dépend pas de la JVM de Sun, mais de la version 5.0 de java uniquement.
L'annonce de cette mise à jour de la JVM d'IBM sur OSNews : http://www.osnews.com/story.php?news_id=12539

Oui, il peut marcher sur AMD64, mais le serveur X fourni n'est qu'en version 586 : tu devras le recompiler aussi.
Pour le serveur X : https://lg3d-x11.dev.java.net (j'ai jamais essayé, désolé)
Pour recompiler Looking Glass, le plus simple est de télécharger le code source sur le CVS, puis de le compiler très facilement avec ant. J'ai un "script" qui fait ça tout seul : http://pinaraf.robertlan.eu.org/LG3D/re_cvs.sh

Dans quel sens doit se faire la compatibilité avec GCJ ?
La majorité des gens veulent que ça soit les applications qui s'adaptent à GCJ. J'estime que c'est dommage de le voir comme ça : il est bien plus rentable de faire évoluer GCJ que d'adapter les applis à GCJ.
Dans le cas de Looking Glass, gcjx devrait être capable de le faire tourner. Malheureusement, gcjx était prévu pour Gcc 4.1 mais a été retardé... (gcjx est un gcj avec le support d'une nouveauté de Java 5 : les generics). Les développeurs de Looking Glass ont d'autres chats à fouetter, mais des utilisateurs sont prêts à rapporter des bugs sur gcjx dès qu'il sera possible de l'utiliser (et prêt à modifier Looking Glass si certaines fonctionnalités de la JVM de sun sont utilisées)