Pinaraf a écrit 3682 commentaires

Je pense que seules les cartes graphiques ATI peuvent te suffire.
Par contre, aucun pilote autre que les pilotes propriétaires de nVidia ne permet d'accélérer l'OpenGL avec Composite activé.

Donc pour les cartes graphiques ATI, toutes les radeon <= 9200 sont supportées pleinement par le pilote libre, avec en bonus un support complet d'EXA dans X.org 6.9/7.0 (c'est-à-dire Render accéléré, soit Composite utilisable avec les *ompmgr actuels...).
Les ATI radeon > 9200 ont un pilote libre en cours de développement, qui ne supporte malheureusement pas pour la 3D toutes les cartes (ma radeon X700 n'est pas supportée pour la 3D par exemple). Néanmoins ce pilote s'améliore continuellement, et je pense que d'ici 1 an il marchera parfaitement.
Par contre, toutes les cartes graphiques nVidia ont des pilotes propriétaires uniquement, le pilote libre étant quasiment fermé d'après certains (il fait de la magie sur des registres de la carte sans explication). D'ailleurs, il faut noter la man½uvre tactique de nVidia qui consiste à ne plus supporter les Geforce < 3 et les TNT dans les derniers pilotes propriétaires (probablement afin de forcer un renouvellement du parc)

Sinon y'a la "méthode" utilisée en XSLT. En XSLT y'a un if mais pas de else. Donc une solution :
<xsl:choose>
<xsl:when test="condition1">
Cas 1
</xsl:when>
<xsl:when test="condition2">
Cas 2
</xsl:when>
<xsl:otherwise>
Sinon
</xsl:otherwise>
</xsl:choose>

J'ai du coder ce week end une application web avec mod_python, et j'ai trouvé ça vraiment agréable à utiliser, simple et rapide.
Je me demande pourquoi personne n'en parle. L'écriture de templates est très simple avec PSP (Python Server Page).

Bof, le dossier .kde me semble assez bien rangé encore.
.kde/
- Autostart/ : des liens/fichiers .desktop/scripts/exécutables qui seront lancés au lancement de KDE
- cache-*/, tmp-*/ et socket-*/ : des dossiers pour les cache, fichiers temporaires et socket
- share/
- - applnk/ : contient des liens qui sont ajoutés au menu K et propres à l'utilisateur
- - apps/ : contient les fichiers des applications qui ne sont pas liés à la configuration. Exemple : les journaux de discussion sur IRC/Jabber, la base de données d'amaroK...
- - config/ : contient les fichiers de configuration des applications, au format "ini". Certaines applications utilisent plusieurs fichiers car elles sont séparées en plusieurs "composants" (exemple : kdevelop).
- - locale/ : je sais pas là...il est vide ce dossier
- - mimelnk/ : les associations de fichiers que l'utilisateur a modifié
- - services/ : les services propres à l'utilisateur. Exemple : des mots clés de recherche personnalisés (alt+f2 => "gg:test" recherche test sur google. On peut facilement ajouter d'autres mots clés que google)
- - servicetypes/ : contient des composants, actions de konqueror.. propres à un utilisateur

Bref, .kde est très rangé.
Et le système de configuration de KDE, KConfig, ne permet pas de cacher des entrées. KConfigEditor est ton ami pour l'édition des options d'ailleurs : http://extragear.kde.org/apps/kconfigeditor/
Au passage : kconfigeditor supporte aussi gconf

1- Ce n'est pas une base de registre immonde qui contient des informations sur tout le système. Ça ne concerne que des applications, les fichiers de config de X par exemple restant hors de ce machin
2- C'est bien plus évolué que la base de registre. Le système de transaction est proche d'une base de données par exemple.
3- Il existe un éditeur en mode texte pour cette base.
4- Il s'agit toujours de KConfig. On a donc toujours une description des différentes clés et valeurs possibles pour ces clés.
5- Comme tu l'as dis, il sera possible de choisir entre un stockage dans un classique fichier "ini" et cette base de données. Il faut tout de même noter que les performances des fichiers .ini sont catastrophiques par rapport à cette base.
6- Cette base sera utilisée par samba4. C'est d'ailleurs les développeurs de samba qui l'ont crée. Donc les performances sont (seront) très bonnes, et cela devra obligatoirement être stable et fiable vu l'envergure du projet Samba4 et la dépendance à cette base pour certains fonctionnalités

Moi j'ai eu un clavier PS2 qui a cramé, en emportant apparemment le port avec.
Résultat j'ai du m'acheter un clavier USB, qui merdoyait pas mal sur tout sauf DOS. J'ai alors flashé le BIOS, et en rebootant, le port PS2 remarchait ...

Pour plus d'info sur les puces SiS/XGI voir http://www.winischhofer.at/linuxsispart1.shtml . En gros si c'est une puce SiS34x ça devrait marcher, pour les autres nada.
Donc il est nada :p (une SiS315 je crois)
Sous Windows le top du top de chez XGI se fait torpiller par l'entrée de gamme de NVidia/ATI et sur les puces intégrées c'est pire.
Et en plus il a le pire !

Comment peuvent-ils vendre ça ? C'est si bon marché ?

Sis ?
Je passe sur le fait que ça soit pourri tout ça, mais y'a un pote qui a des problèmes : sa carte sis n'est pas supportée en 3D, même par un driver proprio ? Ce driver là pourrait marcher ?

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