wismerhill a écrit 2603 commentaires

Des paquets pour mandriva 2009.1 et 2009.0 sont disponibles via les miroir de KDE:
http://download.kde.org/download.php
Ce sont des paquets non officiels, mais fait par quelqu'un de chez mandriva à partir des paquets actuels de la cooker.
Je les ai installé sur ma 2009.1 et ça fonctionne bien, le système semble plus rapide et j'ai pu constater la disparition de certains bugs d'affichage. (et bien sur plein de nouvelles choses)

Non, juste un bazar :-)

Ben, voici un exemple:
http://www.expansys.fr/d.aspx?i=156658
Les récepteurs basés sur un chipset sirf stat III annoncent tous un cold start en dessous de la minute.

Pourtant des récepteurs récents multi-canaux annoncent des cold-fix de moins d'une minute, et des hot start de quelques secondes.

visiblement grub se base sur l'ordonnancement du bios (que je peux changer à la main, par contre je n'ai toujours pas trouvé le bon ordre...), mais le système se base sur autre chose.

Oui, Linux a son propre code de détection des périphériques de stockage (ce qui permet notamment d'utiliser des disques que le BIOS ne voit pas), et donc il va ignorer une éventuelle réorganisation qui serait faite au niveau du BIOS.
GRUB étant forcément plus minimaliste va utiliser les fonctions disponibles du BIOS.

Si tu veux éviter ce problème il ne faut pas réorganiser l'ordre des disques dans le BIOS, ou continuer à modifier la config de GRUB à la main.

Ben en fait on en sait rien, vu qu'ils ne disent pas quel est le composant GPS utilisé.
Par exemple sur le N810 c'est un récepteur GPS qui a été choisi sur base de sa faible consommation et pas de ses performances, et je peux te dire d'expérience qu'il n'est pas formidable. Sans le A-GPS un fix peut prendre plusieurs dizaines de minutes et la position saute parfois de plusieurs dizaines de mètres sans raison. Pour enregistrer les tracés pour openstreetmap c'est pas génial ;-)

Il y avait une suite sur maemo.org qui permettait de gérer ses contacts, rendez-vous, etc... de manière intégrée et interopérable je pense.

C'est GPE ( http://gpe.handhelds.org/ et http://gpe.linuxtogo.org/ ) qui est une suite PIM portée sur plusieurs environnements de type PDA.

Dans le portage maemo il y a les modules calendar, contacts, todos, filemanager, timesheet et une applet spécifique à maemo pour afficher sur le bureau un résumé des calendriers et todos.

La synchronisation est possible avec opensync.

C'était aussi le cas pour l'installation de base de mon N810, mais après la mise à jour (par firmware) vers la version 4 (diablo) de la plateforme les mises à jour se font par les paquets.

Là dessus, Google met une grosse claque à tout le monde : les cellulaires dotés d' Android soient tous capables de mettre à jour leur système :

Sur ce point, la plateforme maemo est tout à fait compétitive, le système de base est une debian arm et on fait les mises à jour avec apt (directement en ligne de commande quand je veux contrôler ce qu'il fait, sinon avec l'interface fournie) et on peut ajouter plein de dépôt non officiels (en particulier ceux de maemo.org).

- enfin téléphone !

Moi c'est justement ce qui m'avait fait acheter un N810: ce n'est pas un téléphone.
S'ils ne sortent plus de "simple" tablettes internet sous maemo, je crois que je vais garder mon N810 longtemps.

Quelle idée aussi d'aller appuyer sur un écran tactile, les gens cherchent vraiment les problèmes...

Justement, ça peut être une façon de détourner l'attention de la véritable attaque.

Dans ce que tu proposes, on est obligé de lire chacun des boutons un par un avec un texte différent par contexte.
Dans le cas des textes de boutons génériques, on a juste le texte de la question à lire, les boutons étant identifiables sans difficulté.

Ce qui n'est pas à priori plus long, car le message est souvent beaucoup plus long que les intitulés des boutons, et s'il ne l'est pas c'est qu'on a déplacé son contenu vers les boutons.

Personnellement, je préfère très largement la deuxième solution, et je ne clique pas oui sans réfléchir...

Tu es une exception.

Justement (cf mon message un peu plus haut) le problème est que ça parait plus clair, et que donc on clique oui sans réfléchir.

Et encore, d'autres l'ont appelé six (enfin, en chiffre romains).

Ouais, avec des feuilles et un D20.

Je le supposais un peu, c'est plus pour le fun que j'ai répondu en prenant volontairement une mauvaise interprétation de ton message ;-)

Donc tu ne veux pas que les gens aie la possibilité de fermer sans enregistrer?
Vaut mieux être sur de vouloir conserver son document dans l'état où il est au moment ou on ferme, vu qu'on n'a même plus l'option d'annuler...

Si l'utilisateur ne lit pas les messages, il ne comprendra surement pas pourquoi on lui propose d'enregistrer quoi que ce soit alors qu'il vient de faire fichier/quitter

Mais s'il ne comprend pas, il est alors obligé de lire le message.
Alors qu'avec un oui/non il suppose que l'ordinateur lui demande de confirmer ce qu'il est en train de faire, ce à quoi il va bien sur répondre par oui.
Le problème est donc dans ce cas qu'il croit comprendre ce qu'on lui demande.

Je l'ai vu tellement de fois (et ça m'est même déjà arrivé), c'est évident qu'à la vitesse où les gens cliquent sur le oui ils n'ont eu que le temps de repérer ce bouton pour le cibler.

Ce que tu peux faire, c'est définir une API pour permettre à l'application de demander au gestionnaire de fenêtres d'afficher pour elle n onglets plutôt qu'un seul, et ensuite l'application pourrait recevoir (typiquement via dbus) notification que l'utilisateur a cliqué sur un de ses onglets.

C'est un peu le même principe que le system tray où une API a été définie (par freedesktop) pour qu'un programme quelconque puisse fournir une icône qui s'affiche dans un endroit indépendant de l'application et qui permet d'interagir avec celle-ci.

Il parlait du temps de démarrage d'un programme, pas du système.

Franchement, KDE à chaque version majeure de QT c'est la même histoire, faut qu'il recodent tout de zéro la moitié des applis, et jettent à la poubelles celles d'avant qui marchaient bien.

Pour la transition KDE1 -> KDE2 c'était effectivement le cas.
Par contre la transition KDE2 -> KDE3 était beaucoup plus light, la compatibilité binaire était cassée, mais le portage était assez simple car les API KDE n'avaient pas fait de modification extraordinaire.

Ça aurait pu être le cas pour KDE4, mais ils ont décidé que tant qu'à faire une transition incompatible ils allaient repenser tous les aspect de la plateforme sur base de toute l'expérience accumulée.
Et il fallait bien que des choses soient réécrites, par exemple à cause de arts qui n'était plus maintenu depuis des années. Ça a donné phonon qui a même été inclus en amont dans qt.

Quant au portage des applications, même lors de la transition à KDE3 certains programmes ont été perdus. Si plus personne ne les maintient et que personne ne veut faire le portage ben l'appli est morte. Tu peut toujours garder les bibliothèques nécessaires à les faire fonctionner (c'est ce qui est fait dans les périodes de transitions entre des versions majeures, pas que pour KDE).

Ben, vu que j'utilise encore le kaffeine de KDE3 je m'en fous un peu de phonon (d'autant que quand c'est pas kaffeine c'est mplayer).

et à part ça, j'ai testé la 1.0RC1 et c'est en très bonne voie, il me reconnais le périphérique DVB et le scanne sans problème.

voire pire, certaines fenêtres ne rentraient même pas dans l'écran et ne pouvait pas être redimensionnées plus petites, et étaient donc inutiles, car les boutons "ok"/"annuler" en bas de la fenêtre étaient cachés

Mais n'importe quel WM correct te permettra, via certains raccourcis claviers, de déplacer la fenêtre sans avoir besoin de la barre de titre.
Par exemple avec kwin Alt+ clic n'importe où dans la fenêtre pour la déplacer.

Ils fonctionnent toujours très bien, je suis sur un bureau KDE 4.2 avec kaffeine 0.8.7 (KDE3) qui fonctionne sans problème.