Goffi a écrit 1524 commentaires

J'ai réussi à faire la sélection, c'est assez étrange: si je sélectionne mon image juste détourée dans un calque, ça ne marche pas. Si j'exporte l'image en PNG (en gardant le canal alpha bien sûr), et que je la réouvre depuis le PNG, là la sélection marche comme sur la vidéo. J'espère qu'on pourra arranger cette sélection aussi: j'ai fait un test ou le bras est collé au corps, du coup quand je déplace le bras ça déforme le corps, il faudrait pouvoir couper le lien avec le corps (en fait peut-être qu'il suffirait juste que je détoure le bras séparément, il faudra que je teste).

Mais sinon l'outil est pratique, j'aime beaucoup :)

Oui j'ai regardé un peu la description de GEGL sur Wikipédia, ça a l'air bien sympa :). Je suppose que ça va permettre d'amener des fonctionnalités réclamées comme les profondeurs à plus de 8 bits, et le support CMJN (dont personnellement je me moque, mais qui servent probablement au niveau pro).

Et oui je sais bien que c'est une version de dév, je ne m'attendais pas à un truc nickel :). J'ai juste mis les infos au cas où quelqu'un voudrait tester en avant-première cet outil sympathique, je garde ma 2.8.x de Debian pour une vraie utilisation.

Bon alors pour j'ai compilé la branche de dév pour tester sur ma Debian Sid. Il faut compiler à la main la dernière version de babl et la branche "origin/soc-2013-n-point-deformation" pour gegl et GIMP, à part ça ça compile sans problème une fois les dépendances de GIMP, gegl et babl installées (à coups de apt-get build-dep).

Les sources de gegl et babl sont ici: http://www.gegl.org/#_download

Je me retrouve avec un GIMP forcément un peu boggué (genre l'outil d'extraction de premier plan ne fonctionne pas, des comportements bizarres), les ciseaux intelligents semblent avoir disparus (j'espère qu'ils ne comptent pas les enlever !), et affreusement lent (j'ai mis les options par défaut, donc ça ne devrait pas être compilé avec le mode debug, je n'ai pas creusé plus les raisons de ces ralentissements).

L'outil de déformation en lui même je n'ai pas compris comment il sélectionnait uniquement les parties non transparentes de son calque sur la vidéo: en prenant la même image de Sintel, en la détourant, recadrant et dedimensionnant à peu près comme sur la vidéo (sinon ça râme), à chaque fois que je clique ça met la grille sur toute l'image, et du coup la déformation n'est pas la même. J'ai réussi une fois par accident à avoir la grille de la même manière que sur la vidéo, mais je n'ai pas encore réussi à reproduire ni à comprendre pourquoi. Je ne sais pas si c'est un bogue ou une combinaise de touche que je ne fais pas (les options ont l'air identiques à la vidéo).
Ah et aussi les actions de ce nouvel outil ne sont pas encore ajoutées correctement dans l'historique d'annulation.

Mais bon, je ne m'attendais pas à avoir un truc foncionnel en compilant à l'arrache une version de dév :)

En tout cas un outil bien sympa. Y'a aussi un nouvel outil de déformation en tordant, « warp transoform », mais je n'ai pas trop testé encore.

Salut,

bon j'ai testé, ça a l'air bien sur le papier, mais en 4/5 essais avec un ami à Vienne, on a eu (tous les 2):

• des problèmes de connexion au serveur (compte créé depuis le site, donc utilisant le serveur officiel)

• le contact n'était pas trouvé

• après avoir réussi à s'appeler, crash des 2 côtés en activant la vidéo.

Dommage, c'est pas mal intéressant, gageons que ça va s'améliorer rapidement, bravo tout de même et bon courage :)

L'appli Android est à mon avis réussie, l'appli GNU/Linux a demandé mon intervention parce que je suis derrière un NAT (FAIBOX), ce qui aurait pu être plus simple à mon avis (un non initié sera perdu).

Du côté SIP, je trouve Jitsi intéressant et je le mentionne souvent dans les commentaires/mes confs, mais l'interface SWING (très très) lente et moche sur mon KDE@Debian Sid, et je n'ai jamais réussi à faire une vidéo conférence correcte avec (saccade ou plantage à chaque fois). Pourtant je l'ai déjà vu tourner et bien quand j'étais voisin de stand aux RMLL il y a quelques années.

Bref, espérons que ça va vite s'améliorer :)

C'est plus facile quand il y a un contraste fort avec le fond. En gros l'idée c'est d'isoler les couleurs avec la courbe de couleurs (une fois la courbe affichée avec couleurs/courbes tu cliques sur l'image un peu partout sur les cheveux pour voir où ça se situe sur la courbe, puis tu mets les couleurs avant et après en noir), tu convertis ensuite en niveaux de gris (couleurs/désaturer/luminosité) et tu nettoie un peu. Puis tu convertis ça en masque de calque. C'est pas parfait, mais ça permet d'avoir le gros des cheveux assez facilement.

C'est expliqué (avec une technique plus ou moins similaire) dans des tutos comme celui-ci: http://www.dom-web.net/?p=1597 . Si les cheveux sont dans une couleurs particulièrement proche du rouge, vert ou bleu, ça peut être intéressant d'utiliser les canaux pour isoler plus facilement la partie qui t'intéresse.

Tu peux déjà compiler la branche « soc-2013-n-point-deformation-tool » dispo ici: https://git.gnome.org/browse/gimp/

Après je ne sais pas quand ce sera inclus mainstream.

gimp-gmic fait partie des paquets installés sur ma Debian sid ;)

Faudra que j'y jette un œil plus en détails…

Oh, la seule formation Blender que j'ai eu (mais que je n'ai malheureusement pas suivi assidûment à l'époque), c'était effectivement dans une autre vie (fort fort lointaine) dans le sud, par un collègue, ce serait donc toi ? Si oui, où en es tu de ton jeu qui avait l'air très prometteur ?

En fait ma vie a beaucoup changé ces derniers temps (en bien !), et du coup j'arrive un peu mieux à m'organiser pour faire ça.

Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir (quoique ses possibilités de montage peuvent peut-être être utiles pour des démos vidéo). Je viens d'acheter le livre « la 3D libre avec Blender 2.6 » qui est plus conséquent que celui sur GIMP :). On verra si j'aurai le courage de le lire jusqu'au bout.

Pour mes vidéos sur SàT j'utilise ffmpeg, c'est le seul qui fonctionnait correctement sans saccade sur ma machine, et qui produisait un bon résultat.

Salut,

merci pour ce compte rendu intéressant.

La partie GNU Social m'intéresse particulièrement: je croyais le projet pratiquement mort, mais si je comprends bien l'annonce officielle (http://www.gnu.org/software/social/merge.html), ils reprennent plutôt status.net qui a été plus ou moins abandonné par son ancien mainteneur en faveur de pump.io (même si d'après l'annonce il restera un peu actif dessus). C'est intéressant, reste à voir ce que ça va donner.

J'ai quand même l'impression qu'il y a des bulles entre tous ces projets: ceux basé sur XMPP (Jappix, Movim, BuddyCloud, SàT, …), Diaspora, les status.net, friendica, lorea et pump.io. C'est un peu dommage, il nous manque un point (site, planète, ou autre) commun pour se tenir à jour sur les projets libres de ce type.

Ben j’espère que ça va vite se standardiser bien comme il faut tout ça, parce que je sais pas vous mais je n’arrive pas à envoyer ou recevoir de fichiers via un XMPP avec un autre client que Pidgin (pourtant j’ai souvenir d’avoir réussi avec Kopete il y a un moment).

Attention, je parle uniquement du microblogage, parce que c'est expérimental, et il y a plusieurs projets (dont les 3 sus-cités) qui travaillent dessus. Mes modifs pour SàT je ne les ai pas encore proposées parce que ça prend du temps de faire une XEP propre, et que pour l'instant je ne l'ai pas trouvé.

Par contre le transfert de fichier donc tu parles est tout à fait standard, il y a la vieille méthode avec la XEP-0096 que pratiquement tout le monde gère mais qui ne passe pas facilement les NATs et autres joyeusetés, et la nouvelle via Jingle qui marche beaucoup mieux mais qui est beaucoup moins implémentée, j'avais expliqué ça (ouch avec des fautes d'ailleurs à la relecture) dans un commentaire.

Bref si tu n'arrives pas à transférer un fichier, tu devrais le signaler sur les outils de débogage des clients concernés.

Par contre, je t'assure que Prosody implément(e/ait?) de façon très bizarre pubsub et que l'année passée en tout cas, durant le développement de la version 0.9, Movim ne trouvait toujours qu'un seul message par personne.

Pour Movim je ne sais pas, mais je sais que Jappix utilisait les notifications PEP qui de base envoient le dernier item uniquement (même s'il peut en envoyer plus). Le truc est que cette notif du dernier élément n'est pas prévue pour ça, c'est fait pour des événements personnels (d'où le nom de la XEP) du style l'humeur de quelqu'un ou la musique en cours d'écoute. Le problème peut venir de là (mais les développeurs confirmeront ou infirmeront s'ils passent par là).

Pour le microblogage, il faut explicitement demander les X derniers items pour tous ses contacts, et ça Prosody sait forcément le faire s'il fait du PubSub.

Sinon, personnellement, quand je vois le statut "Draft" et l'avertissement ci-dessous (sur la page xep que tu as cité), je ne considère pas l'extension faisant parti du standard.

Draft est un standard brouillon, mais c'est un standard. Disons que ce que je n'aimais pas dans la dépêche, c'est qu'on avait l'impresson que c'était un truc non officiel implémenté par Metronome, alors que ça fait des années que c'est tout à fait officiel et utilisé, le statut annonce simplement que des ajustements peuvent encore avoir lieu.
Si tu veux une description précise des différents statuts des XEP, c'est la première qui explique tout ça: http://xmpp.org/extensions/xep-0001.html .

Oui la notification d'une nouvelle image ou d'une galerie, les formats à supporter, les résolutions recommandées, les métadonnées à mettre, etc. Une simple notification ou un envoi complet c'est à définir, mais je pense que l'idéal serait de juste notifier, et de récupérer ensuite l'image via un transfert de fichiers Jingle (ou éventuellement mettre un aperçu dans la notification).

Movim et Jappix utilisent la XEP-0277(microblogage) et sont compatibles entre eux. Pour les images vu que ce n'est pas standardisés, ils ont tous les 2 leur solution maison, je ne sais pas si elles sont compatibles.

SàT gère aussi la XEP-0277, mais l'implémentation des permissions fines (cf http://www.goffi.org/post/2012/06/24/Permissions-fines-pour-PubSub) qui permettent d'envoyer un message juste à un groupe m'ont obligé à faire ma propre implémentation expérimentale de pubsub (http://repos.goffi.org/sat_pubsub/), en attendant de proposer ça à la standardisation. Ça devrait être compatible, sauf qu'une implémentation externe ne me permet pas d'utiliser PEP (une version simplifiée de pubsub qui associe notamment un jid à un nœud pubsub), et du coup ça ne l'est pas. Mais la structure des messages, le protocole est globalement le même (il est enrichie pour SàT de manière compatible).

C'est un peu technique, je peux détailler plus si tu veux, mais en gros pour l'instant ça n'est pas compatible, et dans le futur ça devrait l'être.

C'est la XEP-0277 qui défini le format de données (en gros c'est du atom).

La reponse dans le message du dev principal: Prosody ne conserve pas les messages sur le disque parce que c'est difficile de faire ça proprement, et qu'ils ont d'autres priorités.

J'ai discuté entre temps. Effectivement l'implémentation n'est pas persistante, et c'est une des différence majeure avec metronome, qui aurait une implementation « naive » de la persistance. Ceci dit, tu ne récupères pas que le dernier message avec l'implémentation de Prosody (ce qui serait aberrant avec PubSub), l'affirmation est donc fausse.

C'est juste qu'il n'y a pas encore de XEP sur le partages d'images en particuliers

Quoi (ter) ? Entre le Out-of-band, le In-band et le Bits-of-Binary quand c'est pas trop gros, il y a largement de quoi faire pour échanger du binaire.

Tu me parles de transfert de fichier, moi je te parle de XEP qui défini le partage d'images (ou de galeries) par PubSub: est-ce qu'on code l'image en XML ? Est-ce qu'on utilise le SI File Transfer ? Est-ce qu'on utilise Jingle ? Comment on envoit les métadonneés ? Lesquelles ? Etc.
J'ai déjà dit qu'on pouvait transférer des données binaires avec PubSub.

P.-S.: en relisant mon commentaire: je n'ai pas voulu avoir un ton si agressif, que les contributeurs de la dépêche ne le prennent pas trop mal, c'est toujours bien d'avoir ce genre de dépêche.

Ceci dit, DLFP est un site très influant, et lire que Prosody ne garde que le dernier item en mémoire ou que PubSub n'est pas dans les standards, c'est répandre de mauvaises informations qui peuvent cause du tort à ces projets.

Merci tout de même pour la dépêche :)

Comment des approximations pareilles ont pu passer dans une dépêche collective ?

l'extension pubsub du protocole (qui n'est pas encore dans la standardisation d'XMPP)

Quoi ??? Bien sûr qu'elle est dans les standards: http://xmpp.org/extensions/xep-0060.html , c'est un brouillon de standard (Draft), une étape relativement avancée dans la procédure (l'avant dernière même avant l'état « final ») qui indique une implémentation recommandée, et la possibilité de modifications tant que possible mineures suite aux retours sur les implémentations.
PubSub est implémenté (de manière inégale) dans tous les serveurs XMPP que je connais (openfire, ejabberd, prosody, tigase, métronome) et probablement dans bon nombre de bibliothèques/cadriciels comme wokkel que j'utilise.
Alors peut-être que le phrase sous entend qu'elle n'est pas au statut de standard final, mais pubsub est dans les standards XMPP.

Ce système permet de publier des messages vers des groupes de personnes et de suivre différents groupes pour voir les messages publiés par les autres.

PubSub ne permet pas que de passer des messages (au sens message microbillet), et pas forcément vers des personnes: ça peut être utilisé par exemple pour stocker des données publiques (http://xmpp.org/extensions/xep-0222.html) ou privée (http://xmpp.org/extensions/xep-0223.html).

J'ai l'impression qu'il y a une confusion avec le microblogage (http://xmpp.org/extensions/xep-0277.html) qui est également dans les standards, mais dans un stade moins avancé.

Malheureusement, pubsub est une nouveauté récente dans Prosody et est encore en cours de développement. C'est pourquoi seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire (ce qui signifie qu'au moindre redémarrage de Prosody, ce message sera perdu).

Quoi (bis) ??? PubSub est certe officielement dans prosody depuis la 0.9 qui est sortie récemment, mais ça fait un petit moment qu'ils sont dessus. Je n'utilise pas cette implémentation, mais je doute très fortement que « seul votre dernier message sera enregistré et il ne sera enregistré qu'en mémoire ». Une confusion avec PEP peut-être ?

Bien que peu de clients ont un tel support, nous avons la chance d'avoir deux projets français qui proposent deux clients web différents : Jappix qui utilise beaucoup JavaScript et Movim qui s'efforce de faire travailler à minima le butineur en utilisant PHP.

Comme d'hab « Salut à Toi » passe à la trappe.

Pour ce faire, il sera donc nécessaire de placer un serveur BOSH entre Movim et Metronome pour le transfert de données entre le client et le serveur.

Ça ne me semble pas clair: BOSH fait partie de XMPP: http://xmpp.org/extensions/xep-0124.html et c'est inclus dans prosody (j'imagine dans metronome aussi du coup): http://prosody.im/doc/setting_up_bosh . Il est possible d'utiliser un module de prosody, ou un proxy BOSH externe.

le stockage des images n'étant pas supporté par pubsub

Il est tout à fait possible d'enregistrer des images ou n'importe quel fichier binaire via pubsub. C'est juste qu'il n'y a pas encore de XEP sur le partages d'images en particuliers, ce qui à n'en pas douter arrivera tôt ou tard.

Grâce à Jappix, Movim et Metronome IM, nous avons les premières implémentations de pubsub concrètes qui fonctionnent bien ensemble et qui permettent d'éprouver la version actuelle du brouillon du système publish/subscribe de XMPP.

Euh c'est complètement faux. Il y a des tas d'implémentations de pubsub qui tournent depuis des années, j'en ai cité au dessus, et il y a d'autres projets plus ou moins connus (au FOSDEM il y a 2 ans j'avais vu une démonstration d'un suivi de transports en commun utilisant pubsub). On entend peut-être plus parler des Jappix, Movim ou SàT sur DLFP, mais il ne faut pas cracher sur le super boulot qui a été fait jusqu'ici par tous les autres.

Bon, ceci mis à part, un grand bravo à l'équipe de Movim (et en particulier Timothée) pour le boulot et les progès de Movim: j'ai testé l'application Firefox OS rapidement, elle est très agréable à utiliser et prometteuse. Les mois à venir vont être excitants :)

T'as le paquet qui utilise les nightly builds, j'ai rarement de problème avec, et s'il y en a c'est réglé très rapidement (le lendemain ou quelques jours grand max): http://5digits.org/nightly/pentadactyl-latest.xpi

Pendant qu'on est dans les astuces, tu peux appuyer sur « i » pour te mettre en mode « caret ». Là il y a pas mal de raccourcis de vim qui fonctionnent. Par exemple si tu appuies sur « * » tu vas chercher le mot sous ton curseur. Un appui sur « n » et tu as le suivant. Un appui sur « ? » et tu changes de direction. Ça me sert moins dans une page web que quand je code dans vim, mais ça peut servir à d'autres.

tout ne se fait pas avec [maj] tab/les flèches/entrée ou espace ?

Non non ça marche de base, je n'ai pas d'extension particulières pour les regex.

Il faut ajouter \r à la fin de ton motif de recherche.

Pentadactyl gère les expressions regulières pour la recherche, ce que ne savait pas faire vimperator la dernière fois que j'ai regardé, et en plus je suis habitué aux raccourcis clavier que je trouve relativement cohérents avec vim (en essayant vimperator je me souviens avoir été gêné, mais je ne sais plus par quoi exactement).

Pour éditer du texte, si c'est un peu long j'utilise C-i pour lancer gvim, je ne crois pas que les dw et autres ye fonctionnent dans un formulaire, c'est le cas avec vimperator ?

Mais bon, pour mon utilisation, pentadactyl me convient parfaitement, et j'y suis tellement habitué que j'ai beaucoup de mal à utiliser un navigateur sans lui maintenant (tout comme je fais souvent des :w quand je ne suis pas sur ma machine et que je suis sur un autre éditeur que vim).

Firefox 24, c'est l'apparition bienvenue d'une fonctionnalité présente de longue date dans Chromium : la fermeture des onglets à droite de l'onglet pointé par un clic droit.

Pour supprimer les onglets à droite, avec pentadactyl il suffit de fait [nombre]d (et [nombre]D pour la gauche). Il y a peut-être plus élégant, mais je fais parfois 100d pour supprimer tous ceux à droite.

En bonus, on peut mettre un filtre. Par exemple :tabc! linuxfr supprimera tous les onglets DLFP.

Je n'ai pas encore essayé Cozy (enfin si mais la démo en ligne), juste Owncloud rapidement pour tester le calendrier (c'est ce qui m'intéresse le plus). Je vais tester Cozy bientôt, mais pour le moment j'ai beaucoup de choses à faire.

Si vous implémentez Caldav ça devrait être comme Owncloud, le problème étant qu'il n'y a pas encore de bonne solution libre pour gérer ça sur Android (aCal et Caldav Sync étant trop lents ou incomplets), mais ça a priori ça n'est pas votre problème et gageons que ça va s'améliorer avec le temps…

Tiens puisque tu es là: est-ce que vous avez des applications Firefox OS et Android (dépôt F-Droid surtout) prévues à plus ou moins long terme ? Pour le premier je suppose vu que vous travaillez avec Mozilla.

Parce que je viens de tester Owncloud: le site est vraiment pas mal, mais sur Android pour le calendrier il n'y a rien de satisfaisant en libre (une synchro caldav mais que dans un sens, et un calendrier Caldav mais ultra lent sur ma config, et peu pratique à mon goût). Côté application Firefox via le Firefox pour Android, je n'ai rien vu non plus.