Frédéric COIFFIER a écrit 702 commentaires

Est-ce que ce n'est pas lié à la configuration de Piwigo ?
Piwigo utilise différentes tailles fixes (XXS -> XXL) dont les dimensions sont configurables dans Configuration > Options > Tailles de photo.
Ensuite, suivant la mise en page, Piwigo choisira la taille juste en dessous.

Mais bon, malgré tout, bien souvent, c'est le thème qui limite. J'en suis arrivé à la conclusion que le mieux est de modifier un thème pour en faire ce que l'on souhaite…

Et non… je n'ai jamais compris pourquoi les KIO n'avait pas poussé l'idée jusqu'à créer des montages virtuels comme gvfs-smb (qui doit à priori utiliser FUSE mais dans ce cas, n'est-ce pas propre à Linux ?)

Bref, pour toutes les applications n'utilisant pas KIO (donc, toutes les applications non KDE), impossible d'avoir la transparence réseau…

Je crois que la question revient à chaque annonce OwnCloud, mais tu utilises quoi comme applications Android ? (si elles ne sont pas libres mais qu'elles fonctionnent, je ne te jetterais la pierre [même si c'est toujours mieux])

Ah ? Le support de Btrfs dans la Debian d'il y a 1 an ? Donc, ça doit être très vieux. Quitte à vouloir jouer avec Btrfs, il faut effectivement avoir des kernels et des btrfs-progs très récents. Avec Archlinux, les kernels sont beaucoup plus récents donc, ça me semble moins risqué.

Sinon, j'avoue que je n'ai pas essayé de lire une vidéo stocké sur le SSD en Btrfs (j'utilisais essentiellement des vidéos en streaming, partage réseau ou clé USB).

Moi, j'utilise btrfs. Ça permet de fusionner les 2 disques en 1 seul (RAID0) et avec la compression à la volée, ça fait gagner une place non négligeable (et ça en devient même plus rapide car moins d'accès disque et la charge CPU supplémentaire ne me semble pas gênante). Je dois juste avoir une petite partition /boot dans un coin en ext.
Bref, btrfs, c'est l'avenir (et de plus en plus stable).

Malheureusement, le code n'a plus bougé depuis 2010 mais la dernière Bêta fonctionne encore correctement (= compile) avec les versions récentes de KDE4 et de Qt4 (mais le futur KDE 5 devrait l'achever pour de bon).

Je pense qu'aux rayons X, la batterie est noire comme un explosif (contrairement aux autres composants : cf recherche Images laptp + xray). Après, il faut certainement être super attentif à la lecture rayon X pour voir qu'un disque dur est devenu un carré noir.

Je pense qu'ici, IHM est utilisé comme traduction de GUI (Graphical User Interface) qui est effectivement beaucoup plus réducteur.

Faute de pouvoir me déplacer, est-ce que la présentation sera accessible sur le site après la conférence ?

Je confirme que le toolkit Oxygen est également inutilisable avec NX (j'utilise QtCurve qui marche très bien et qui a l'avantage d'avoir son équivalent pour Gtk).
Avec NX, je suis également obligé de lancer KDE (ou toute application Qt) avec : QT_GRAPHICSSYSTEM=native
Cela force les applis Qt à passer par X11 pour le rendu (au lieu de faire le rendu en interne et de filer les buffers à Xorg/NX ce qui fait saturer la liaison réseau).

C'est également pour cette raison que je suis sceptique sur le fait d'avoir NX + Wayland (car si j'ai bien compris, dans Wayland, chaque application s'occupe du rendu de sa fenêtre et tout se fait en affichant des buffers graphiques).

Alors, ça ne répond pas vraiment au cas des liseuses, mais pour les appareils sous Android, il existe une application permettant de télécharger les articles et de les lire offline :
https://play.google.com/store/apps/details?id=fr.gaulupeau.apps.InThePoche

Le but de Buildroot est justement de tout cross-compiler sur la machine hôte.

Sur Qt5, il existe également ce livre en cours de rédaction qui aborde les mêmes sujets :
http://qmlbook.org/index.html

Effectivement, ownCloud est une bonne brique de base. Le problème, ce sont les clients au-dessus : le client Android est ridicule (très limité et ne fonctionne pas).
Ce que tout le monde souhaiterait : remplacer entièrement un backend Google pour son agenda, ses mails, ses sauvegardes, sa musique, ses adresses sur ownCloud. OwnCloud permet tout ça. Mais trouver des clients viables pour Android, c'est le parcours du combattant !
Donc, je pense que le développement de ownCloud a atteint un palier : la moteur est prêt, il ne reste qu'à concevoir ce qui va autour.

Certes, d'après ce que tu dis, ça a l'air bien mais elle est où la doc ? Ça s'installe et s'utilise comment ?

J'ai également rapidement testé. Cette version tente bien d'associer des visages entre eux mais c'est très, très loin de ce qu'arrive à faire Picasa : beaucoup de visages non associés et beaucoup d'erreurs. Je ne sais pas du tout s'il y a un mécanisme d'apprentissage (sur Picasa, je suppose qu'il y a en a un) : j'ai plutôt l'impression qu'il y a un seuil de ressemblance à franchir.
Mais je pense que le domaine de la reconnaissance faciale est très complexe et qu'il doit être couvert de brevets.

Ce qui est ennuyeux également avec la Raspberry Pi, c'est que l'on peut faire beaucoup de choses mais rien est standard : si j'ai bien suivi, l'accélération 2D n'est pas standard, on ne peut pas utiliser GStreamer pour décoder de la vidéo en hardware [1], V4L2 n'est pas supporté [2] par le module caméra qu'ils viennent de mettre en vente (donc, aucun support avec la plupart des applications courantes).

[1] http://elinux.org/Omxplayer
[2] http://blog.nicolargo.com/2013/05/test-de-la-camera-raspberry-pi-5m.html

Et surtout, y aura t-il un équivalent à FreeNX/Technologie_NX permettant de se connecter à des machines à distance avec des lignes bas débit ?
Peut-être une intégration du procole SPICE  ?

Il devait penser à un système GNU/Linux et je ne pense pas qu'Android soit un système GNU/Linux… A part le noyau, ça n'a rien en commun !

Ici, le JavaScript est utilisé en complément du C++ : on peut développer des applications en pure C++, pure QML et C++/QML.
Je pense qu'il a été choisi de fait qu'il est accessible, répandu et utilisé par de très nombreux développeurs (et il y avait déjà un moteur Javascript pour le moteur Webkit déjà intégré à Qt).

Il n'y a pas que sur les téléphones qu'il y a des écrans tactiles…

Par contre, je viens de voir que ma Fedora 16 ne propose pas de paquet. Et l'ajout du dépôt RPM du site x2go génère déjà plein de conflits (car semble fournir des versions particulières de certains paquets Python), avant même d'avoir tenté d'installer le client…

Moi, j'utilise FreeNX sur mon PC perso (avec Gentoo) et c'est également ce que j'ai déployé au boulot (sur Fedora). Au niveau performance, ça marche bien. Le client NX officiel pour Windows marche bien et est facile à installer pour les utilisateurs.
Ensuite, il y a toujours des petits problèmes (connexion initiale qui échoue plusieurs fois avant d'arriver à passer [correction avec un sleep dans nxnode], faut croiser les doigts lors d'un "resume" de session et quelques crashs du serveur distant sporadiquement [mais au cours des derniers mois, ça s'est bizarrement calmé]). Bref, avec l'habitude et l'expérience, je m'en sortais et j'en étais satisfait.
Mais c'est vrai que j'attends depuis 5-6 ans une solution un peu plus maintenue et plus fiable. Je connaissais x2go de nom mais j'ai eu vraiment peur de me lancer dans son installation (ayant peur de revivre le calvaire de ma première installation FreeNX).

A la place de KMyMoney, j'aurais cité Skrooge surtout pour les vastes possibilités de génération de graphique :
http://skrooge.org/

C'est nettement mieux que ça n'a été. De plus, depuis quelque temps, Kdenlive est capable de récupérer le projet en cas de crash. Dernièrement, j'avais systématique des crashs quand j'essayais de stabiliser des clips vidéos HD (mais j'étais sur des versions de développement et je n'ai jamais su si ça venait de MLT ou Kdenlive).
Donc, ce sont plus des bugs de disfonctionnement que des crash qui restent (bien que je dois justement voir comment ça a changé dans cette version).

En tout cas, ça va dans le bon sens, c'est très intuitif, performant et nettement au dessus des alternatives libres.