Oscar Blumberg a écrit 46 commentaires

Ca, je trouve que c'est le truc le plus mesquin que MS ait fait. Encore faire passer OpenGL par DirectX (et virer WGL) c'est déjà pas terrible, mais ca ...
Bon le workaround ca serait de faire du reverse engineering pour faire marcher le linker gcc sous windows pour avoir le même résultat que le linker m$.
Le pire c'est que c'est peut être que le début.
Imaginez que ca en arrive a un point ou la team gcc soit obligée d'analyser les binaires windows pour voir que l'octet d'offset 3F doit être a 4A pour que le programme puisse accéder au système de fichier...

Nimporte quoi

Vista evidemment.
Toujours est il que c'est a regarder absolument, un grand moment de rigolade.

Aucun style, aucune finesse

Posté par kolter (page perso, envoyer un message privé) le vendredi 09 février à 21:03

Zune ?

Monstre ? comme gconf ?

* Gère très bien Unicode (charset ISO-8859-XX, UTF-8, UTF-16), convertit les chaînes dans le charset de votre terminal

Veillez a ne pas laisser traîner votre hachoir sur irc, plus particulièrement sur #linuxfr, l'auteur n'est en rien responsable des conséquences de ceci.

=> []

DBus succedera a KPart ?
Heuuu, DCOP plutot non ?

Ne pas oublier de prendre en compte l'annonce du concours qui *pourrait* être intéressante pour certains ?

Moi je la verrais bien cette news, rien que pour ca.

Bhale Bacce ?
Le même que http://onsfoudkilao.com/ ?

J'étais au concert a l'abracadabar, a Paris, l'année dernière, trop de la boulette Bhale Bacce :)

Quelques mois ... haha ...

voir http://lists.kde.org/?l=kwin&m=115999369611542&w=2
et la réponse : http://lists.kde.org/?l=kwin&m=115999647204760&w=2

Eike Hein (le maintainer de konversation) dit qu'emerald (le window manager de beryl) n'a pas autant de fonctionnalitées que kwin : les implementer dans emerald serait plus long que d'ajouter le support du kompositing à kwin. De plus emerald est très jeune comparé a kwin.

Puis bon, vous preferez pas avoir un joli kcm que le compiz/beryl-setting-manager ?
De plus, c'est peut être débile mais pour quelquechose comme le window manager je préfère avoir un truc 100% kde, ça n'engage que moi...

1 le benshmarker est ouvertement pro-kde

Lubos Lunak étant le maintainer de KWin, l'inverse m'aurait parut étonnant...

> Abstraction faites de toutes les considérations techniques (gstreamer est une bouse etc ...)

Très constructif, passons.

Le "gstreamer est une bouse" c'est une citation et ne reflète pas du tout mon opinion, j'ai jamais vu le code de gstreamer, jamais vu la gueule de l'API, j'en sais rien, je me tais.

J'ai critiqué le fait que KDE fait une couche qui n'aura que le plus petit dénominateur commun (et ça n'apporte rien au libre). Et si ce n'est pas le cas, ça sera limite ingérable (d'ailleurs, ça commence). Tu parles de stabilité d'API/ABI, mais ce qui va arriver c'est que dans KDE il y aura des applis qui utilisent phonon, d'autres qui utilisent Gstreamer, d'autres Xine, d'autres ...
C'est se tirer une balle dans le pied. Si phonon est beaucoup utilisée, les programmes n'offriront que peu de fonctionnalités. Ce n'est pas avec ça qu'on va concurrencer Windows Media Player surtout si rien ne bouge pour les 3 ans à venir.

Ben, c'est dit partout, phonon *doit* être simple. Il devra niveler par le bas les fonctionnalitées des backends, ok. Les applications ayant besoin d'une manipulation fine utiliseront un framework particulier, pourquoi pas gstreamer ? En tout cas c'est comme ça que j'ai compris le schmilblik.

En gros, il faut que ça leur tombe tout cuit dans le bec sinon c'est de la merde. Pas de compromis. Franchement, pour qui il se prend ?

Je vois pas en quoi son attitude est blessante pour les développeurs gst : il faut une solution qui se conforme au points qu'il a écrit, ça veut pas dire que kde contribuera pas a gstreamer.
A mon avis (pures spéculations), les développeurs des différents backends coderont sur le moteur multimédia qu'ils ont wrappé (correction de bugs, etc).

PS : aseigo n'est pas représentatif des développeurs de KDE, les développeurs de KDE sont milles fois plus respecteux que les fans de KDE.

Pure généralisation. Un troll est un troll, tu peux pas dire que les trolleurs KDE "ilstrollentplus" et qu'en plus "ilssontmoinsrespectueux" que les autres ...
En plus, comme je l'ai dit plus haut, je vois pas de problèmes avec ce qu'a dit Aaron.

En parlant de troll, sans vouloir sombrer dedans, faire un projet qui a pour but d'être commun a plusieurs desktop (je parle de gstreamer la ;)) et l'écrire avec la glib, c'est comme si kde sortait un fw audio avec QtCore, tout le monde gueulerait.

Abstraction faites de toutes les considérations techniques (gstreamer est une bouse etc ...), pour moi c'est une question de bon sens :
Sachant que l'API multimédia sera figée au début de KDE4, et que les backends sont trop instables, API/ABI parlant, le plus logique c'est pas de faire une couche d'abstraction ?
Ça apporte aussi l'avantage d'exposer a l'application une API consistante avec le reste des kdelibs.

Rien que ça, ça me parait être une très bonne raison de coder Phonon.

Oui

kde-devel@cerise:~/qt-copy$ solidhardwarebrowser 2> /dev/null&
[2] 7748
kde-devel@cerise:~/qt-copy$ dbus org.kde.solidhardwarebrowser_7748 /solidhardwarebrowser/solidhardwarebrowser com.trolltech.Qt.QWidget.setWindowTitle "blah"
kde-devel@cerise:~/qt-copy$

C'est un peu plus verbeux menfin. L'utilitaire dbus (analogue a dcop) est fournit avec Qt 4.2 TP me semble.

... et ils n'auraient pas du.
Je suis kde-core-devel (k-c-d pour les intimes) depuis pas mal de temps et l'idée de publier un snapshot de KDE4 était en discussion. Personnellement j'étais contre.
Ce snapshot va forcement attirer une foule d'utilisateurs voulant essayer la version 4 de kde en s'imaginant retrouver les mockups qu'ils ont vu sur le net etc. Ils vont repartir déçus (KDE4 cédlamerde).
Pour l'instant ya *rien* qui marche, ça crash tout le temps et en plus c'est moche. Le seul intérêt de ce snapshot c'est pour les développeurs d'applications KDE qui veulent commencer à porter vers KDE4, car tous les changements sont en profondeur (DBus, CMake, etc ...).

Appeler ça snapshot et mettre une grosse news sur kde.org, c'est courir le gros risque de se taper une masse d'end-user pas content.

La 0.7.2 est également dans fnux ...

=====> []

ThePingouin c'est pas tux non plus.
Camomille c'est parceque ... heuuu
Parceque .... c'est bon pour la santé :p
Et que tux aime bien la camomille ...

Moi aussi chuis compatible

bah oui, mais je ne parle pas de stocker les informations du compte ou du mot de apsse juste les infos nescessaires pour se connecter au serveur mail (commes les hotes, les methodes de securité supportées ...)

C'est très bien qu'un soft comme ça existe linux (et sous KDE en plus :p)

Moi qui l'avais mauvaise quand notre guitariste m'envoyait des fichiers guitarpro :/

Je le teste dès que je peux :)

(Sauf s'il est horrible à packager mais bon par exemple ogre ca va :p)

Ogre a été horrible a packager (je parle en connaissance de cause, je suis le maintainer :p)
Mais sinon, oui, tu veux ton paquet, tu viens sur irc, tu trouve un paquageur disponible et il te le boucle en peu de temps : C'est l'avantage d'une petite distribution.

(au passage petite pub : http://www.fnux.org(...) : rejoingnez nous :) )