Pour le moteur multimédia, il est maintenant sûr que Arts sera abandonné. Pour le remplacer, Gstreamer et NMM sont les mieux placés avec un léger avantage pour Gstreamer. Kdemm, une couche d'abstraction, est en cours de développement afin de permettre l'utilisation de plusieurs moteurs.
Du point de vu des applications, c'est très flou, Noatun ne rencontre pas le succès attendu, amaroK et Juk sont très populaires ainsi que kaffeine pour la vidéo. Il sera difficile de faire un choix.
Scott Wheeler dans cet interview donne son point de vue qui permet de nous éclairer sur tout cela. Nous apprenons dans cet interview que Arts sera abandonné pour des raisons techniques (latence trop grande) mais surtout car son créateur ne s'occupe plus du projet, que très peu de développeurs sont capables de le faire évoluer et aucun n'a une vision globale du projet lui permettant de le maintenir.
Devant cet échec, l'équipe KDE est prudente. Afin d'avoir le temps de tester les différents projets existants (Gstreamer, NMM, Helix, ...), une couche d'abstraction a été écrite : Kdemm. Cela permettra de voir les différents moteurs multimedia évoluer et de choisir le meilleur plus tard.
Pour les applications, c'est aussi très flou. Juk et amaroK sont deux applications phares sous KDE mais il sera difficile de faire un choix. Comme on a pu le lire sur KdeNews, les utilisateurs sont partagés. Certains sont conquis par toutes les fonctionnalités d'amaroK, d'autres préfèrent la simplicité de Juk. Ce dernier a l'avantage d'être déjà présent dans la distribution de base de KDE, la question est donc plus : doit-on sortir amaroK de kdeextragear (les applications KDE non-distribuées avec KDE) ?
http://developer.kde.org/~wheeler/juk.html
http://amarok.kde.org (non disponible actuellement)
Pour la vidéo, le choix devrait se faire entre Kaffeine et Kmplayer (qui porte bien mal son nom).
http://kaffeine.sourceforge.net/
http://extragear.kde.org/apps/kmplayer.php
# 2-3 liens en plus
Posté par Sebastien . Évalué à 10.
NMM : http://cvs-digest.org/index.php?issue=oct12004(...)
MAS : http://cvs-digest.org/index.php?issue=sep242004(...)
GStreamer : http://cvs-digest.org/index.php?issue=oct152004(...)
Bonne lecture.
PS: et puis peut-etre ca aussi :
https://linuxfr.org/~bins/15448.html(...)
# Kmplayer
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Ca m'a l'air bien sympa !
Haypo
[^] # Re: Kmplayer
Posté par oliv . Évalué à -1.
Quelle remarque? Tu veux dire la phrase 'qui porte bien mal son nom' ? Je trouve en effet que pour un player multimedia de kde, Kmplayer est un nom plutôt judicieux, surtout comparé à kaffeine (qui ressemble plus à un gestionnaire de machine à café ;) ).
À l'origine, Kmplayer était une interface KDE pour Mplayer, mais il semble depuis qu'il se soit diversifié (Xine, etc.). C'est peut être ce point que souligne la remarque.... juste une supposition.
PS: aurais-tu mis le doigt sur un bug de templeet concernant les phrases entre guillemets? faisons un essai:
"Je vois dans se produire dans l'avenir proche une crise qui me perturbe et me fait trembler pour la sécurité de mon pays. Comme résultat de la guerre, de grandes entreprises ont été intronisées et une ère de corruption du pouvoir s'en suivra, et le pouvoir financier du pays s'efforcera de prolonger son règne en travaillant contre le peuple jusqu'à ce que toute la richesse soit concentrée dans les mains de quelques-uns et que la République soit détruite. Abraham Lincoln."
[^] # Re: Kmplayer
Posté par gnumdk (site web personnel) . Évalué à 5.
Je n'ai découvert que hier que kmplayer pouvait utiliser xine alors que je connais l'existence de ce soft depuis un moment, d'ou ma remarque.
# RIP arts
Posté par imr . Évalué à 5.
J'aimais bien par exemple en réseau pour avoir des terminaux qui "font" du son. Ca permettait d'avoir des applis même non kde sans support arts interne qui l'utilisent facilement à travers le réseau en faisant 'artsdsp appli'.
Plus simple à mettre en oeuvre je n'ai trouvé que nas mais il réclame que l'appli le supporte en interne. Ca c'était bien avec arts.
J'imagine que le problème c'est qu'il n'a jamais atteint une masse critique de développeurs. C'est dommage, c'est pas mal de temps perdu, parce que ce que pas de projets récents cherchent à atteindre il le faisait déja.
Quant à noatun, créve!
Je l'ai utilisé avec vraiment beaucoup de bonne volonté et il n'a jamais fonctionné correctement.
Un exemple frappant, c'est que dans l'exemple au dessus d'un terminal réseau j'ai gagné du temps à utiliser xmms à travers artsdsp plutot que noatun toute seul parce qu'il n'a jamais réussi à comprendre ce que toutes les autres applis kde comprenaient, à savoir que le serveur de son était "ailleurs" et il lançait de lui même un artsd ou se plantait. Le comble!
Alors si son auteur le trouve achevé, c'est qu'il y a eu un miracle depuis que je ne l'ai plus utilisé, c-a-d depuis amarok.
[^] # Re: RIP arts
Posté par spongurex . Évalué à 3.
C'est là que l'on peut voir l'avantage à utiliser Gstreamer. Gstreamer est déjà une couche d'abstraction. Il peut s'interfacer avec Alsa, OSS, ESD, Arts et plein d'autre. Donc pourquoi ne pas coder un plugin NAS pour Gstreamer.
Je ne connais pas NMM donc je ne m'avancerais pas à faire une pseudo comparaison qui finirai surement en troll ;-)
[^] # Re: RIP arts
Posté par Ludovic Gasc . Évalué à 3.
à quand une normalisation d'un protocole de son indépendant du serveur de son, comme peut l'être le protocole X vis à vis de xfree/x.org ?
Pourquoi pas une extension du protocole X qui gèrerait le son ? il me semble que MAS ou NMM peut s'interfacer avec un serveur X.
[^] # Re: RIP arts
Posté par ptitatou . Évalué à 8.
Par contre sur une extension de X pour le son, la je suis radicalement contre, déjà je trouve que les players pour X ne devraient etre qu'une sur-couche graphique.
Bref, le son sous linux n'a pas besoin d'un serveur graphique, n'allons pas créer des dépendances inutiles : modularité toujours !
[^] # Re: RIP arts
Posté par Renaud Lacour . Évalué à 1.
[^] # Juk/Amarok : Faut-il vraiment choisir ?
Posté par xguardian . Évalué à 4.
Pour ma part, Juk et Amarok n'ont pas du tout la même cible.
Juk est léger et simple d'utilisation.
Amarok est plus lourd mais propose plus de fonctionnalités.
Si je devais les comparer l'un et l'autre, je ne verrais pas trop l'utilité de Juk. (Bien sur, ce n'est qu'un avis. Je ne connais ces 2 logiciels que depuis peu de temps et non sous toutes les coutures).
Juk un lecteur audio capable de gérer les musiques suivant divers critères et de créer des playlists.
Amarok fait la même chose, mais permet de compléter certaines infos sur les albums/pistes (titre de l'album, nom exacte du morceau, jacquette, paroles, ...)
Il effectue aussi des statistiques en fonctions du nombre d'écoutes, de la dernière date d'écoute, ... permet de les classés par préférences et ceux automatiquement.
Il veille sur les changements dans les répertoires que l'on lui a demandé d'essayer, ...
Bref vous l'aurez compris, je suis plutôt un défenseur d'AmaroK, et je ne vois pas pourquoi il n'aurait pas sa place parmis les paquetages de KDE. D'un autre coté, je ne vois pas pourquoi non plus, ceux dont les capacités de Juk suffisent, devraient voir leur programme retirés de la liste par défault de KDE.
Mais ceux qui m'embêtes le plus dans KDE en général, c'est que justement dans un "paquetage", on retrouve plusieurs logiciels dont parfois un seul nous suffit. Pourquoi n'aurait-on pas le choix d'installer tel ou tel logiciel seulement plutôt que le gros bloc entier ?
Je pense que la question devrait plutôt se situé dessus, ce qui laisserait à l'utilisateur final plus de liberté et de confort.
Guile, un utilisateur très régulier de KDE même s'il lui trouve quelques défault.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Romain Vinot . Évalué à 4.
KDE a toujours fourni les sources sous la forme de gros tarballs contenant de nombreuses applis. C'est un choix particulier qui peut se défendre (qui était même plutôt logique il ya quelques temps, qu'il est de moins en moins maintenant que de plus en plus de logiciels sont intégrés dans la version de base de KDE et que ça devient un joli bordel). Au moins, ça limite fortement les dépendances. Quand on voit ce qu'il faut faire pour installer Gnome (à la main), c'est une galère pas possible.
Maintenant, si cette façon de faire ne convient pas aux utilisateurs, c'est aux distributions de découper les gros paquets d'origine en plus petits paquets. C'est justement ce qui est en train d'arriver (au moins pour celles que je connais) : Mandrake a déjà fait le pas depuis la version 9.2, pour Gentoo il existait la variable DO_NOT_COMPILE (qui n'était pas très conviviale) et ils sont en train de passer tous leurs paquets à une nouvelle version plus divisée. j'ai cru comprendre que la question était en train de se poser chez Debian également (mais là, je suis pas sûr). Pour les autres, je ne sais pas.
Bref, la question était bonne et légitime, la réponse étant c'est en cours. :o)
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Prosper . Évalué à 4.
Sur debian ca fait bien longtemps que les paquets KDE sont divisés en plein de sous paquet ( a peu pres 1 par appli ).
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par gnumdk (site web personnel) . Évalué à 5.
Pour ca, le Kde de la debian est génial, on install que ce dont on a besoin. Je dirais meme que le Kde de la debian est plus découpé que n'importe quel gnome sur n'importe quel distrib. Ils ont poussé le vice à l'extreme, c'est un peu troublant au début: genre t'install kmail et il n'a pas de support imap/pop par defaut :) Il faut faire un apt-get install kdepim-kio-plugins, idem pour le multimedia et pour kdebase.
[^] # vive le progres ?
Posté par Philippe F (site web personnel) . Évalué à -3.
Enfin, tu es sur ? Tu appelles ca une fonctionnalite ? Donc il faut trois package (j'imagine que pgp/mime n'est pas fourni par defaut) pour installer kmail. C'est sur qu'avec ca, le linuxien debianiste se sent beaucoup plus intelligent:
<<
- t'as quoi comme distrib toi ? Moi j'ai une mandrake.
- t'as une mandrake: c'est nul! Regardes, si tu veux kmail, tu as kmail directement. Moi, sur ma debian, j'installe kmail mais je n'ai pas kmail ! Il faut aussi installer les fichiers de config, l'interface graphique, le pop3, le imap et pgp/mime. Pour konqueror, il me faut 24 package (avec tous les kpart, sachant que khtml n'est pas fourni par defaut) pour l'installer, c'est quand meme beaucoup mieux que d'installer un seul paquett.
- ben, je comprends pas ?
- tu vois pas l'interet ? C'est dingue. Ma distrib, elle est _optimisee_ . Tu vois, si je veux kmail mais sans le support de l'interface graphique, du pop3 et de l'imap, je peux. Alors que toi, tu gaches 0.005 euro d'espace sur ton disque dur [1] ! Les distribs comme mandrake, elles t'installent toujours n'importe quoi quand tu ne leurs demande rien. C'est quand meme incroyable qu'on puisse pas choisir entre kmail avec et sans pop3+imap.
- ah ouai, t'as raison. Je vais demander a Mandrake de splitter ses paquets comme debian. Mais si j'ai envie d'installer tout les logiciels de KDE, comment je fais ?
- pas de probleme. Tu connais la liste de 112 logiciels inclus dans KDE, et tu insalles a la main les 453 paquets qui servent a les faire tourner. Tu vois, linux ca assure !
- putain, c'est vraiment genial ce que tu me dis la. Quand je pense qu'avant, il me suffisait d'une dizaine de paquets pour obtenir pleins de logiciels. Comme j'etais naif.
- et attends, tu iras au devant de nouvelles decouvertes. Grace a apt-get (que RMS benisse ceux qui l'ont developpe), les 1237 paquets de dependances de tes 453 paquets sont installees automatiquement.
- putain, debian, ca assure vraiment un max !
>>
[1]: chiffre arbitraire en estimant que les options de kmail prennent 1 Mo et qu'un DD de 20 Go vaut environ 100 euro.
[^] # Re: vive le progres ?
Posté par gnumdk (site web personnel) . Évalué à 7.
Tu sais ce que c'est un méta package?
apt-get install kdepim et tu auras un kmail totalement fonctionnel.
Mais bon, tant que tu y est, autant faire un seul package Kde avec tout dedans, ca sera plus simple, nan?
Parce que moi, je trouve que y'a des trucs qui sont pas assez découpé. Genre konq-plugins ou j'aimerai bien avoir un package par plugin, ca m'eviterai de faire ca régulierement:
rm -f /usr/share/services/fsview_part.desktop
rm -f /usr/share/services/kuick_plugin.desktop
Parce que moi, avoir des menus de 12 km de long, c'est pas vraiment le genre de truc qui m'interesse...
[^] # Re: vive le progres ?
Posté par Infernal Quack (site web personnel) . Évalué à 4.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: vive le progres ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Tu as regardé le prix des DD dernièrement ? Ou tu as oublié un '0' à "200" ? :-)
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Christophe Fergeau . Évalué à 3.
Récupérer jhbuild ou garnome avant de lancer la compil, c'est pas trop compliqué hein ;) Ensuite si tu veux récupérer les trucs un pas un et les compiler à la main alors que t'as des scripts pour le faire à ta place, ou même des paquets précompilés avec ta distrib, libre à toi, mais viens pas te plaindre que c'est compliqué quand tu fais toi même le choix de te compliquer la vie.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Romain Vinot . Évalué à 1.
Je dis justement dans mon message que c'est à la distrib de distribuer chaque logiciel de la façon qui lui plaît. Que les formats par défaut des projets (gros paquet pour KDE, plein de petites libs pour Gnome) ne doivent pas nécessairement être visible pour l'utilisateur.
Donc, ton commentaire appuie le mien. C'est pas parce Gnome est livré de base avec plein de petits paquets que c'est comme ça qu'on le compile. Pareil pour KDE, c'est pas parce que c'est livré de base avec des gros paquets que c'est comme ça qu'on le compile.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Romain Vinot . Évalué à 2.
Cette remarque me fait penser à un avis de Aaron Seigo sur son Blog :
S'il existe plusieurs applications différents dans KDE pour faire plus ou moins la même chose, c'est qu'il suffit que chaque application ait au moins 1 fonctionnalité que les autres n'ont pas pour qu'il soit très difficile de supprimer cette application. La simplicité étant aussi "une fonctionnalité", il est toujours très difficile de supprimer une application des repository de KDE.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Je suis un fervent partisan de la suppression des trucs qui marchent pas (noatun, arts, ...) mais juk et amarok, puisqu'ils plaisent, autant les garder.
Pour info, kdeextragear, c'est pas la cinquieme roue du carosse, c'est des paquets KDE officiellement maintenus qui peuvent faire des release independantes de KDE. Cet ensemble de paquetage prend de plus en plus d'importantce, tout simplement parce que le nombre d'application developpee avec KDE et le nombre de developpeurs augmentent.
Comme l'a fait remarque qq'un, les utilisateurs ne sont pas les memes. Pour mes parents, je mettrai plutot juk, car ca joue de la musique. Pour mon petit frere que ecoute de la musique 24/24, amarok convient mieux.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Alex . Évalué à 2.
Perso je pense qu'on devrait proposer par défaut l'appli la plus légère, et a coté les applis avec un peu plus de features. Par contre je pense que ça poserai problème en rapport avec les interfaces dcop qui peuvent être utilisés par d'autres applis.
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Romain Vinot . Évalué à 2.
Effectivement, KDE a décidé de donner la même réponse dans les deux cas : chacun fait comme il veut. Si un dev veut développer une nouvelle fonctionnalité/nouvelle appli, libre à lui. ET on ne supprime rien d'existant.
On pourrait discuter à l'infini sur ce choix, ce que je ne ferais pas ici :)
[^] # Re: Juk/Amarok : Faut-il vraiment choisir ?
Posté par Philippe F (site web personnel) . Évalué à 4.
Sinon, la multiplication des logiciels sous linux pour faire la meme chose est un probleme de longue date. Ce qui est particulierement penible, c'est quand tu as 5 logiciels differents pour faire la meme chose, dont aucun ne marche correctement. Ce n'est pas le cas de juk / amarok donc je me rejouis de cette multiplicite qui a marche.
[^] # Re: RIP arts
Posté par Jiba (site web personnel) . Évalué à 1.
Je n'aime (ais) pas arts car il s'accaparait le son en permanence, même lorsqu'il n'était pas sollicité (contrairement à ESD par exemple, qui semble libérer le son quand il a fini de jouer).
Concrètement, lorsque l'on fait par exemple un jeu vidéo, cela signifie qu'il FAUT obligatoirement prévoir un support arts, sans quoi les utilisateurs de KDE ne pourront pas avoir de son ! Heureusement qu'OpenAL est venu me sauver la vie (il supporte entre autre arts).
[^] # Re: RIP arts
Posté par med . Évalué à 2.
[^] # Re: RIP arts
Posté par Jiba (site web personnel) . Évalué à 1.
[^] # Re: RIP arts
Posté par Al Brow . Évalué à 2.
# Function to suspend the arts daemon. return 1 if the daemon is/was suspended,# 0 otherwise
suspendArts()
{
local sleeptime=1 # seconds to sleep between retries
local num_retries=3 # max number of retries
local retry_count=0 # counter
local status="" # output of artsshell command
# do a basic test to see if the necessary programs are available
status=`artsshell status 2>/dev/null`
if [ ! $? -eq 0 ]; then
# oh well
return 0
fi
status=`artsshell status | grep "server status" | awk '{ print $3}'`
while [ "$status" != "suspended" ] && [ $retry_count -lt $num_retries ]; do
# sleep if this isn't the first try
if [ $retry_count -gt 0 ]; then
sleep $sleeptime
fi
# try a suspend
artsshell suspend 2>/dev/null
# increment count
let "retry_count += 1"
# get status again
status=`artsshell status | grep "server status" | awk '{ print $3}'`
done
# is it suspended now?
if [ $status = "suspended" ]; then
return 1
else
return 0
fi
}
il est appelé avec l'execution du jeu avec:
# try to suspend arts
suspendArts
De mon côté j'ai eu aussi des expériences difficiles avec artsd : démarrage intempestif sous environnement gnome , rarement supporté par les jeux (artsdp n'aidait pas beaucoup pour quake2 et autres jeux basé sur ce moteur : un prblçme de mmap)
En prenant de l'expérience , j'en conclus que artsd était le moteur de son le plus puissant (le suel à le battre aujourd'hui est NMM mais il n'est pas encore intégré aux ditributions). Par contre c'est le moins bien supporté par les applications non kde (rare sont les programmes à utiliiser ses fonctions de compatibilité, et artsd est en fin de compte capable de s'interfacer avec n'importe quoi).
Autre problème : artsd est un serveur multimédia , le son n'est qu'une de ses fonctions. Hors rare au-delà du son son utilisation est marginale. Mais il n'a jamais été compatible avec les plugins de ffmpeg (mplayer) , LADSPA et en plus pour le son il ne gère pas le midi ...
Donc un formidable outil qui a passé son temps à contourner tous les bugs/limitations des systèmes linux (Xv n'existait pas, ffmpeg était instable, la latence du noyau était énorme , les drivers oss ...)
Alors que NMM qui a exactement le même objectif mais utilise tous ces projets externe a finalement été dévelopé en quelques mois , artsd avancait seul pendant des années ...
J'espère juste que les développeurs de arts ne vont pas être amer et feront contribuer ces nouveaux projets de leur expérience, sinon nous finirons avec gstreamer comme seule api multimédia .
Alban
[^] # Re: RIP arts
Posté par un_brice (site web personnel) . Évalué à 3.
# KDE sera user-friendly lorsque ce problème sera résolue.
Posté par Ontologia (site web personnel) . Évalué à 9.
Mandrake, que je bidouille en fonction de mes besoins.
Mon utilisation devenat strictement bureautique avec un petit peu de dev, j'observe le desktop offert par KDE en tant que gestionnaire d'un réseau de 35 postes en entreprises, utilisés par toutes sortes d'utilisateurs de tous ages et de tous niveaux.
Je me met donc dans la peau du end-user normal qui panique quand son icône Word a disparu, croyant qu'il a été désinstallé.
J'observe sous cet angle le développement de KDE, ses avancées
(géniales), ses avantages par rapport à XP (pour la première fois, je peux affirmer, depuis environ 6 mois, que KDE apporte des plus à XP sous certains aspects pour un utilisateur novice), ses ratés et ses manques.
Parmi les gros manques, reste celui du son.
Franchement, Billou et ses sbires doivent être mort de rires.
C'est loin d'être au point...
Loin de moi l'idée de critiquer, il faut rendre hommage au travail de
nombreux développeurs talentueux, ya 4 ans je m'arrachais les cheveux avec oss, maintenant on a alsa et parfois, il arrive que Arts
fonctionne.
Sous windows, que l'on peu critiquer autant que l'on veut, le mixage du son n'est plus un problème depuis longtemps.
Sous Linux, et dans le cas qui nous occupe KDE, il y a encore du travail. En effet, toujours dans cette logique de communauté qui me dérange quelque part en tant que Républicains français (très) méfiant vis à vis du communautarisme, mais aussi en tant que passionné de primatologie/ethno/anthropologie tout à fait réaliste quand à la primalité et donc l'attractivité de ce type de structures sociales, le concept "le but est de faire un serveur de son pour KDE et les appli multimédia de KDE, et les autres on s'en tappes" m'échauffe assez le sang.
J'entend déjà les sarcasmes de mes amis windowsiens : "tiens c'est dingue, faut reconfigurer le son selon que tu utilise KDE, Gnome, etc..."
C'est LE gros problème.
On ne peut demander à un utilisateur novice de choisir entre la couche d'émulation oss d'alsa, alsa lui même, arts, ou je ne sais quoi d'autres, comme je suis obligé de le faire.
Personnelement, cela ne me dérange pas, c'est juste un contre temps, et kill sur le terminal. Mais cela n'est qu'à la porté de power-user comme nous.
Il est déjà génant pour un novice de devoir choisir entre quinze
applications offrant le même service, si en plus il doit utiliser le
terminal...
<pas tapper> Je sais, avoir plusieurs appli pour le même service est un plus, une liberté que comme vous j'apprécie et dont je n'aimerai pas me passer.
</pas tapper>
Mais ce n'est pas le cas d'un novice qui veut un logiciel pour lire ses
DVD, un logiciel de gravure, un traitement de texte, un navigateur, son logiciel de mail et son logiciel de messagerie instantané.
Ce sont des gens qui sont perdu quand on a déplacé un icône de 50 pixels dans une barre d'outil, alors leur proposer 3 lecteurs vidéo, 2 navigateurs, etc... leur fait peur.
C'est d'ailleurs pour cela que je milite auprès de Mandrake, puisqu'ils destinent leur distrib à cette population (enfin il aimerait bien) de poser la question à l'utilisateur, lors de l'installation, de son niveau de compétence et quelques autres questions permettant d'adapter le desktop à l'utilisateur.
Je répondrait, nous répondrions que nous sommes expert, ce faisant j'obtiendrai un bureau avec un terminal dans ma barre de tâches, plusieurs logiciels pour chaque fonctionnalitées, etc...
Le novice n'aurait aucun choix parmi les applications répondant à
certaines fonctionnalitées. Il faudra à la base faire le choix corneilien des logiciels. Tout au plus pourrait-on lui proposer un
présentation vidéo l'informant de l'existance de plusieurs logiciels,
de leur fonctionnalités propre, avantages/inconvéniant lui permettant de faire un choix (mais pas au début).
<parenthèse>
Je crois beaucoup aux présentations vidéo pour démocratiser linux. Je serai prêt à en faire quelques unes si j'avais sous la main un logiciel fonctionnel me permettant de faire une capture vidéo de mon desktop. Il en a été fait un, mais il déconne complètement et est à peu près inexploitable...
</parenthèse>
Il faut donc que l'ensemble des communautés se mettent d'accord, quitte à user de couches d'abstractions sur un serveur de sons efficasse permettant de faire fonctionner l'ensemble des applis.
gstreamer est surement très bien, Jack à l'air génial, etc... Je ne
connais pas les technologie.
Tant que certains problématiques de ce genre ne seront pas solutionnées(Visualiser automatiquement les partages samba dans le kdfm, visualisateur d'images gérant les galleries absent (enfin peut êtr que depuis...), les icônes d'applications instalées n'appraissant pas (toujours) dans le menu K, etc...), Linux ne sera pas prêt pour le destop et donc n'investira pas l'entreprise (où le son est un problème très secondaire) et donc...
C'est vraiment dommage, parce que toutes les briques sont présentes pour faire un OS mieux qu'XP. Mais entre lmes batailles entres communautés, le fait que les employés de Mandrake n'ont manifestement jamais vu une PME typique de leur vie, que l'implication partisane aveugle, ça limite...
'Fin voilà
Perso je travaille pour la suite ( http://isaacos.loria.fr(...) ), ça ne
m'angoisse plus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par Christophe Fergeau . Évalué à 3.
»
C'est xvidcap le logiciel que t'as testé ? (http://xvidcap.sourceforge.net/(...))
En ce qui concerne ta distrib idéale, ton pb de démon pour le son, ... ubuntu me semble pas mal au niveau du "une seule appli proposée par tâche". Comme c'est que des applis gnome, ça résoud le pb du démon pour le son au passage ;)
fedora a l'air de regarder un peu du côté de alsa/dmix pour voir si y a moyen de faire des choses intéressantes de ce côté là. Sinon t'as aussi une solution au pb des démons différents, c'est d'utiliser une carte son potable et de pas utiliser de démon pour le mixage ;)
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par Ontologia (site web personnel) . Évalué à 2.
C'était une horreur, impossible d'enregistrer un vidéo d'une définition supérieur à 320x200. et je ne suis malheureusement pas assez bon en dev pour l'améliorer :(
Il me semble que ce n'est pas dans le débat "tel distrib fait ce que tu veux, etc..."
Je veux être réaliste et à mon avis, seule Mdk, ne serait-ce que parce que c'est une entreprise et qu'ils ont choisi de s'adresser à la niche "Linux pour le desktop" est à même d'avoir les reins assez solide pour proposer une distribution cohérente :-)
Je pense aux formidable travail de mdk sur l'installation, sur le "panneau de configuration" (j'utilise l'expression windowsienne à dessein), etc...
Cà n'est pas contre les distrib alternative, mais je pense que seule une boite avec des moyens, en sus de la communautés peut proposer une distrib crédible.
Quand à mes problèmes de sons, je m'en contente tout à fait, comme je le disais, je bidouille quand il ya à bidouiller, j'arrive toujours à m'en sortir.
Mon propos est que le novice, il installe son linux, ça doit marcher, point.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par Christophe Fergeau . Évalué à 5.
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par cedricv . Évalué à 8.
* New screen capture input plugin for X11, Win32, BeOS and Mac OS X
(Stream your desktop)
qui te permet de capturer donc ton desktop et de la streamer vers le réseau ou vers un fichier :)
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par djibb (site web personnel) . Évalué à 2.
Tu aurais un ch'ti lien plus explicite ?
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par djibb (site web personnel) . Évalué à 2.
bon ca bug un peu chez moi... mais j'ai les drivers ATI je reesaye en dri.
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par spart . Évalué à 1.
http://www.unixuser.org/~euske/vnc2swf/(...)
pour capturer une session VNC et la convertir en animation Macromedia Flash(tm) kipuképalib.
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par un_brice (site web personnel) . Évalué à 2.
Quand on utilise directx, mais sinon, sous win9x, les cartes avec un seul cannal ne jouaient qu'un son à la foix.
Et puis, dmix ça doit bien avoir deux ans. Et avant, on s'en sortait, avec la sortie alsa de sdl et artsdsp (sans parler de ceux qui ont acheté 20¤ une carte son multicanaux).
Arts n'as pas été conçu pour KDE, même si ce dernier l'a popularisé. Il existait avant et n'est pas utilisé que par les applications KDE.
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par wismerhill . Évalué à 1.
J'ai fait une recherche avec urpmf, le seul fichier contenant dmix que j'ai trouvé c'est dans la doc d'alsa pour une fonction de l'api.
[^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.
Posté par un_brice (site web personnel) . Évalué à 3.
# mouais
Posté par TImaniac (site web personnel) . Évalué à 4.
[^] # Re: mouais
Posté par Infernal Quack (site web personnel) . Évalué à 7.
Depuis, KDE ne veut pas dépendre d'un produit externe sur lequel elle n'a pas la main (dans le sens "connaissance" pas "contrôle").
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: mouais
Posté par gnumdk (site web personnel) . Évalué à 5.
# DirectX
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Il serait temps d'avoir un système unifié (un peu comme on a Xorg pour l'affichage graphique) pour les applications multimédia. Ca simplifierait vraiment les choses pour les développeurs et les utilisateurs.
[^] # Re: DirectX
Posté par Jean Roc Morreale . Évalué à 4.
"Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer."
[^] # Re: DirectX
Posté par Christophe Fergeau . Évalué à 4.
[^] # Re: DirectX
Posté par Croweye . Évalué à 2.
tu veux rire!!!!
bon, p-e pour le son et la gestion des events, mais pour l api graphique, c est un vrai cauchemar pour faire autre chose que des jeux.
Je travaille pour une compagnie qui tente de porter sa lib graphique sous linux, on prennait sdl au debut, finalment, on a pété un plomb et tout recodé l'affichage. Le simple fait de ne pas pouvoir avoir du multi display est une horreur. Ils ont voulu avant tout etre ultra portable, le problème, c que si une architecture ne suportait pas telle chose, toutes les autres ne l ont pas non plus. Il faut voir aussi l'interface de l'overlay de SDL... a comparer avec Xv et DirectX, il n'y a pas grand possibilite de manoeuvre (tout de meme bravo pour l'overaly software, c rapide)
finalement , pour revenir notre code, sorry, ils ont pas voulu qu on le rendre gpl... mais j avais commencé le tout chez nous pour montrer au boss et forcer la migration, des que je clean ca un peu, je rend ca publique, ca fairait un bel ensemble avec la sdl courrante, notament permettre plusieur display (fenetré, X only)
[^] # Re: DirectX
Posté par kassoulet (site web personnel) . Évalué à 2.
/o\
[^] # Re: DirectX
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: DirectX
Posté par kassoulet (site web personnel) . Évalué à 1.
ou l'utilisateur va devoir s'arracher les cheveux pour trouver comment avoir du son ?
[^] # Re: DirectX
Posté par Jiba (site web personnel) . Évalué à 3.
[^] # Re: DirectX
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: DirectX
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: DirectX
Posté par Al Brow . Évalué à 1.
# Rediriger son windows vers pc linux avec arts
Posté par regis1 . Évalué à 1.
Le but est dutiliser mon ensemble 4.1 qui est branche sur mon PC sous linux depuis mon portable sous windows (quand je joue ^_^, sinon je meternise pas ss cet OS :p).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.