gpe a écrit 799 commentaires

en quoi le connecteur d'Outlook est-il indispensable?
Dans ma boîte on est passé du jour au lendemain de Lotus à Outlook et franchement je ne vois pas l'intérêt d'Outlook.
Donc si tu passes à OBM pourquoi vouloir garder Outlook?

Le problème c'est aussi le pourcentage de pilote pour les matos sortis dans les 12 derniers mois...

Je n'ai pas regardé mais je doute qu'Android inclut la stack GSM, non? Donc pas de soucis à ce niveau.

PDFEdit! Ça fonctionne vraiment ce logiciel? A part obtenir un crash je n'ai jamais réussi à en faire quelque chose...

Je ne connais pas l'état des relations entre Linux et Intel mais en règle générale quand on est dans une relation d'estime et de confiance on peut se permettre de tout se dire, non?

manque le lien pour compiz, non?

dcraw n'est pas le problème en tant que tel, c'est un bon moteur de dérawtisation d'ailleurs beaucoup de logiciels commerciaux se basent sur lui. Mais tout seul il n'est franchement pas pratique d'usage et nécessite pas mal de travail avant d'obtenir une image fianle et aucune surcouche finalisée n'a vu le jour actuellement en tant que logiciel libre.

La version 4 offrait un undo global (suppression de toute les modifs).
La version 5 qui va sortir avant la fin de l'année offrira un vrai undo complet.
La version 5 n'est pas la prolongation de la 4 mais une réécriture complète du logiciel qui inclura des fonctions de cataloguages, selon plusieurs mode, de retouche avancée, etc, etc
Son concurrent direct est Lightroom.

Le 40D c'est seulement 14 bits pas 48 ...

Pas d'accord, quand ta source est en plus de 8 bits, Raw des APN qui sont entre 10 et 16 bits, il faut bien un traitement 32 bits pour les traiter correctement et ressortir en 16 bits, non?

s/faut/faux/

C'est faut. Il faudrait que je retrouve le lien où la démonstration est clairement faite que même pour traiter un jpeg 8 bits il est bénéfique de d'abord passer en 16 bits avant de faire des traitements.
Si au final tu veux avoir un 8 bits réel tu es obligé de traiter au moins en 16 bits sinon tu auras trop de pertes dans les traitements.
De plus tous les reflex actuels font du 12 bits pertinents au minimum. Les scanners également.

Quant au rendu sur écran même s'il est limité sur beaucoup d'écrans actuellement ça progresse et des écrans dépassant les 8 bits arrivent. De plus tout le monde ne se contente pas du rendu sur écran mais beaucoup de photographes font du tirage photo qui en fonction du papier permet d'exploiter pleinement une image avec plus de 8 bits.

Pas si j'en crois l'avertissement qui suit sur la page que tu cites:
Il est important de noter que Gimp dans son ensemble reste 8-bits jusqu'à ce que GEGL couvre l'ensemble de l'application.

D'ailleurs si tu essaies d'ouvrir un tiff 16 bits Gimp 2.6 t'avertit qu'il ne le gère pas et qu'il va le convertir en 8 bits...

Et la gestion des images avec une profondeur de couleur supérieure à 8 bits c'est pour quand? La 2.8 ou la 3.0?
Perso (et je ne pense pas être le seul) c'est l'évolution majeure de Gimp que j'attends et qui fera que je l'utiliserai régulièrement.
D'ailleurs quand tu annonces la sortie de la 2.6 sur un forum photo la première question qui arrive c'est: "Est-ce qu'il gère enfin le 16 bits?" ...

Tu dis les développeurs ont donc adopté le célèbre adage en cours dans le logiciel libre « publiez tôt, publiez souvent »

Est-ce qu'un rythme fixe a été adopté (genre tous les 6 mois) ou est-ce au petit bonheur la change?

Dans la release note ils disent:
- and a tentative integration of GEGL, the graph based image processing library that will eventually bring high bit-depth and non-destructive editing to GIMP.

et plus loin

- Important progress towards high bit-depth and non-destructive editing in GIMP has been made. Most color operations in GIMP are now ported to the powerful graph based image processing framework GEGL, meaning that the interal processing is being done in 32bit floating point linear light RGBA. By default the legacy 8bit code paths are still used, but a curious user can turn on the use of GEGL for the color operations with Colors / Use GEGL.

Bref ce n'est franchement pas clair leur histoire...

Ah oui c'est vrai ça ne marche pas pour "enregistrer sous", par contre pour "ouvrir" ça fonctionne...

Ben chez moi il fonctionne parfaitement le CTRL-L depuis Firefox...

Il ne me semble que quelqu'un ait dit le contraire.
On parlait accessibilité du bureau et on nous répond que k3b, Amarok, koffice, etc. sont très bien. C'est certainement vrai mais ça n'a rien à voir avec l'accessibilité du bureau c'est tout!

Ah oui je viens d'essayer ça marche effectivement mais je n'en vois toujours pas l'intérêt ???

Et qui t'as dit que k3b et Amarok n'étaient pas de bons logiciels? Pas moi en tout cas...

C'est sur que le ALT+clic droit+déplacement c'est la fonctionnalité indispensable que tout le monde utilise toutes les 30 sec! Combien d'utilisateurs de kde savent que ça existe?

Pour les débits dans nautilus c'est présent depuis la version 2.22 si je ne m'abuse?

Enfin bon si c'est juste ça qui te motive pour KDE, t'es vraiment dans le micro détail!

De plus en plus fort les kde fanboy! D'habitude vous attendez le 3 ou 4e message pour troller. ;)

Sinon je ne vois pas le rapport entre k3b, amarok, kmail, koffice et le bureau?

C'est bon ça marche maintenant. Coban avait installé wxpython 2.8 mais pour qu'il soit pris en compte il a fallu que je relance ma session.

Quand j'essaie de lancer coban sur une debian testing j'obtiens:

Traceback (most recent call last):
File "coban.py", line 39, in
from wx.lib.wordwrap import wordwrap
ImportError: No module named wordwrap


Je suppose qu'il doit manquer une dépendance sur quelque chose, mais quoi?

Un glissé déposer intuitif (apparemment cela le fait avec ff nautilus./bureau) et une ouverture automatique des dossiers par glissé déposé

avec nautilus 2.20 j'ai l'ouverture auto, je doute donc que ça ait été retiré dans la 2.24, non?

Pour le reste je n'ai pas compris ce que tu voulais dire par glissé déposé intuitif?