lezardbreton a écrit 2632 commentaires

KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer

Pas uniquement, KDE a compris que les gens qui développent les applications graphiques ne sont pas les mêmes que les gens qui développent des frameworks multimedia. C'est l'esprit une tache - une appli appliquée aux développeurs. Un développeur de navigateur web n'a pas forcément les connaissances, les compétences et l'envie pour participer au développement d'un framework multimedia. KDE participe tout de même aux projets qu'ils utilisent dans la mesure de leur moyen. Cmake a par exemple été beaucoup amélioré pour supporter KDE, et ça s'est fait en collaboration avec les devs KDE.

Sinon, au niveau des appuis commerciaux de KDE, il ne faut pas oublier Mandriva et SUSE.

<off-topic>je m'étais promis de ne pas répondre tellement ce débat est consternant, c'est raté</off-topic>

Peut-être y-a-t-il si peu d'applications KDE utilisant des bindings uniquement parce que :
- les devs KDE sont à l'aise avec le C++ parce que les libs sont bien faites et la documentation complète
- ne comprennent pas l'intérêt des bindings par rapport au C++
- ne veulent pas rajouter 100 machines virtuelles différentes pour faire tourner une appli basique parce qu'ils se préoccupent de la consommation mémoire de leurs utilisateurs
- trouvent qu'il est très intelligent de tout faire en C++, car justement tous les devs KDE auront une base commune de langage
- trouvent que les langages autres ne sont pas aussi performants

Bref, tu peux trouver des dizaines de raisons pour ne pas utiliser les bindings autre que "les bindings ne sont pas complets". En l'occurence, tu apprendras par exemple que PyQT et PyKDE sont complets et générés automatiquement et je t'invite à lire l'interview de leur auteur : http://dot.kde.org/1155075248/

Franchement, ras-le-bol de ces gens qui passent leur temps à critiquer sur des conneries.
Aaron Seigo a déja répondu à ces critiques complètement débiles de supporters de leur joujou préféré : http://aseigo.blogspot.com/2006/05/id-like-another-black-eye(...)

1. Aujourd'hui, Gstreamer est une grosse bouse infame. Je n'ai jamais vu un backend aussi mauvais. Peut-être que dans la théorie, c'est beau, en pratique, c'est nul. Compare Amarok avec Gstreamer ou avec Xine, tu verras la différence. Pire, compare totem-gstreamer avec totem-xine, et on peut voir lequel des deux marchent correctement.

2. Les devs de Gstreamer prennent des décisions stupides, dans la tradition GNOME, comme des changements brusques d'API (qui ont provoqué beaucoup d'incompatibilité) sans discussion prélable comme entre la version 0.8 et la 0.10.

3. Il n'est pas question d'utiliser Phonon pour les applis ayant des besoins spécifiques, mais uniquement pour les applications classiques qui ont toutes plus ou moins les mêmes besoins basiques et pour lesquels ça ne sert à rien d'utiliser un backend particulier.

4. On a bon dos de critiquer KDE pour ne pas utiliser des technologies GNOME alors que KDE vient justement de prendre dbus alors que dcop était parfaitement fonctionnel depuis des années et était là avant dbus. Pourquoi GNOME n'a-t-il pas utilisé dcop ? A mon avis, c'était déja une connerie pour KDE d'utiliser dbus.

5. Prendre Phonon, c'est au contraire laisser la porte ouverte à Gstreamer dans un but d'ouverture, sinon xine aurait évidemment été la meilleure solution.

6. Comme d'habitude, les développeurs GNOME ont tendance à ne penser à l'utilisation des bibliothèques qu'ils utilisent uniquement dans un contexte GNOME. Par exemple GTK+ qui va encore grossir pour recueillir les bibliothèques GNOME (que personne n'a sohaité maintenir malgré leur utilisation dans de nombreuses applications) au sein du projet Ridley. Merci pour les devs XFCE !

Bref, foutez la paix au kdeistes s'il vous plait.

Tu as visiblement tout compris :)
En tout cas, merci de l'info, et vive Kolab !

Pas faux, en même temps, il existe des gens comme toi pour le repréciser. C'est aussi pour montrer que ça avance aux extérieurs comme moi qui se demandent un peu ce qui se passe. L'appeler krash est aussi là pour montrer que oui : c'est une version de dev, très loin d'être finalisée. Enfin bon, si ça peut attirer des développeurs en herbe, c'est toujours bien.

Sauf que :
- dans le journal aucune indication comme quoi ce ne sont pas des dépots officiels
- tout le monde ne connait pas Ubuntu et ses différents dépôts

Si ça n'a rien à voir avec Ubuntu officiel, effectivement, ce n'est pas la faute d'Ubuntu, mais je me demande dans ce cas-là pourquoi on en parle, ça doit affecter un nombre d'utilisateurs plutôt minimes, non ?

Un soucis de paquetage, et ce n'est pas la faute du packager ?
C'est quand même étonnant de tout pardonner ainsi lorsqu'il s'agit d'Ubuntu...

Celle-là je pense : https://addons.mozilla.org/firefox/2390/ (VideoDownloader)
Mais bon, ça marche que avec Firefox.

Il existe aussi des filières expertise en France. Dans les boites de conseil, tu as souvent des dénominations "experts" qui signifient quelque chose. Dans ma boite, sur 500 consultants, tu as 2 experts dans un domaine particulier et c'est un poste à part au niveau hierarchique (cad leur seul responsable est le PDG). Sur le fond, je suis entièrement d'accord avec toi : les experts ne sont pas assez reconnus en France.

Franchement, avec 1Go de RAM, si ça parait lourd, c'est qu'il y a un problème quelque part.

En fait, tout n'est pas rose chez Apple, loin de là. Si tu lis les commentaires de Osnews, de Digg, ou encore de Slashdot, les opinions sont en train de changer depuis deux-trois mois. En tout cas, les mécontents de Apple ont reçu une médiatisation très importantes ces derniers temps. Entre les personnes qui passe sous GNU/Linux et qui se croit assez important pour en faire part à tout le monde et certaines annonces désastreuses pour l'image comme cette étude sur la qualité des Power Mac G5 aux conclusions alarmantes : http://www.macintouch.com/reliability/pmg5.html , j'ai senti un retournement d'opinion qui ne se traduit pas encore dans les chiffres sur les ventes bien sûr.

Personnellement, je pense que faire la même interface pour tous les OS est une erreur de conception. Une interface qui s'intègre à Windows n'est pas la même qu'une interface pour KDE. L'exemple parfait est Firefox, avec son interface d'ouverture des exécutables qui oblige à passer par /usr/bin. Bon, ça, c'est la théorie. Comme vous pouvez voir sur les screenshots, l'interface de Swift n'est pas vraiment windosienne. Je suis persuadé que konqueror sous Windows ne sera pas une réussite d'intégration, au moins au début.
Enfin bon, plus il y a de monde sous KHTML, meilleur c'est !

Sur le temps d'affichage, c'est très rapide. C'est presque comparable à Opera. Mais c'est vrai que ça crashe pas mal, un peu normal pour une alpha en même temps.

En quoi réinventent-ils la roue ? Au contraire, ils reprennent un moteur de rendu déja existant.

Le moteur de rendu est mature, le navigateur est en version alpha.

Vivi, Lego revient vers le libre : https://linuxfr.org/~lezardbreton/21533.html
http://mindstorms.lego.com/press/2057/Open%20Source%20Announ(...)

Tu te fous de moi, c'est ça ?
Tu pars d'un mail de janvier 2005 pour parler de klipper, je te réponds qu'aucun (zero bug) n'est présent dans le bugzilla à propos de son démarrage avec KDE. Je te dis aussi qu'à la fois sur Mandriva 2006 et sur Cooker, ça marche sans intervention de ma part.
Ensuite, tu me parles de kfmclient, je t'explique que c'était dû au changement de gestion des menus (en gros, ça sera beaucoup moins patché et standard). Ce genre de bug n'existera plus la transition effectuée. Au contraire, Mandriva travaille pour que ça ne revienne plus, c'est un très mauvais exemple.
Enfin, tu parles de KDM avec un mail du 14 Septembre 2004, je ne comprends même pas pourquoi je devrais répondre à ça.

Que la distribution de développement de Mandriva soit instable, c'est un peu son rôle. Faire des transitions, parfois douloureuses, c'est normal.

Mes deux distributions sont Mandriva et Debian Testing, chacunes ont leurs bugs, et les deux ont très peu de bugs sous KDE. Ce n'est pas comme la malheureuse Kubuntu... Ce n'est pas parce qu'une distribution est française qu'il faut s'acharner dessus !

Et les fenêtres konqueror qui se crashent régulièrement (pouf ! fermée !) ?
Je ne vois pas de quoi tu parles. Ca crashe autant qu'ailleurs (c'est à dire que je ne me rappelle plus de la dernière fois que c'est arrivé).

Et les raccourcis kfmclient qui une mise à jour sur deux ne fonctionnent plus ? (pourtant, la commande « konqueror », elle, fonctionne)
C'est dû au système de menu Debian qu'avait pris Mandriva. Ca tombe bien, ça n'existera plus avec la 2007.

Et Klipper qui ne reste pas lancé (et qui d'ailleurs ne veut même pas s'intégrer dans la boîte à miniatures) ?
Chez moi ça marche !

Mandriva n'est pas la panacée, mais dire qu'elle est plus instable qu'une autre, c'est de la profonde mauvaise foi.

Il faut rajouter que /usr/share/config/kdm/kdmrc a été vidé de toute substance intéressante en même temps. Un genkdmconf plus tard et ça repart.

il était encore dans mon cache. Il n'existe effectivement plus.

Enfin bon, la rapidité ne faisant pas la qualité, il ne vaut mieux pas les installer : http://kubuntu.org/packages/kde-354/README
These packages contain a bug which stops /etc/kderc and therefor the kubuntu-default-settings files from being used.

We do not know the cause of this bug but we currently do not advise upgrading to these packages.

Jonathan Riddell 2006-08-01

Heu, comment dire, je suis un gros nul en paquetage rpm et je me suis lancé pour débuter. J'ai suivi le RPM HowTo en français de Mandriva : http://qa.mandriva.com/twiki/bin/view/Main/RpmHowToFr . Je voulais faire le paquet kde-style-klearlook, alors j'ai piqué le srpm d'un autre thème KDE dans Mandriva et adapté grossièrement le fichier spec pour klearlook.

Une fois ce fichier spec fait, un rpmbuild -ba kde-style-klearlook.spec plus tard, tu as ton fichier rpm conçu dans ton répertoire ~/rpm/RPMS/. rpmlint te permet de repérer les erreurs de construction de ton rpm (chez moi, il manquait un champ).

Quand j'ai cru que mon rpm était à peu près correct, j'ai demandé conseil à misc sur IRC, et j'ai viré mon champ depends qui n'avait aucun intérêt, vu que rpmbuild analyse automatiquement les dépendances.

En suivant les instructions trouvées sur http://qa.mandriva.com/twiki/bin/view/Main/ContributorHowtoF(...) , je l'ai uploadé sur le FTP de Mandriva et posté un message sur la ML pour le proposer.

Comme misc m'avait prévenu, mon paquet n'a pour le moment intéressé personne (les devs sont un peu trop pris par la préparation de Mandriva 2007), et il est donc toujours sur le FTP en attente de validation. Il est aussi ici : http://lezardbreton.free.fr/mandriva/

Mon conseil du jour : prendre un paquet pas compliqué (un style KDE est très adapté), reprendre un paquet existant similaire et l'adapter, et enfin, lire la doc Mandriva, qui n'est pas mal du tout et en français.

Donc une appli pas réactive, ça ne te dérange pas ? Je ne comprends pas ce que tu veux dire, ce n'est pas parce qu'une application passe la plupart du temps en fond d'écran que tu n'as pas besoin de vitesse pure au moment où tu l'utilises.

Et t'as mis quoi à la place ? T'as une autre solution moins buggué/moins consommatrice de ressources ?
Strigi : http://www.vandenoever.info/software/strigi/
http://strigi.sourceforge.net/index.php/Main_Page
Je l'ai testé, ça marche très bien (pas de bugs apparents), l'interface est sûrement à retravailler, et la taille de l'index est important. Utilisation du CPU<1%, consommation mémoire <10Mo (impressionnant, je n'ai rien senti).
Par contre, je n'en ai toujours pas l'utilisation

Kio-lucene : http://kioclucene.objectis.net/ , pas testé mais j'en ai entendu du bien.

J'ai trouvé les traces du début des annonces de Beagle pour la sortie de Mono 1.0, le 30 juin 2004. Ca veut dire qu'en plus de deux ans de dévelopement sur l'application emblême de Mono avec ces outils soit-disant si performants on n'en soit que là ? Tu n'as pas l'impression qu'il y a comme un problème ?