Webcam + Linux = Mercury

Par marc[i1], 26 août 2005 à 08:09 :: Général :: #148 :: rss

Et oui, j'ai fini par craquer ! J'ai installé Mercury à Isa pour qu'elle puisse utiliser la webcam avec ses copines sur MSN.

Pour ceux que cela interresse, Mercury est une application non-libre (au sens GPL) écrite en Java, mais qui a l'avantage énorme de bénéficier du support vidéo pour MSN. Mais il supporte aussi tout les « machins » de MSN, tel que les grosses images à la con (j'ai perdu le nom ^_^), le wizz, ... bref tout ce qui rends MSN parfaitement indispensable aux ados shootés aux skyblogs et qui vous fait regretter de ne pas avoir une connection à 20 Méga.

Bah moi je reste avec Gaim, au moins j'ai pas l'impression d'avoir allumer un sapin de noêl pour dialoguer ... oui je sais Jabber, toussa ... mais non !

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le 26 août 2005 à 09:10, par marc (un autre)

"non-libre (au sens GPL)" => c'est même pas open-source. C'est du bon vieux logiciel proprio, mais gratuit... et petit détails qui tue, qui marche bien

"oui je sais Jabber, toussa ... mais non !" => mais pourquoi ?

2. Le 26 août 2005 à 09:40, par marc[i1]

Clair que ça marche bien mais un peu "too much" pour moi !

En fait j'ai pas vu de client Jabber suffisament bien foutu ! Psi n'est pas terrible, Gajim, bah faut installer PyGTK, ... et ça me saoul en fait Quand il ont disposera d'un client bien foutu en "stand-alone", alors oui mais pour le moment, c'est plus, un pour KDE et l'autre pour Gnome ... et moi sous XFCE

3. Le 26 août 2005 à 10:16, par marc (un autre)

Tu attends quoi exactement ? Si tu es sur XFCE, alors c'est basé sur GTK... Si tu espères que toutes les applis soient écrites en C, je crois que tu vas devoir faire ceinture. Quand tu vois Gaim, tu es content que les autres projets ne suivent pas ce dernier... Heureusement, de plus en plus, on utilise des langages adaptés pour faire certaines taches... et PyGTK est un bon exemple =) Faire une petite appli graphique en python est bien moins douloureux qu'en C par exemple... Hélas, on arrive aussi à des "dérives" avec toutes ces superbes applis écrites en C#/GTK#/mono... Mais bon, je te comprend, avoir à maintenir xxx libs, à la main, "from source", c'est pas chouette... (et c'est là que je case avec debian, c'est une seule commande pour installer 600kb (PyGTK, c'est pas gros))

4. Le 26 août 2005 à 10:20, par Geobert

je test le psi 0.10-test1 et ça commence à devenir vraiment excellent. ça manque de meta-contact mais c'est prévue pour la prochaine version. à cette version là je pense adopter !

5. Le 28 août 2005 à 16:00, par bouh

marc (un autre) a dit: Quand tu vois Gaim, tu es content que les autres projets ne suivent pas ce dernier...

Si j'ai bien compris, tu prefere les applis ecrites en python - tcl/tk? Ou pire: en utilisant wish....

Je partage pas trop ton avis. Il me semble que la stabilite et la variete d'une libraire comme Gtkmm ou Qt permet de creer des applications plus robustes et plus fonctionelles (et aussi plus rapides). Ensuite c'est surtout une question de gout (ou de degout ).

6. Le 29 août 2005 à 09:04, par marc (un autre)

Je partage pas trop ton avis. Il me semble que la stabilite et la variete d'une libraire comme Gtkmm ou Qt permet de creer des applications plus robustes et plus fonctionelles (et aussi plus rapides)

Si j'étais en forme, je t'aurais demandé de développer car j'avoue ne pas comprendre ou se cache la justification de ton argument, surtout le plus robustes et plus fonctionelles. Je comprend même pas pourquoi tu parles de tcl/tk qui n'a pas été abordé ici... bonne journée quand même =)

7. Le 29 août 2005 à 09:30, par marc[i1]

Si j'étais en forme, ...
Retour de week end difficile ? ou bien c'est l'épuisement de 24h chrono :p

8. Le 29 août 2005 à 10:01, par Geobert

je pense que ce que marc un autre veut dire, c'est que les soft codés en langage scripté (python, tcl/tk...) ne sont pas forcemment moins robuste qu'un soft codé en C/C++.

Et c'est bien vrai.

9. Le 29 août 2005 à 10:35, par marc (un autre)

marc[i1]: oui et non. Disons que j'ai tendance à facilement partir en troll, et que ton blog n'est pas franchement le bon endroit pour ça Et oui, ce weekend on a fait 13 épisode de 24h, alors la forme est pas au top =)

Geobert: clairement... Question vitesse, je trouve pas l'argument très bon non plus. J'ai du mal à voir... C'est plus au niveau de l'aspect usine à gaz que la vitesse se fait sentir.... L'argument le C/C++ plus rapide que le reste du monde, c'est pas vraiment applicable à tous les domaines... Pour la robustesse, j'ai presque l'impression qu'il est plus facile d'écrire de la merde en C/C++ qu'en python (ou autre).

10. Le 29 août 2005 à 10:50, par marc[i1]

... ce weekend on a fait 13 épisode de 24h, ... Ouha ! j'ai hâte de voir ça alors Rrrhhaaa le teasing de la mort ! 'chuis tout excité maintenant :p

11. Le 29 août 2005 à 10:52, par marc[i1]

ah oui
j'ai tendance à facilement partir en troll
mouais un Marc en vaut un autre ;), toi aussi t'aime bien chatouiller le troll sous les bras ...

Le troll c'est bon, mangez-en !

12. Le 29 août 2005 à 11:05, par marc (un autre)

marc[i1] : Niveau 24, ouai cette série est pas mal faite. C'est un peu comme un film américain pas trop mal (bateau, mais bon...), mais super long. Le tout est bien fait, le scenar pas mal... Bref, c'est mieux que Rick Hunter quoi =) Niveau troll, c'est chouette tant que ça reste gentil et pas trop gros. Le coup de mettre python, tcl/tk (wish) dans le même panier, dire que le wrapper GTK de python est de la merde, et que coder en C++ est gage de qualité, ça passe même pas l'entrée poid lourd de carrefour...

13. Le 29 août 2005 à 18:31, par bouh

Ok, je veux bien reconnaitre que j'ai pas trop ettayer mes arguments. Puisque tu l'as gentilement demande en lachant des arguments frappants: "dire que le wrapper GTK de python est de la merde, et que coder en C++ est gage de qualité, ça passe même pas l'entrée poid lourd de carrefour..." je vais donc m'executer

On sera bien d'accord toi et moi, et jusqu'a la fin de ce sujet, que la qualite d'un code ne depend pas du language mais bien de la personne qui l'utilise et qui cree l'appli. Maintenant si tu relis ma note dans ce sens tu y verra qu'il n'y est pas question de "code propre" ou "merdique".

PyGtk n'est qu'un interpreteur, puissant certes, mais tu restes limite par les possibilites de l'interpreteur. Aussi bon que soit ton code, la stabilite de ton application passe du reste par celle de l'interpreteur.

2, un executable binaire ne requiert pas de machine virtuelle pour fonctionner. Et comme beaucoup de librairies C++ sont maintenant standardisees, il n'est plus aussi difficile qu'avant de porter une application d'une plateforme a l'autre. Ce qui fait que l'avantage "cross plateforme" d'un language interprete, est de moins en moins prevalant. (Surtout que il me semble que l'interpreteur Python n'est pas aussi performant sous windows que sous linux, ok la je suis pas assez cale, donc tu pourras surement me confirmer ou m'enfoncer) Sketch est recement passe sous Gtk+, pour cause de portabilite il me semble.

3, il y a une chose que tu ne peux pas enlever au C: c'est son evidente maturite. "C" est vieux. Mais il est toujours la. "C" est mature, il ne change pas d'annee apres annee, son comportement est connu et on n'a pas a recoder une application tout les six mois pour la nouvelle version qui vient de sortir. C beneficie de beaucoup d'avantage lie au C. C/C sont puissants, les libraires a dispositions sont innombrables et il n'y a que l'imagination qui puisse te limiter (ou ton pc ). C++ dispose d'environement graphiques qui rende la confection d'interfaces graphiques tout aussi rapide et intuitive que n'importe quel autre language.

Et puis vu que tu as l'air de coder en Python.... Allez .. ne le nie pas, tu as bien utilise du CGI-C au moins une fois? :-p Pour moi, Python, c'est un choix qui ne se pose que pour une interface simple et rapide (et encore il y a enormement d'alternatives...)

Enfin comme je le disait a la fin du precedant post, et c'est le facteur le plus important: chaque programmeur a ses preferences et est plus efficace sur l'un ou l'autre des langages. Bonne soiree.

14. Le 29 août 2005 à 18:40, par marc[i1]

Wouhaaa !
tu fais des commentaires plus long que mes billets !

15. Le 29 août 2005 à 19:14, par bouh

En fait, lol, j'en suis pas tres fier. Surtout que j'ai quand meme reussit a ecrire ca "Ou pire: en utilisant wish...."

Evidement ce que je voulais dire c'est que ce peut encore s'ameliorer, mais ca l'equipe qui a bosser dessus le sais deja. Donc elle avait pas vraiment besoin que je marque ca.

Je m'excuse.

Et c'est ce que j'aurais du faire tout de suite plutot que de reagir betement, contrairement a Geobert, et d'envoyer un post inutile de 100 lignes.

16. Le 29 août 2005 à 23:24, par marc[i1]

Disons que marc(l'autre) est un bon trolleur et t'as plonger la tête la première

En tout cas, moi j'apprends toujours des trucs en lisant les commentaires

17. Le 30 août 2005 à 09:35, par Geobert

bouh : je pige mieux ton point de vue maintenant

18. Le 30 août 2005 à 09:54, par marc (un autre)

ouai, perso j'ai rien appris, c'est toujours le vieux troll moisi qui resort tous les 15jours. Je ne code pas uniquement en python (en fait, très peu). J'ai plus codé en C par exemple, donc je pense avoir suffisement de recul pour critiquer l'un ou l'autre. Dire que le C n'a pas évolué depuis 10ans, c'est faux. Le C++ pareil. Les normes ne bougent pas tant que ça (pourtant, C99...enfin bon), mais les compilos sont loins de donner une stabilité au langage... y'a qu'a voir à chaque version majeur de gcc les problèmes que ça amène (surtout en C++), donc une appli coder il y a plusieurs année ne compilera sans doute pas sans douleur avec un gcc-4. De plus, les bibliothèques de bases que tu utilises bougent et demandent de revoir ton code régulièrement. Le C ou le C++ n'y peuvent rien, pas plus que le python.
Je tiens à souligner qu'ici on parlait de petite applis graphique. En utilisant Gtk+ ou Qt(4 uniquement), j'aimerais savoir en quoi tu es plus portable que du code python par exemple ?
Bref, j'ai eu une mauvaise matinée, j'ai pas dormis, alors j'arrete là, mais je suis vraiment pas d'accord avec tes arguments qui sont quand même assez superficiels (désolé, mais en apparence, ça ressemble vraiment au vieux préjugé qui dit que la vitesse d'une appli graphique repose uniquement sur le fait que le langage soit compilé ou non, avec par dessus une couche de un programme écrit en langage interprété sera bcp plus lent (trop) qu'écrit dans un langage compilé).
Y'auraient encore plein de chose à dire, mais étant donné qu'il suffit de taper un ou deux mot clé sur google pour avoir des réponses un peu plus complète, je m'arrete là

19. Le 30 août 2005 à 11:24, par bouh

As-tu envoye ton post avec une appli graphique ? Est-elle ecrite en python?

Le python meriterais donc plus d'audiance ? Malheureusement, tu sembles promouvoir ce language, mais tu ne m'a pas vraiment convaincu non plus de ton cote. Peut-tu me donner l'exemple d'une application rapide, stable, et portee sur plusieurs plateformes ecrite en Python?

20. Le 30 août 2005 à 11:54, par marc (un autre)

J'ai dis qqpart que python était la solution à tous les problèmes ? Non, je parle de petites appli graphique comme un client IM (ça reste le sujet ici). Pour poster, j'utilise firefox, qui il me semble utilise XUL...c'est compilé XUL ?

Pour exemple, je dirais bittorrent, mais je suis sûr qu'on peut en trouver d'autres. Si tu es convaincu que pour l'écriture d'une petite appli graphique, C/C++ sont plus adapté, libre à toi. Moi je verais plus que pour une petite appli graphique, le surplus ajouté par C* est moins négligeable que dans une grosse appli. C'est une question de compromis le plus souvent. Par contre, tes arguments sur la vitesse de la chose, la stabilité, je resterais contre. Cela se tient sur les machines pas très costaud (Pentium II et inférieur je dirais), et encore... Beaucoup de monde utilise java sur des machines relativement légère de type PDA.
Moi, j'arrete là

21. Le 30 août 2005 à 14:00, par bouh

J'ai mal considere l'aspect "petite appli graphique" que tu as pourtant pris la peine de mentionner dans chaque post. Je suis trop parti sur la grosse appli.

De ce fait tes arguments se tiennent. (Attention j'ai pas dis tous: Java sur le PDA, c'est pour l'aspect cross-plateforme, il me semble )

Je me suis du coup demander pourquoi j'utilisais pas python plus souvent? En fait, soit j'ecris un FvwmScript ou une applet gnome. Ce qui est pas vraiment de la programmation mais plus du jouet... Du coup je me passe bien de python. Mais je vois mieux ton interet pour la chose.

C/C++ reste le choix de la performance. Mon choix le plus souvent, a tord peut-etre.

Cette discussion a tout de meme ete enrichissante pour l'un de nous deux: moi Merci et tant pis pour toi

22. Le 30 août 2005 à 14:32, par marc (un autre) (le faible)

Note qu'il existe tout de même de grosse appli qui utilise beaucoup Python, comme Zope, mais là, ça se discute plus
Pour ce qui est de java, c'était surtout pour montrer que malgré tout ce qu'on peut dire sur sa lourdeur et sa jvm, on le retrouve sur beaucoup de téléphones et PDAs ...
Désolé si j'ai paru un peu agressif par moment, c'est sans doute le fait que j'ai passé 2heure ce matin à tenter d'avoir une machine en état de marche pour bosser :/
Tout le monde est content maintenant, alors tant mieux

23. Le 30 août 2005 à 16:17, par marc[i1]

Bah pour moi il en ressort :

Python, c'est bien ... si c'est pas trop gros !

C/C++, c'est mieux sauf si c'est trop petit !

donc vous m'auriez poser la question dès le début, je vous l'aurez dit

24. Le 30 août 2005 à 16:53, par bouh

lol

25. Le 30 août 2005 à 17:07, par marc (un autre)

mouaif mouaif Faudrait aussi prendre en compte d'autres critères:

ecrire du python propre est plus simple que d'écrire du C++ propre

le comportement requis. Si tu t'en fout que ton opération prenne un peu plus de temps en échange du traitement que t'offre python (gestion mémoire par exemple), quite à gonfler un peu la machine....

blablabla.

C'est sans fin et il n'y a pas de réponse absolue :). Il faut faire la chasse aux généralisation rapides! De la même façon qu'il ne me viendrait pas à l'idée de pondre un programme C pour faire du traitement de chaînes mais plutôt du perl/python/awk/sed, je ne sortirais pas du C/C++ pour une appli qui se fait en 10min avec glade + python.
Qui eut crû que ça partirait autant dans ce troll en parlant d'un soft:

proprio

qui exploite un protocole proprio

qui demande un programme proprio pour se lancer (jvm)

Au fait, Mercury, il est lent ?

26. Le 30 août 2005 à 17:18, par marc[i1]

Au fait, Mercury, il est lent ? Sans la cam, non ça va pas trop mal ... mais une fois la cam branchée, c'est affreux !
Le soft ralentie tellement que cela est vite pénible :

tu tapes à l'aveugle, les lettres s'affichent après quelques secondes !

faire défiler la conversation est quasi impossible

Mais globalement, il fait ce qu'on lui demande ... affiche les cams

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.

marc[i1]