Sortie de KDE 4.5

Posté par (page perso) . Modéré par Mouns.
Tags :
32
12
août
2010
KDE
Ce 10 août, KDE 4.5 est disponible au téléchargement. Cette version n'apporte pas de grands changements mais plutôt une amélioration de l'existant. En effet, cette version corrige plus de 16 000 bugs et améliore la réactivité du système.

Le grand absent de cette version est Kontact 4.5 qui devait arriver avec le portage de Akonadi, les développeurs ont préféré retarder la sortie afin d'éviter la perte de courriels importants. Il y a quand même quelques nouveautés comme l'intégration de Webkit, l'amélioration de la zone de notification ou, encore, la détermination d'itinéraire avec Marble. Nouveautés dans KDE Development Platform

  • WebKit peut désormais être utilisé à la place de KHTML par les applications KDE tout en offrant autant d'intégration que KHTML.
  • KHTML supporte les requêtes XPath.
  • Un nouvel ordonnanceur HTTP (via le KIO HTTP) permet d'accélérer les requêtes concurrentes afin d'accélérer le temps de téléchargement total. Ceci permet à KHTML et WebKit de finir le rendu de la page plus vite.
  • Les espaces de travail de Plasma peuvent être configurés par JavaScript, ceci permet aux administrateurs réseau de gérer plus facilement la configuration des postes de travail des utilisateurs.
  • Un système de cache pour les applications, KSharedDataCache, a été introduit, il est dès à présent utilisé pour les icônes et montre un gain de temps sensible.
  • Phonon, la bibliothèque multimedia, utilise optionnellement PulseAudio.
  • Un binding pour Perl a été ajouté et la gestion de Ruby s'est nettement améliorée.
  • Les API pour les applications utilisant KatePart ont été étendues pour offrir plus de fonctionnalités.
Pour le futur, il est prévu de rendre KDE plus utilisable pour les système tels que les téléphone mobile en sélectionnant un ensemble réduit de fonctionnalités à la compilation pour diminuer l'utilisation de la mémoire. Des versions mobile de Kontact, KOffice et Plasma vont être développées dans ce sens. Une autre direction d'amélioration est d'augmenter le nombre de périphériques Bluetooth pris en charge par BlueDevil.

Nouveautés dans Plasma

  • La zone de notification a été visuellement retravaillée, des icônes monochromes permettent plus de clarté et de consistance. Les indicateurs pour les opérations de longue durée sont maintenant directement intégrés au widget et l'affichage des notifications par catégorie et la mise en file ont été retravaillés. Les notifications des widget Plasma partagés sur le réseau peuvent être affichées comme les notification locales.
  • KWin, le gestionnaire de fenêtre, peut désormais placer les fenêtre sur le bureau sans qu'elles se recouvrent en utilisant les algorithmes de tiling. Il est aussi possible de déplacer des fenêtre (écrites en Qt) en sélectionnant une zone vide de la fenêtre. Les performances des effets des fenêtres ont aussi été améliorées.
  • Un gestionnaire d'activité a été introduit pour gérer les activités de Plasma. Les activités sont plus faciles à gérer et la séparation des activité en tâches différentes est plus évidente.
  • Plasma Netbook la version de Plasma pour les petits écran continue de s'améliorer.
  • Les calendriers japonnais, thaï et taiwanais sont désormais supportés.
  • Les applications Plasma peuvent être utilisées comme applications à part entière via plasma-windowed.
  • Les distributeurs et les administrateurs peuvent définir une blacklist d'effets visuels afin d'éviter ceux qui posent problème avec une configuration donnée.
Pour le futur, il est prévu d'étendre le concept d'activité de Plasma afin, notamment de grouper les applications semblables entre-elles, les effets de flou vont être utilisé pour faire ressortir les informations importantes et un espace de travail va être créé pour les media center et les téléphones mobile (le premier appel a été passé durant l'Akademy en utilisant Plasma Mobile).

Nouveautés dans KDE Applications

  • Marble peut déterminer un itinéraire hors ligne en utilisant les données de OpenStreetMap et OpenRouteService.
  • Parley a une nouvelle interface d'exercices et gère la conjugaison.
  • La liste d'Adblock dans Konqueror peut être automatiquement mise à jour afin d'améliorer son efficacité.
  • Gwenview garde désormais toutes les informations EXIF en cas de manipulation d'image.
  • # Tant qu'on est dans KDE

    Posté par (page perso) . Évalué à 10.

    2 petites infos:

    - Quanta Plus est sorti de sa léthargie et annonce son grand retour (pour 2011 ?): http://milianw.de/blog/quanta-gsoc-midterm-evaluation et http://milianw.de/blog/final-days-of-quanta-gsoc-2010
    - La détection de visage arrive dans Digikam, et via une bibliothèque afin d'être utilisée dans d'autre projets: http://adityabhatt.wordpress.com/2010/08/10/digikam-gsoc-fac(...)

    2 projets du GSoC

    Dans les fonctionnalités annoncées depuis longtemps, j'aimerais beaucoup voir apparaître la détection de langage: https://bugs.kde.org/show_bug.cgi?id=66516
  • # Mise à jour sur Mandriva

    Posté par . Évalué à -7.

    Vu l'état catastrophique de kde4 installé d'origine tant sur Mandriva que sur Ubuntu (ralentissements monstrueux, etc.), j'ai tenté d'urgence la mise à jour sur Mandriva.

    J'ai fait pointer les dépôts pour mise à jour sur les rpm Mandriva.
    Ça a mis à jour quelques centaines de paquets sans message d'erreur.

    Depuis, le mode graphique ne démarre plus.

    C'est normal, chef ? (c'est peut-être le nouveau KDE qui est en mode texte pur ?)
    • [^] # Re: Mise à jour sur Mandriva

      Posté par (page perso) . Évalué à 3.

      Oui c'est la nouvelle version de KDE, il font un retour au source pour être sur d'avoir les meilleurs performances.
    • [^] # Re: Mise à jour sur Mandriva

      Posté par . Évalué à 3.

      Tu devrais peut-être t'adresser au bon endroit, non ?

      http://forum.mandriva.com/viewtopic.php?t=130555
    • [^] # Re: Mise à jour sur Mandriva

      Posté par (page perso) . Évalué à 1.

      J'ai noté aussi de grosse lenteur sous linux notamment sur certaine configuration.

      Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Mise à jour sur Mandriva

      Posté par . Évalué à 4.

      Sur Ubuntu, je veux bien croire que ce ne soit pas la meilleure implémentation vu que la distro est centrée sur Gnome. Mais pour Mandriva cela me paraît bizarre. Utilisant actuellement une Mandriva et une arch, je n'ai pas remarqué de lenteurs. Au contraire, j'aurais tendance à dire que la fluidité augmente avec le nombre de version.

      Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque

  • # Activités

    Posté par . Évalué à 2.

    Le gros truc révolutonnaire qui déchire tout de JDE4 est supposé être les fameuses activités.

    Maintenant, j'ai essayé (honnêtement) d'utiliser ça il y a quelque temps. La doc était plus que disparate, et les quelques manipulations que j'ai pu effectuer ne m'ont pas permis de déterminer ce qu'on peut en faire, comment le faire ni pourquoi.

    Après, j'ai eu l'impression qu'il y avait un mélange dans ma tête entre ces activités, le bureau et l'écran. Comment je mélange tout ça ? Je suis en permanence en double écran avec 6 bureau, et j'ai l'impression que ça rajoute juste une couche virtuelle au dessus de tout ça.

    Cela dit, ces essais sont assez anciens. Ca se trouve c'était le tout début et les choses n'étaient pas finies et la doc n'existait pas. Il y a des explications plus claires maintenant ?
    • [^] # Re: Activités

      Posté par . Évalué à 1.

      Cela a ENORMEMENT change avec cette version. C'est enfin utilisable. Par contre je trouve dommage que l'on puisse pas avoir deux activite desktop/netbook c'est soit l'un soit l'autre.
      • [^] # Re: Activités

        Posté par . Évalué à 7.

        > Cela a ENORMEMENT change avec cette version. C'est enfin utilisable.

        ce qu'il y a de mignon avec KDE 4, c'est qu'on nous fait le coup à chaque sortie de KDE 4.n+1
        • [^] # Re: Activités

          Posté par . Évalué à 3.

          Oui ben la on parle d'un point particulier: les activites et si tu pretends que la facon de gerer les activites n'a pas change entre la version 4.4 et 4.5 cela montre juste que tu n'as pas essaye cette derniere version. Pour info dans la version 4.4 cela passait par la cacahuette.
          • [^] # Re: Activités

            Posté par . Évalué à 9.

            ça doit faire mal :(
            • [^] # Re: Activités

              Posté par . Évalué à 4.

              Ca fait moins mal avec chaque sortie de KDE 4.n+1.
              Quand tu ne sens plus la douleur, tu as l'impression que c'est enfin plaisant et tu cours l'écrire sur linuxfr.
              Et là tu te prends un coup de Gniarf. A chaque sortie de KDE 4.n+1.

              KDE Sado Cacahouette 4
              Vous en redemanderez!
        • [^] # Re: Activités

          Posté par (page perso) . Évalué à 5.

          Et oui, chaque fonctionnalité est introduite dans une version n et stabilisée dans une version n+1. Sachant que ce sont les retours des utilisateurs qui permettent principalement de stabiliser, ça semble logique.
          C'est aussi la philosophie open-source "publier vite, publier souvent".

          Pas choquant, quoi.
    • [^] # Re: Activités

      Posté par . Évalué à 3.

      En même temps, avec 2 écrans et 6 bureaux, la plus-value des activités doit pas être énorme, non?

      Je voyais plutôt l'utilisation des activités lorsqu'on n'a qu'un seul écran et qu'on fait plusieurs utilisations différentes de sa machine avec des besoins assez différents.
      • [^] # Re: Activités

        Posté par . Évalué à 7.

        PS : Ah, et j'ai oublié....

        JDE, c'est l'implémentation en java de KDE?
        • [^] # Re: Activités

          Posté par . Évalué à 10.

          Oui, mais ça marche mieux sur une Jebian avec un noyau Jinux.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Activités

            Posté par . Évalué à 2.

            Je pense que tu veux dire Sebian et Kinux (décalage à gauche d'une lettre sur un clavier azerty).
        • [^] # Re: Activités

          Posté par . Évalué à 4.

          Oui, ce qui explique aussi le commentaire précédent sur la lenteur de KDE dans Mandriva: il s'agit bien de JDE.

          Mais rassurez-vous, tout va bientôt s'arranger:
          La prochaine version de KDE par Mandriva sera plutôt écrite en Lisp.

          Donc, bientôt, une Mandriva Emacs adaptée aux débutants grâce à son plugin KDE! \o/
      • [^] # Re: Activités

        Posté par . Évalué à 1.

        OK, si je comprends bien, les activités, c'est une manière de faire ce que ej fais déjà avec les bureau et les écrans : je répartis les applications sur les bureaux en fonctions de thématiques.

        Quand je parle des écrans, c'est parce que la seule chose que je sois arrivé à faire avec les activités, c'est mettre un fond d'écran différent sur les bureaux :)

        Pour JDE4 : hé oh, ça va hein !
        • [^] # Re: Activités

          Posté par . Évalué à 2.

          non maintenant tu peux avoir la vue de dossier, la vue de bureau, journal d'activite, recherche et lancement (le truc pour les netbook) et bientot je pense que l'on aura plus de choix comme un centre multimedia par exemple.
  • # rekonq vs Konqueror-Webkit ?

    Posté par . Évalué à 3.

    J'avais entendu parler de rekonq basé sur Webkit, l'annonce parle Konqueror utilisant Webkit, mmmh, quelqu'un saurait-il ce que ça change pour l'utilisateur?

    Y a t'il une association 'flexible' entre les onglets et les processus comme Chrome le permet (plusieurs possibilités: un processus par onglet, par site web, pour tous les sites, etc.)?
    • [^] # Re: rekonq vs Konqueror-Webkit ?

      Posté par (page perso) . Évalué à 2.

      Le principe du "un processus par onglet" a été implementé dans webkit 2, qui n'est à mon avis pas encore intégré dans KDE.
      • [^] # Re: rekonq vs Konqueror-Webkit ?

        Posté par . Évalué à 2.

        D'ailleurs Webkit 2 est-il disponible sous GNU/Linux / Unix ? Il me semble que seuls Mac OS et Windows y avaient eu droit, repoussant les autres systèmes à "plus tard". En tout cas, il n'est pas disponible dans une version stable sous Arch.
    • [^] # Re: rekonq vs Konqueror-Webkit ?

      Posté par . Évalué à 3.

      L'intérêt est d'avoir le choix, les seuls points commun de Konqueror et de reKonq étant les librairies KDE et Webkit. Pour l'interface, ils prennent des voies complètement différentes.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: rekonq vs Konqueror-Webkit ?

        Posté par (page perso) . Évalué à 4.

        il y a d'autres points communs:
        partager les librairies KDE permet d'avoir les même signets, le même historique, le même portefeuille de mots de passe, etc.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # kdepim non inclu

    Posté par . Évalué à 2.

    pour compléter l'info sur kontact non présent dans kde 4.5, c'est en fait tout kdepim qui n'a pas été inclu.
    La raison principale est le portage de kmail vers akonadi, qui est à l'heure actuelle encore assez expérimental (j'en ai une version compilée depuis les sources, et même pour juste rapporter des bugs, c'est très limite)
    D'après l'avis personnel que je me fait de cette version, je serais assez surpris si une version stable de kmail 2 sortait avant kde 4.6
    Mais en tout cas pour l'instant, la suite kdepim de kde 4.4 est parfaitement utilisable, et elle a même reçu quelques corrections de bogues.
    • [^] # Re: kdepim non inclu

      Posté par . Évalué à 1.

      Il me semble que KMail 2.0 avait déjà été reporté plusieurs fois et devait arriver avec KDE 4.5.

      C'est dommage, Akonadi devait être un des piliers de KDE en tant que bureau sémantique.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: kdepim non inclu

        Posté par . Évalué à 2.

        KMail 2.0 arrivera avec KDE 4.5.1 normalement...
      • [^] # Re: kdepim non inclu

        Posté par . Évalué à 4.

        le portage de kmail à akonadi a en effet été reporté jusqu'à cette version. Principalement pour laisser le temps à akonadi de mûrir un peu plus en terme de stabilité et performances et de compléter les fonctionnalités qui lui manquaient. Le travail a été plus important que prévu, et comme souvent, le manque de développeur à fait que cela a été beaucoup plus long que prévu.

        Le portage en lui même à finalement commencé un peu avant la sortie de kde 4.4 mais n'est pas complet/fonctionnel/utilisable à ce jour. Donc l'équipe kdepim à décidé de ne pas inclure kdepim 4.5 avec kde sc 4.5

        C'est vrai que c'est dommage que ce soit si long, surtout que pour la première version, à mon avis, on se rendra surtout compte des régressions en terme de fonctionnalité, d'ergonomie et de performances par rapport à la version sans akonadi, et ça va râler.
        Mais je pense que l'architecture globale de akonadi est un pas dans la bonne direction et qu'une fois bien stabilisé, le développement pourra reprendre de plus belle pour corriger les lacunes et améliorer des tas de choses qu'il était très difficile de faire avant :)
      • [^] # Re: kdepim non inclu

        Posté par . Évalué à 2.

        Le bureau sémantique c'est nepomuk, akonadi sert au stockage des informations de PIM.
        • [^] # Re: kdepim non inclu

          Posté par . Évalué à 2.

          En effet, c'était un raccourci.

          Néanmoins, la PIM fait partie du bureau sémantique, et Nepomuk aura besoin de piocher dans les informations d'Akonadi pour faire une partie de son boulot. Donc ça reste un pan encore manquant.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: kdepim non inclu

      Posté par . Évalué à 5.

      Ils vont arriver à détacher kmail de mysql ou pas ?

      Quand j'ai vu qu'il fallait un mysql installé (et e exécution) pour lire ses mails, hop poubelle.

      Y a pas besoin d'un SGBD pour stocker des mails, enfin !

      C'est dommage, j'aimais bien kmail...
      • [^] # Re: kdepim non inclu

        Posté par . Évalué à 10.

        il y a besoin d'un moyen de stocker et de récupérer des infos sur le disque pour un client mail.
        Les développeurs de kmail (ou plutôt d'akonadi) ont décidé (à tord ou à raison, ça peut se discuter) que les concepteurs et développeurs d'un SGBD sont mieux placés pour fournir une solution plus efficace pour stocker et gérer les mails et informations associés sur disque que des développeurs de logiciels quelconques.
        Maintenant je ne vois pas en quoi le fait que kmail ait besoin de mysql le rende moins bien, tu ne sais absolument pas ce que mysql rempli comme besoins dans kmail, il pourrait très bien remplacer du code qui était plus volumineux, moins performant et plus bogué mais directement inclus dans kmail, et du coup tu ne t'en rendais pas compte.

        Teste le toi même et vois la différence, et après tu pourras venir te plaindre chiffres et expérience personnelle à l'appuis de ce qui ne te conviens pas.

        PS: actuellement, au niveau des performances c'est effectivement moins bon qu'en 4.4, mais mysql ne semble pas être le fautif, et j'ai vu plusieurs mail des développeurs qui en parlaient et qui annoncent qu'ils vont bosser pour améliorer ça.
        • [^] # Re: kdepim non inclu

          Posté par . Évalué à 3.

          en particulier ca pourrait remplacer du sqlite qui serait plus lent (ou monothread, enfin en accès exclusif aux tables), plus plantogène et exploserait tout simplement sur de gros volumes

          tout dépend de ta volumétrie de mails donc de tes usages, je suppose.
          • [^] # Re: kdepim non inclu

            Posté par (page perso) . Évalué à 7.

            Il n'est donc plus possible d'utiliser le format maildir ou mailbox (qui était très pratique, surtout au niveau sauvegarde) ?
            • [^] # Re: kdepim non inclu

              Posté par (page perso) . Évalué à 5.

              Bien sûr que si.
              Il y a une grande confusion dans les commentaires là. Voilà une explication pour tout le monde:

              Akonadi n'est pas un agent de stockage pour vos courriels, vos carnets d'adresse, vos agendas, etc. C'est un cache. Ils s'occupe de récupérer (ou d'envoyer) les informations et méta-informations, que ce soit sur le grand Ternet ou dans votre disque dur, ensuite il les met en cache dans sa base de données (mySQL ou postgreSQL actuellement) pour en faciliter l'accès aux applications.
              Cette structure permet des accès concurrents (plusieurs application sur les mêmes données). Elle permet aussi à l'application de s'affranchir de la gestion des données, c'est ainsi que la première version fonctionnelle de Mailody a été écrite en 10 minutes.
              Enfin le couplet sur la base de données me fait un peu rigoler: on s'énerve tous dès qu'une appli a besoin d'une ressource supplémentaire, mais dites... il y a écrit quoi sur nos babasses? GHz ou MHz? Ram en Mo ou en Go? RPM HD ca commence par 1xxx, 4xxx ou 7xxx (ou plus)? En plus Akonadi utilise un mySQL minimal (ou pas si on veut). Et puis il faut bien que les développeurs s'amusent.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: kdepim non inclu

                Posté par (page perso) . Évalué à 3.

                j'ai oublié de préciser:
                vous pouvez donc toujours stocker vos données en mbox, maildir, ldap, vcard, etc.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: kdepim non inclu

                Posté par . Évalué à 7.

                Utiliser un SGBD simplement pour faire du cache, y a un truc que je n'ai pas du comprendre ?
                Un SGBD nécessite une part d'administration qu'un utilisateur de base ne saura jamais faire (pour rester constant et optimal en terme de perf) ; mais vu la quantité de données à manipuler (relativement nulle vu les capacités du programme), on peut aussi se poser la question de la pertinence de son utilisation.

                Pour enchaîner sur le chapitre des ressources, quitte à faire mon dinosaure, mon pc fixe à la maison est un pentium II 266MHz, avec 600 Mo de RAM. Le disque dur est un vieil IDE , je n'ai pas les RPM en tête, mais ce n'est pas un foudre de guerre.
                Linux tourne dessus depuis plus de 10 ans. Le passage à KDE 3.5 n'a pas été un problème. J'ai même été surpris de voir que ça ne tournait pas trop mal.
                Je serais peut être surpris, lors du passage à KDE 4.x, de voir que tout reste réactif, mais je me pose des questions. C'est bien que les développeurs "s'amusent" comme tu dis, espérons que cela ne se fasse pas au détriment de leur produit ....

                Bon, comme on est vendredi, pour finir, je me contenterai d'un : c'était mieux avant ! :)
                • [^] # Re: kdepim non inclu

                  Posté par (page perso) . Évalué à 6.

                  _Si j'ai bien compris_ les explications d'un des devs Debian, en principe il n'y a pas besoin d'administration, parce que l'utilisation est minimale, et parce que, comme c'est un cache, Akonadi peut effacer et refaire les tables. Quant aux ressources consommées, globalement ça semble plutôt positif - mais bien sûr les développeurs ne se basent que sur notre expérience, c'est à dire sur ce qu'on leur transmet... autrement dit, si tu as une "petite machine" (sans jeu de mot graveleux), il vaut mieux participer aux tests maintenant. Au passage un des devs bosse (bossait?) sur un PIII 450 MHz.

                  Sur ta bécane, qui a 12 ou 13 ans, oui c'est assez puissant pour kde3 (j'en ai une avec 128 Mo de Ram, avec un noyau linux 2.4 c'est très rapide), mais pour le reste? les vidéos, flash, les sons, les jeux récents, les pages web (et dieu sait si ça bouffe de plus en plus!), la reconnaissance faciale, la virtualisation, ... enfin tous ces trucs hype qui nous empêchent de bosser mais qui plaisent à nos femmes. Et même dans les trucs pour bosser: OpenOffice.org 3, SugarCRM, etc. je ne pense pas que ça tourne bien dessus.
                  Et puis rappelle-toi la sortie de Win95, on trouvait normal que ça ne tourne pas sur des XT, ni des 286 (et même les 386 il fallait de la patience).
                  Et enfin, c'est vrai c'est un peu ridicule cette course à l'échalotte, mais d'un autre côté on ne peut pas se plaindre de l'omniprésence de Windows et MacOSX sans proposer d'équivalent, et ça ça bouffe de la puissance.

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: kdepim non inclu

                  Posté par (page perso) . Évalué à 8.

                  Tu ne peux pas en 2010, avec l'évolution de l'informatique, demander aux développeurs de se limiter afin que les softs de maintenant puissent encore tourner sur des machines de 1998.
                  Même les machines légères de maintenant sont plus puissantes, même les téléphones portables ont plus de mémoire.
                  Pour le dinosaure, il ferait un bon terminal X.
                  • [^] # Re: kdepim non inclu

                    Posté par . Évalué à 3.

                    oui mais bon.

                    KDE 4 rame, même sur une machine légère de maintenant. C'est ça le problème.

                    J'ai un ion 330 (processeur atom, 2GB de ram, carte graphique nvidia) et kde4 est franchement inutilisable : très lent et peu réactif (même en activant le preset "machine peu puissante, grand écran", avec pleins de petits bugs d'affichage (j'utilise le driver "nouveau"). A côté gnome est une fusée.
                    • [^] # Re: kdepim non inclu

                      Posté par . Évalué à 2.

                      Si tu utilise le driver nouveau, il faut désactiver les effets de bureau, car la partie 3D de nouveau est encore expérimentale.
                      Sur une carte nvidia, si tu n'utilise pas le driver propriétaire il vaut mieux configurer son bureau "à l'ancienne" avec des fenêtres qui se redessinnent à l'écran sans passer par des buffer opengl.
                      • [^] # Re: kdepim non inclu

                        Posté par . Évalué à 1.

                        Même en désactivant l'ensemble des effets de bureau, ça restait lent chez moi. Aussi bien sur mon eeepc (ce que je peux comprendre) que sur une machine correcte (Core2Duo T8100, 3Go de ram, driver nouveau).

                        C'est un peu le même ressenti que Vista : tout est lent, tout lagge. Ca ne ramait pas vraiment, mais c'était juste un peu trop lent pour être confortable. En revanche, sur mon pc de salon (pentium dual core 2.4Ghz etcarte graphique intel), c'est suffisamment confortable.

                        Je confirme que gnome est une fusée comparativement, sur les deux machines où j'ai fait le test.
                • [^] # Re: kdepim non inclu

                  Posté par . Évalué à 4.

                  "mon pc fixe à la maison est un pentium II 266MHz, avec 600 Mo de RAM."

                  l'objectif de KDE est, entre autre, de proposer un environnement de bureau avec une suite logicielle cohérente, aux fonctionnalités avancées et fonctionnant sur du matériel résonnablement moderne.
                  L'objectif était le même avec kde3, sauf qu'à l'époque, ton matos était raisonnablement moderne, ce n'est plus le cas aujourd'hui.
                  Je pense que demander comme matériel raisonnablement moderne une machine de moins de 6 ans n'est pas abusif, surtout que ce n'est pas le seul environnement de bureau libre et qu'ils n'ont pas sur les épaule le fardeau d'avoir à combler les besoins et envies en terme d'environnement de travail de tous les utilisateurs de logiciels libres.
                • [^] # Re: kdepim non inclu

                  Posté par . Évalué à 3.

                  'mon pc fixe à la maison est un pentium II 266MHz, avec 600 Mo de RAM.'
                  Le seul probleme avec ce genre de vision de l'informatique c'est que une fois que ca tombe en panne il t'est quasi impossible de reparer.
                  Tu vas tomber forcement sur du matos aussi vieux, d'occase (ou plus cher que du neuf !) qui durera pas forcement plus longtemps que ta piece qui vient de lacher.
                  Bref un programme desktop n'a aucun interet de se cantonner a du vieux matos, mais devrait quand meme tourner sur ce qui etait le plus pourri il y a 3 ans, temps maximum de garantie.

                  Je dis ca non parce que je suis adepte du toujours plus (honnetement je serais deja heureux avec un simple core deux duo, la je tourne avec un Pm 2ghz) mais par simple experience (je ne recommencerai plus a essayer de changer une carte mere d'un p4c 3ghz, ca avait fini par me couter plus cher qu'une petite config neuve....(apres 3 cartes meres d'occas qui ont crame dans les 2 mois, + tout le temps perdu) tout ca parce que ca me faisait chier de racheter RAM et PROC alors que seul la carte mere etait morte...
        • [^] # Re: kdepim non inclu

          Posté par . Évalué à 4.

          Maintenant je ne vois pas en quoi le fait que kmail ait besoin de mysql le rende moins bien,

          Oui, enfin ça impose un peu d'avoir un daemon qui tourne juste pour gérer tes mails. Même pas, d'ailleurs, juste pour gérer le _stockage_ de tes mails (sinon y'avait déjà le MailDaemon[Replacement] de BeOS/Haiku qui faisait la même). Ce n'est pas exactement anodin, si?

          Ca peut être une bonne idée, mais ça devrait être débrayable : le mec qui lit une pauvre boîte IMAP de 10Mo, on ne devrait pas lui imposer une telle usine à gaz.
          • [^] # Re: kdepim non inclu

            Posté par . Évalué à -1.

            Pour moi le principal probleme se situe pour la recuperation de la boite c'est gentil un base de donnee mais bon c'est tout de meme moins lisible qu'un fichier texte... maintenant ils ont peut etre prevu des moyens de sauvegarde et de recuperation pour les personnes ne connassant strictement rien aux BDD...
          • [^] # Re: kdepim non inclu

            Posté par . Évalué à 1.

            Effectivement, pour si peu de mails, c'est problématique.
            Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?

            Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?
            • [^] # Re: kdepim non inclu

              Posté par . Évalué à 3.

              Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?

              Je crois que ça avait été tenté et abandonné, le MySQLe. Enfin de toutes manières, avec les doutes qui planent actuellement sur l'avenir de MySQL, ça serait probablement une bonne idée d'avoir un plan B.

              Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?

              Ne pas réinventer la roue, c'est bien. C'est très bien, même. Mais réutiliser un parpaing comme roue pour éviter de la réinventer, c'est stupide. Même si c'est un très très bon parpaing. Même si on l'a rogné pour le rendre "presque rond".
              • [^] # Re: kdepim non inclu

                Posté par . Évalué à 3.

                Le problème avec akonadi, c'est qu'il se place entre mon serveur imap et mon client mail. Et qu'il veut stocker dans mysql (d'ailleurs, pourquoi pas PostgreSql ? On est vendredi après tout !) *tous* mes messages, pour les servir à kmail derrière. Ce n'est sûrement pas ce que j'attends d'un client imap, qui n'a que des besoins de stockage local limité (je ne stocke en local que ce que je veux garder en local).

                akonadi est peut-être très bien pour stocker son carnet d'adresse, mais pour les mails, ça me semble hautement inadapté à mon cas d'utilisation (que je n'estime pas spécialement exotique).
                • [^] # Re: kdepim non inclu

                  Posté par . Évalué à 4.

                  akonadi ne stocke pas que les mail, il stocke toutes tes info perso (mail, vcard, calendrier, contact, ...) ET les meta données associées (et les tags qui tu as pu placer dessus)
                  Et ensuite, il ne sert pas qu'à les fournir à kmail, mais ou tout autre client pim à qui tu en autorise l'accès.
                  Ça permet d'avoir une base de données centralisée (et non redondante entre applis) de tes infos personnelles avec une interface d'accès uniforme et concurrente (ça se dit ça ?)
                  • [^] # Re: kdepim non inclu

                    Posté par . Évalué à 3.

                    La base de données n'est pas du tout centralisée : elle n'est dispo que sur une seule de mes machines. Je préfèrerai que tous les efforts qui ont eu lieu sur akonadi aient été assignés à avoir un carnet d'adresse sur imap, un calendrier sur imap, etc... (fonctionnalités possibles mais extrêmement mal supportées par kdepim).

                    Pour résumer, j'attendais beaucoup d'akonadi : j'ai testé et tout ce que j'ai constaté, c'est qu'il n'y a AUCUN bénéfice utilisateur à l'utilisation d'akonadi, que ça ne me permettait toujours pas d'avoir un calendrier ou un carnet d'adresses partagé, etc). C'est peut-être lié à l'implémentation foireuse plus qu'au modèle lui-même, mais en l'état ça ne me satisfait pas (surtout sur mon eeepc où je ne souhaite pas de cache local).

                    Pour résumer, en tant qu'utilisateur, je ne vois aucun bénéfice à akonadi. En tant que développeur, je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données. J'ai l'impression que les dev kde se sont bien plantés sur ce coup là.
                    • [^] # Re: kdepim non inclu

                      Posté par . Évalué à 2.

                      rien n'est fini ni figé, tu peux déjà demander une sauvegarde des informations d'akonadi et les importer sur une autre machine. c'est toujours un bon point.
                      Ensuite les requêtes vers akonadi sont faites via DBus et seulement lui il me semble, or DBus peut fonctionner sur un réseau, donc il n'y a pas de limitation technique qui empecherait akonadi de tourner sur une machine et des clients de 4 machines différentes d'y accéder. (il faut bien sur que les clients puissent faire une connexion DBus réseau et que akonadi écoute le réseau pour des requêtes DBus, ce qui n'est pas le cas actuellement)

                      En tant qu'utilisateur, un des intérêts est d'avoir tes infos centralisées quel que soit le logiciel que tu utilises, tu n'as toujours qu'un seul endroit à changer, à configurer, à mettre à jour pour que tous les logiciels qui ont besoin de cette info l'aient à disposition.

                      En tant que développeur, tu n'as pas à coder la partie base de données et requêtes sur les informations, en plus tu n'as aucun problème d'accès concurrent aux fichiers de ressources qu'il est très difficile de résoudre en bossant appli par appli. Tu peux écrire une appli qui vérifie si tu as de nouveau mails et t'affiche le sujet, un lien vers d'éventuelles pièces jointes et un lien vers le contact de messagerie instantané correspondant à l'envoyeur s'il est connecté; le tout très rapidement et avec très peu de code.
                    • [^] # Re: kdepim non inclu

                      Posté par . Évalué à 1.

                      j'ai oublié de répondre à ce point :

                      "je ne vois pas le bénéfice d'avoir un *serveur* akonadi par rapport à une API d'accès aux données."

                      Le fait que ce soit un serveur n'empêche en aucun cas d'avoir une API "à la KDE" pour y accéder. Tu ne fais pas des requêtes toi même sur le réseau via DBus (ou sans...) mais tu utilises libakonadi qui est une abstraction de haut niveau au protocole de communication.
                      • [^] # Re: kdepim non inclu

                        Posté par . Évalué à 1.

                        Tu réponds à côté de la question. Je me pose (très sérieusement) la question du bénéfice d'avoir un *serveur* akonadi plutôt qu'une API, tu me réponds que ça n'empêche pas d'avoir une API. Certes, non, mais je n'ai toujours pas compris le bénéfice (point de vue de développeur et utilisateur) que m'apportait l'architecture actuelle d'akonadi.

                        Pour le stockage centralisé des contacts, j'ai l'impression qu'il faut plus une norme et une lib qu'un serveur.

                        En soi, je n'ai toujours pas compris ce que fait akonadi (en tant que serveur) qui ne saurait être fait par une lib et une api correspondante. Je suis peut-être passé à côté de quelque chose, mais je sèche pour trouver des arguments (et je pense vraiment que le temps investi l'aurait été beaucoup mieux pour une gestion correcte de l'imap).

                        Sinon, il y a une norme maintenant pour dbus sur le réseau ? Les dernières fois que j'avais regardé, c'était toujours "oui oui, c'est possible, mais personne n'a encore fait le boulot".
                        • [^] # Re: kdepim non inclu

                          Posté par . Évalué à 1.

                          ok, je me suis peut-être mal exprimé, mais il me semblait en avoir parler. l'intérêt du serveur plutôt qu'une api ou chaque appli attaque les fichiers de config dans son propre process est la gestion des accès concurrents (sur du nfs par exemple, c'est impossible à faire, sur un FS local, ça l'est, mais c'est très compliqué et limité), la gestion plus fine des droits (rien dans akonadi ne permet à l'heure actuelle de faire ça, mais c'est complètement infaisable avec un accès direct aux données depuis les applications) et la gestion de caches et des ressources et leur réutilisation par plusieurs applis (performances améliorées, pas besoin de reparser les fichiers de données et config pour chaque appli, pas besoin de se connecter au serveur imap pour chaque appli)

                          Pour DBus sur le réseau, il me semble que ça a toujours fonctionné, il y a de sévères limitations (entre autre l'impossibilité d'identifier avec certitude l'id de l'utilisateur faisant la requête, ce qui parait normal, et aussi des problèmes de performance) mais DBus en lui même dialogue par dessus une socket de type unix, qui a strictement (à part pour l'id utilisateur donc) la même api et le même fonctionnement qu'une socket tcp. Et il me semble que le code qui ouvre la socket en TCP au lieu d'UNIX est déjà dans DBus depuis la 1.0
                          • [^] # Re: kdepim non inclu

                            Posté par . Évalué à 1.

                            Les données étant stockées dans mysql (qui est lui-même un serveur), j'ai vraiment du mal avec l'argument de la gestion concurrente, des droits, etc... MySql gère déjà tout ça, et ça sera probablement le cas des autres.

                            On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant. Là, c'est une catastrophe, il ne tourne pas correctement sur mon eeepc701 (pas la faute d'akonadi, mais là aussi les ressources seraient sûrement mieux exploitées ailleurs). Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, sotcker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs.

                            Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas. C'est dommage, parce qu'il y a eu beaucoup d'investissement dessus et que ça me laisse vraiment l'impression d'un beau gâchis.

                            Sinon, dbus sur le réseau, le gros facteur limitant est l'absence d'authentification.
                            • [^] # Re: kdepim non inclu

                              Posté par . Évalué à 3.

                              mysql peut être utilisé sans lancer de serveur, directement depuis akonadi (ou toute autre appli) avec la libmysql et attaquer un fichier privé comme base de données.

                              "On pourrait effectivement parler de performances, de cache, mais pour ça, il faudrait que kde4 soit performant."

                              tu disais te poser cette question "très sérieusement" Que viens faire cette insulte gratuite qui n'apporte rien là dedans ?
                              1) les performances de kde sont moins bonnes que celles de kde3, mais elles ne sont pas "catastrophiques"
                              2) les problèmes de performances sur certains problèmes n'empêchent en rien le fait de vouloir les régler sur d'autres.
                              3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.

                              "Et puis, monter une usine à gaz pour charger 300 contacts, je suis pas convaincu. Par contre, stocker chaque mail que je consulte via imap dans une base de données, je suis sûr que ça plombe les perfs."

                              akonadi, c'est pas pour stocker 300 contacts, je pense que même les développeurs KDE savent que pour ça, on a pas besoin d'un système de gestion des données personnelles centralisées qui utilise un SGBD.
                              Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !
                              Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.
                              De ton coté, si tu ne peux pas patienter ces 0.002999 secondes supplémentaires, tu peux toujours utilser mutt, il lira et fera des recherches dans tes 1 mail super rapidement et sans plomber aucune perf !

                              "Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait kde4. Sur le papier, ça avait l'air joli, dans les faits, ça ne marche pas."

                              Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.
                              Je suis le premier frustré de l'avancement d'akonadi, j'aurai aimé (et je pensais, à la sortie de kde 4.0) en être au point actuel dans la version 4.2 de KDE, finalement, c'est beaucoup plus long que prévu, mais les choses avancent, et je ne doute toujours pas des avantages technologique de ce choix par rapport aux autres, comme je ne doutais pas du potentiel de kde 4 avant la sortie de la 4.0, et il n'y a qu'a voir la vitesse à laquelle les développeurs arrivent à faire avancer les choses à chaque version pour s'en convaincre. ça a été long, mais maintenant, chaque version, en plus d'ajouter son lot de régressions, viens avec ses améliorations en terme de performance et consomation, d'ergonomie, de fonctionnalités et de nouveau outils et logiciels.
                              • [^] # Re: kdepim non inclu

                                Posté par . Évalué à 2.

                                maintenant, chaque version, en plus d'ajouter son lot de régressions

                                Hou, le vilain lapsus ;-)
                              • [^] # Re: kdepim non inclu

                                Posté par . Évalué à 3.

                                Ensuite, tu as beau être "sûr que ça plombe les perfs" ça reste de la théorie de comptoire, et en matière d'optimisation, il n'y a qu'une seule règle absolue, tester !

                                Ca tombe bien, j'ai testé, c'est juste super lent akonadi pour les mails.

                                [cite>Tu vas toujours trouver que dans ton super cas à toi avec 3 mail et 1 date dans ton calendrier, les perfs sont plombées, mais si ça prends 0.003 secondes au lieu de 0.000001 secondes, c'est pas la mort. Par contre, le type qui a vraiment une grosse base de mails, de contacts, de calendriers et tout, il sera content d'avoir un truc plus réactif.

                                Ca tombe bien aussi, j'ai 2.8Go de mails, en 115.000 messages environ (stats faites à la vavite au du et find sur le répertoire Maildir). Peut-être qu'akonadi marche pour tes 200 messages reçus via pop, mais pour moi, ça ne marche pas.

                                Moi j'appelle ça un bon choix, plombé par des problèmes techniques et des retards d'implémentation.

                                C'est peut-être simplement l'implémentation qui fait qu'en l'état, ça ne marche pas. Mais j'ai quand même de gros doutes sur la validité du modèle dans l'ensemble.

                                Sinon, pour les perfs de kde4, elles sont juste insuffisantes pour qu'il soit utilisable sur un eeepc701 (malgré 2Go de ram, c'est donc bien un problème de cpu). Pas grave que ça soit pas la cible, mais pour moi, ça signifie que si on se préoccuppe des perfs, il y a sûrement plus urgent à faire que d'optimiser l'accès aux 200 contacts personnels stockés dans un fichier/dossier (les carnets d'adresse d'entreprise, ils sont déjà dans du ldap ou une bdd).

                                3) les optimisations de code et d'algo ne suffisent pas toujours à améliorer les performances, on fini par atteindre les limites de ce qui peut être fait à un moment, et si on veut faire mieux, la seule façon est d'essayer une autre voie.

                                Comme virer akonadi ;). Non, plus sérieusement, tant mieux si les dev réussissent à faire marcher akonadi correctement, kde a besoin d'un pim qui marche. Mais juste "avoir un truc qui marche" ne suffira pas à me convaincre que les ressources mises sur akonadi ne l'auraient pas été mieux ailleurs.
                                • [^] # Re: kdepim non inclu

                                  Posté par (page perso) . Évalué à 4.

                                  Pour ton eeepc, c'est pas un probleme de cpu mais de lenteur de ton disque dur...

                                  Avec un proc de merde (P3) et un bon disque, kde4 tourne correctement
                                  • [^] # Re: kdepim non inclu

                                    Posté par . Évalué à 1.

                                    Avec un proc de merde (P3) et un bon disque, kde4 tourne correctement

                                    Intéressant. Tu as des sources là dessus ? (notamment, sur pourquoi kde solliciterait autant le disque dur et les remèdes à y apporter). Je précise que j'avais désactivé l'indexation et nepomuk, qui sont donc hors de cause.
                                    • [^] # Re: kdepim non inclu

                                      Posté par (page perso) . Évalué à 4.

                                      Le chargement du cache des SVG par exemple....

                                      Sinon, pour la partie processeur, désactiver oxygen et ses gradients est une bonne idée aussi...
                                • [^] # Re: kdepim non inclu

                                  Posté par . Évalué à 2.

                                  > kde a besoin d'un pim qui marche
                                  Ha bon ?
                                  >(les carnets d'adresse d'entreprise, ils sont déjà dans du ldap ou une bdd
                                  Et pour les particuliers, ils sont certainement nombreux a avoir déjà leur carnet d'adresse soit chez leur F.A.I. soit chez MSn ou encore Gmail... voir Facebook... Donc, bon, comment dire... une suite "pim" lourde locale... est ce encore bien utile ? Dans quel cas ? Pas la majorité des entreprises semble t il, ni la majorité des utilisateurs.

                                  Dans synchronisation il y a accès.
                                  Puisqu'accès est nécessaire, celui ci est plus important.
                                  Pourquoi alors synchroniser puisqu'on peux accéder ? Pourquoi faire de tels échanges de données lorsque l'accès seul rend lui même le même service ?
                                  Bref la "synchronisation" c'était l'ancien temps... Les accès se sont tellement diversifiés et multipliés (qu'un simple 'google gears like' suffit)
                              • [^] # Re: kdepim non inclu

                                Posté par . Évalué à 2.

                                mysql peut être utilisé sans lancer de serveur, directement depuis akonadi (ou toute autre appli) avec la libmysql et attaquer un fichier privé comme base de données.

                                Il peut, mais pas dans Akonadi, apparemment (alors que ça aurait été un bon compromis) :

                                Why not use MySQL/Embedded?

                                We tried that as well, there are two reasons for not using it: No support for the InnoDB engine (which we need for transaction support) and poor availability (only OpenSUSE provided usable packages, needed a patched QSQL driver).

                                http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_MyS(...)
                            • [^] # Re: kdepim non inclu

                              Posté par (page perso) . Évalué à 2.

                              >Non, je crois vraiment qu'aknoadi est l'un des pires choix qu'ait fait
                              >kde4.

                              C'est vrai que avoir un kmail vraiment stable en IMAP, c'est un très mauvais choix...

                              Puis, pour ton histoire de serveur, y'a la même chose sous Gnome (en peut etre plus limité) avec evolution-data-server ...

                              Donc bon, j'ai plus confiance en les devs de gnome et kde qu'en toi ;)

                              Et de ce que j'ai testé de kmail/akonadi, c'était instable mais largement plus rapide que le kmail monolithique actuel.
                              • [^] # Re: kdepim non inclu

                                Posté par . Évalué à 1.

                                Et de ce que j'ai testé de kmail/akonadi, c'était instable mais largement plus rapide que le kmail monolithique actuel.

                                De ce que j'ai teste c'est l'inverse, il fallait bien 5 minutes pour qu'il affiche le moindre email (imap avec copie local) et la verification des nouveaux emails ne fonctionnait pas mais bon lorsque cela sera un peu plus stabilise je retesterai. Par contre j'espere vraiment qu'il y aura la possibilite d'avoir les deux versions en parallel...
                              • [^] # Re: kdepim non inclu

                                Posté par . Évalué à 1.

                                [quote]C'est vrai que avoir un kmail vraiment stable en IMAP, c'est un très mauvais choix...[/quote]

                                C'est clair qu'il fallait monter akonadi pour refaire l'imap de kmail (qui n'est toujours pas un bon client imap, si tu veux une idée de ce qu'est une bonne architecture pour un client imap, regarde du côté de trojita, malheureusement pas encore assez avancé pour être utilisable).

                                [quote]Puis, pour ton histoire de serveur, y'a la même chose sous Gnome (en peut etre plus limité) avec evolution-data-server ...[/quote]

                                evolution-data-server est une couche d'abstraction sur divers backend, un composant corba à utiliser par les applications. Du coup je vois pas trop la différence avec ce que j'ai décrit.

                                [quote]Et de ce que j'ai testé de kmail/akonadi, c'était instable mais largement plus rapide que le kmail monolithique actuel.[/quote]

                                Il fallait refaire kmail, ça c'est une évidence. Mais le choix d'akonadi, vraiment, sur le papier ça avait l'air joli, dans les faits, ça ne marche toujours pas correctement.
                                • [^] # Re: kdepim non inclu

                                  Posté par . Évalué à 2.

                                  Dans les faits ce n'existe pas encore donc attendons de voir avant de critiquer non?
                                • [^] # Re: kdepim non inclu

                                  Posté par (page perso) . Évalué à 4.

                                  Il fallait refaire kmail, ça c'est une évidence. Mais le choix d'akonadi, vraiment, sur le papier ça avait l'air joli, dans les faits, ça ne marche toujours pas correctement.

                                  Je me demande bien pourquoi il ne l'ont toujours pas sorti dit donc !
  • # Vers où va KDE ?

    Posté par . Évalué à 6.

    Moué, j'attends de voir KDE 4.5, mais globalement, je suis assez dubitatif quant à son évolution. Je regrette la branche 3.x sur pas mal de points.

    L'équipe de KDE continue de travailler sur plein de sujets excitants, mais pour les problèmes de base ou les attentes des utilisateurs, rien n'est encore fait.

    Par exemple, KDE ne dispose pas d'un lecteur vidéo digne de ce nom. Je trouve que Dragon Player, pourtant lecteur officiel, jure au milieu des autres applications KDE qui regorgent de fonctions en tout genre. Son support des sous-titres est minimal, il n'est pas capable de me donner des infos sur ce qu'il lit, ne sait pas se mettre à la taille d'une vidéo, ne supporte pas UPNP et, bien plus gênant, n'est pas du tout utilisable en réseau.

    Par exemple, quand je veux regarder sur mon netbook mes vidéos hébergée sur mon serveur en passant par SFTP, ce boulet veut d'abord me les copier dans /tmp. C'est très pénalisant vu que les vidéos pèsent 300 Mo et que je le fais via le WiFi... Alors qu'avec Totem et Nautilus, aucun problème pour lancer la lecture et me balader dedans !

    Et Kaffeine n'est pas beaucoup mieux. À l'origine, il devait être basé sur Phonon mais reste finalement sur Xine et doit donc rester sur ses limitations. Sur Debian avec la dernière version de Xine, toujours pas de VP8... Quand à l'interface qui demande au minimum une fenêtre de 1000×500, c'est pas terrible sur un netbook... La faute à des boutons mal conçus alignés en largeur. Et en plus, je n'arrive même pas à le faire lire des fichiers par SFTP...

    Quand aux autres applis, j'ai l'impression que Konqueror, pourtant l'appli phare de la 3.x, est complètement laissé à l'abandon, remplacé par Dolphin et reKonq qui en font moins.

    L'équipe semble tiraillée entre le besoin de faire des trucs simples et ergonomiques, et celui de faire des trucs très puissants. Le problème, c'est que le mélange ne donne pas quelque chose de cohérent, et comme il n'y a pas assez de dev, elle ne peut pas tout faire.

    C'est dommage, j'aimais bien la 3.5 qui avait une large avance sur tout ce qui se faisait (y compris propriétaire), mais j'ai maintenant l'impression qu'avec la 4, le bureau ne sait plus trop vers où se diriger. Du coup, il s'est fait doublé par GNOME, qui avec Dbus, Gstreamer, Telepathy ou GVFS a réussi à se mettre à niveau. Il n'y a plus qu'Evolution qui aurait besoin d'un travail de fond. J'ai du mal à voir en KDE une vitrine technologique comme avant...

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Vers où va KDE ?

      Posté par . Évalué à 3.

      Je suis plutot d'accord sur le fait que coté lecteur vidéo (Je prefere quand meme kaffeine) et au niveau messagerie instantanée (Kopete et son support des webcam et son interface qui aurait besoin d'un rafraichissement ergonomique) il y a encore du travail a fournir.
      • [^] # Re: Vers où va KDE ?

        Posté par . Évalué à 2.

        C'est vrai, j'avais oublié Kopete, mais lui aussi me semble laissé pour compte...

        D'ailleurs, KDE 4 devait apporter Decibel, un nouveau framework pour ce qui tourne autour de la messagerie instantanée et Kopete devait se baser dessus.

        Pour finir, on n'a plus de nouvelles.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Vers où va KDE ?

          Posté par . Évalué à 2.

          beaucoup de bonnes idées de Decibel on été reprises par l'implementation actuelle de téléphaty.
          les dev de kopete souhaitent migrer vers télépathy, mais manque de dev, de temps, toussa...
    • [^] # Re: Vers où va KDE ?

      Posté par (page perso) . Évalué à -6.

      Vers où va KDE ? Question existentielle qui en appellerait presque une réponse instantanée: D.T....

      Et, plus sérieusement, quand on en est à corriger 16.000 bugs dans une release mineure, on est en droit de se poser des questions. Il y avait un bug toutes les 40 lignes ou bien ?

      Toutes vérifications faites, je suis définitivement une mauvaise langue, ce dont je tiens à m'excuser ici publiquement. Les 16.000 bugs corrigés sont vraiment bien corrigés:
      - 15.999 applications buggées en mousse (style Kaffeine, K-machin qui gère mal le wifi, K-s'tête chinois...) virées
      - le 16.000ème: remplacement de kdm par gdm dans le startup.sh

      Oui, encore une fois, modestement, et comme disait l'amie Ségolène: pardon !
      • [^] # Re: Vers où va KDE ?

        Posté par (page perso) . Évalué à 4.

        L'histoire des 16 000 bugs c'est vraiment du n'importe quoi.
        Cf cette discussion: http://lwn.net/Articles/399523/
        En gros il regardent juste le nombre de bugs fermés entre deux dates (la release 4.4 et la release 4.5 par exemple).
        Si un même bug est ouvert 250 fois en doublon car il impacte beaucoup de monde et bien une seule correction du code permettra d'annoncer fièrement qu'on a corrigé 250 bugs !
        • [^] # Re: Vers où va KDE ?

          Posté par . Évalué à 8.

          >L'histoire des 16 000 bugs c'est vraiment du n'importe quoi.

          Uniquement dans *ton* interprétation!
          Le bug dupliqué quelqu'un a bien dut bosser pour vérifier qu'il était un dupliqué et le fermer, non?
          C'est aussi du travail donc je trouve normal de le compter parmi le boulot fournit par les contributeurs a KDE, tout comme les traductions, la documentation, etc.

          Après il serait bien d'avoir aussi le nombre de bug corrigé par une modification de code, c'est une autre mesure du travail accompli, mais l'un ne remplace pas l'autre!
          • [^] # Re: Vers où va KDE ?

            Posté par (page perso) . Évalué à 6.

            >>> Uniquement dans *ton* interprétation!

            Quand on annonce que 16 000 bugs ont été corrigés cela devrait vouloir dire que 16 000 dysfonctionnements ont réellement été corrigées dans KDE. Sinon cela perd tout son sens.
            Bien entendu que vérifier les doublons c'est du boulot, mais cela ne corrige pas un dysfonctionnement dans KDE !
            Sinon ils peuvent aussi dire que 16 000 trous ont été creusés puis rebouchés. C'est assurément un sacré travail que de creuser et de reboucher autant de trous mais je en vois pas en quoi cela améliore directement KDE.

            Je ne dénigre pas du tout le boulot des devs de KDE. Je dis juste qu'ils feraient mieux de laisser tomber cette mesure des bugs fermés car elle est absurde.
            • [^] # Re: Vers où va KDE ?

              Posté par (page perso) . Évalué à 2.

              Je ne dénigre pas du tout le boulot des devs de KDE. Je dis juste qu'ils feraient mieux de laisser tomber cette mesure des bugs fermés car elle est absurde.

              C'est une mesure qui a le mérite d'être très simple et de ne pas demander de travail supplémentaire, il suffit juste de faire une soustraction.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Vers où va KDE ?

              Posté par . Évalué à 3.

              A la reflection, tu as raison: ils auraient due dire '16000 bug reports' ont été fermé pas '16000 bug'.

              C'est un raccourci plutôt malheureux, oui.
              Après rapporter ce chiffre ne me choque pas, il est une mesure (parmi d'autre) de l'effort fourni.
    • [^] # Re: Vers où va KDE ?

      Posté par (page perso) . Évalué à 6.

      >>> Par exemple, KDE ne dispose pas d'un lecteur vidéo digne de ce nom.

      Y'a SMPlayer qui est bourré de fonctions et qui est écrit avec Qt: http://smplayer.sourceforge.net/
      Certes Qt ce n'est pas KDE mais bon...au moins l'intégration est meilleure qu'avec un soft GTK.
    • [^] # Re: Vers où va KDE ?

      Posté par . Évalué à 4.

      Smplayer et VLC ont tout deux une interface basé sur Qt et sont pour moi les lecteurs vidéos les plus avancés.

      Pour Dolphin, je le trouve à l'usage bien plus agréable à utiliser que konqueror (y compris dans la branche 3.x), c'est vrai que lors de la sortie de KDE 4.0 il était largement en retard, mais personnellement je peux plus m'en passer, je ne me sers plus de konqueror, y compris pour la navigation web (firefox).

      Personnellement je trouve que KDE est actuellement l'environnement graphique le plus avancé, bien que je ne l'utilise pas (mais je me sers de la plupart de leurs applications).

      Si un logiciel n'est pas directement fournit par KDE rien n'empêche d'aller le chercher ailleurs, avec un peu de chance ça sera basé sur Qt.
      Tu vois une différence entre une applications KDE et une application Qt toi ? Moi pas ?

      Et puis avec le thème Qt4 de Gtk, même les applications Gtk sont visuellement proches de Qt, donc même si une application KDE est manquante je vois vraiment pas le problème tant que ça tourne sous Linux...
      • [^] # Re: Vers où va KDE ?

        Posté par . Évalué à 3.

        Smplayer et VLC ont tout deux une interface basé sur Qt et sont pour moi les lecteurs vidéos les plus avancés.
        ...
        Si un logiciel n'est pas directement fournit par KDE rien n'empêche d'aller le chercher ailleurs, avec un peu de chance ça sera basé sur Qt.
        Tu vois une différence entre une applications KDE et une application Qt toi ? Moi pas ?


        Qu'un logiciel soit développé en Qt ne suffit pas pour qu'il soit pleinement intégré à KDE. C'est comme dire qu'un logiciel en GTK est explicité fait pour GNOME, c'est faux.

        Des environnements de bureau fournissent de nombreuses fonctions plus haut niveau que le toolkit sur lesquels ils se basent, comme l'accès aux fichiers à distance avec Kio, Phonon qui permet d'avoir des paramètres multimedia communs à toutes tes applis, ou Kwallet qui garde précieusement tous les mots de passe.

        C'est également important pour l'interface : boîtes de dialogues, cohérence de l'ergonomie et des icônes, etc.

        VLC peut lire des fichiers par SFTP ?


        Pour Dolphin, je le trouve à l'usage bien plus agréable à utiliser que konqueror (y compris dans la branche 3.x), c'est vrai que lors de la sortie de KDE 4.0 il était largement en retard, mais personnellement je peux plus m'en passer,

        D'un point de vue fonctionnalités pures, il reste largement en deça de Konqueror. De nombreuses fonctions ont sauté, comme la sélection par motif, l'affichage visuel des dossiers par tailles, le découpage des fenêtres, etc.

        Quand on est habitué à une certaine puissance, il est difficile de s'accommoder de tels choix, on a l'impression de revenir en arrière.


        je ne me sers plus de konqueror, y compris pour la navigation web (firefox)

        Toujours pareil, Firefox ne s'intègre pas correctement à KDE, ne serait-ce que que parce qu'il est plus conçu pour GTK, mais pas seulement : il n'utilise pas kwallet, ni kio, ni Phonon, etc.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Vers où va KDE ?

          Posté par . Évalué à 2.

          "Toujours pareil, Firefox ne s'intègre pas correctement à KDE, ne serait-ce que que parce qu'il est plus conçu pour GTK, mais pas seulement : il n'utilise pas kwallet, ni kio, ni Phonon, etc. "
          Il existe le paquet firefox-kde-opensuse (mais que l'on peut trouver dans d'autres distrib comme ArchLinux), qui permet de mieux intégrer Firefox à KDE, en s'appuyant justement sur kwallet, l'sexplorateur de fichiers de KDE, ...
          • [^] # Re: Vers où va KDE ?

            Posté par . Évalué à 2.

            D'ac, je ne savais pas. Tant mieux, ça prouve qu'il y avait un vrai besoin.

            Par contre, ça n'a pas l'air d'être dispo sous Debian, dommage.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Vers où va KDE ?

              Posté par . Évalué à 2.

              J'ai essayé de l'utiliser mais après une maj de firefox, j'ai eu des problèmes et c'est resté incompatible trop longtemps. J'ai du le laisser tomber, mais ça c'est un "problème" propre aux extensions firefox, pas à KDE amha.

              J'ai aussi laissé tomber konqueror parce que firefox fait mieux le boulot même si je suis d'accord avec toi sur les usages incroyables et l'intégration magnifique que permettait konqueror. J'avais trop de sites qui ne rendaient pas bien dans konqui, et surtout les extensions firefox sont géniales.
              Quand j'ai commencé à utiliser konqui, j'espérais beaucoup des kio slaves et des kparts, d'autres idées du genre "l'extension" qui permettait de ripper des CDs facilement depuis konqui, et j'espérais en voir arriver plus. Ca n'a jamais eu lieu faute de développements.

              Pendant ce temps, j'ai trouvé cette richesse et cette facilité d'extension et de modification de l'appli pour l'adapter à mes usages chez firefox et ses extensions. J'utilise KDE pour cette possibilité d'adaptation, et firefox aussi, malgré les lacunes de GTK.

              Donc je n'ai plus besoin que d'un file manager qui me procure les possibilité des kio, dolphin fait le boulot, tant pis pour les kparts et l'intégration géniale de konqui. C'était une bonne idée, mais s'il n'y a pas les ressources en dévs derrière pour les mener à bout, ça ne sert à rien de pisser contre le vent.
              • [^] # Re: Vers où va KDE ?

                Posté par (page perso) . Évalué à 2.

                J'avais trop de sites qui ne rendaient pas bien dans konqui, et surtout les extensions firefox sont géniales.
                T'as essayé avec webkit ? Même si ce n'est dispo "officiellement" que depuis cette version, ça fait un moment qu'on peut l'utiliser avec konqui.
                Pour les extensions, autant que je m'en souvienne il y a eu (il y a fort longtemps) une démo technique qui permettait d'utiliser les extension firefox avec konqui (un KPart XUL), mais qui n'a pas été continué (probablement trop de boulot à maintenir). Dommage, parce konqui + extensions firefox, quand bien même ça serait un peu plus lent, ça laisserait tout le monde loin, très loin derrière.
                • [^] # Re: Vers où va KDE ?

                  Posté par . Évalué à 2.

                  >T'as essayé avec webkit ? Même si ce n'est dispo "officiellement" que depuis cette version, ça fait un moment qu'on peut l'utiliser avec konqui.

                  J'ai installé la dernière version pour essayer, mais sans mes extensions je doute de m'y faire à nouveau.

                  wekbit, c'est juste le rendu ou c'est aussi le javascript?
                  Parce que c'était ça aussi qui posait des problèmes, pas seulement khtml.
        • [^] # Re: Vers où va KDE ?

          Posté par . Évalué à 1.

          Bien sûr il y a quelques différences entre une application typiquement KDE et une application Qt, mais dans l'ensemble ça ne change pas tant que ça, nombre de fonctionnalités de KDE finissent dans Qt comme Dbus et Phonon par exemple.

          Après tu me parle de Kwallet, mais ça ne concerne que quelques applications et pour Kio ça ne concerne que le gars qui programme l'application, l'utilisateur final en a un peu rien à faire.

          Il y a aussi la cohérence de l'interface mais franchement est ce que c'est vraiment génant de pas avoir exactement la même fenêtre avec Fichier/Ouvrir... entre Kate et QtCreator ?

          Moi personnellement je m'en accomode très bien, je m'en aperçois même pas au quotidien.
          J'utilise mes applications pour les services qu'elle fournissent et j'attend d'elles qu'elles soient agréables, rien à faire que mon éditeur de texte (Kate/KDE), mon environnement de développement (QtCreator/Qt) et mon navigateur (Firefox/Gtk+) diffèrent à quelques détail près, en choisissant bien ses thèmes ils ont tous la même apparence à moins de chercher dans le détail.

          Effectivement, je connais peut être pas assez Konqueror, mais dans ce que tu cite Dolphin permet de diviser la fenêtre, tout comme trier les fichiers par taille.
          (Ou alors j'ai mal compris).
          • [^] # Re: Vers où va KDE ?

            Posté par . Évalué à 4.

            Bien sûr il y a quelques différences entre une application typiquement KDE et une application Qt, mais dans l'ensemble ça ne change pas tant que ça, nombre de fonctionnalités de KDE finissent dans Qt comme Dbus et Phonon par exemple.

            C'est vrai, et c'est même très bien, c'est la preuve que leur boulot est reconnu et en vaut la peine.

            Après tu me parle de Kwallet, mais ça ne concerne que quelques applications et pour Kio ça ne concerne que le gars qui programme l'application, l'utilisateur final en a un peu rien à faire.

            Kwallet concerne toute application qui a un mot de passe à conserver et les exemples sont légions : Konqueror pour les formulaires, Dolphin pour les partages distants, Krdc pour les accès distants, Amarok pour last.fm, Chocoq pour Twitter, etc.

            Quant à Kio, je ne suis pas développeur et pourtant j'en ai besoin chez moi et au bureau. Ben oui, j'ai plusieurs machines, et au boulot je dois accéder à des partages SMB et SFTP. C'est par Kio que je passe, même sans m'en rendre compte.

            Il y a aussi la cohérence de l'interface mais franchement est ce que c'est vraiment génant de pas avoir exactement la même fenêtre avec Fichier/Ouvrir... entre Kate et QtCreator ?

            Ça dépend des gens, mais c'est le ressenti global qui y perd. Après, ça peut être comme sous Windows où chaque appli a son propre framework, mais je trouve dommage de ne pas le faire sous Linux où l'on a justement de très bons frameworks, unifiés et complets.

            Effectivement, je connais peut être pas assez Konqueror, mais dans ce que tu cite Dolphin permet de diviser la fenêtre, tout comme trier les fichiers par taille.

            En effet, Dolphin peut diviser sa fenêtre, mais pas en plus de deux parties, quand Konqueror peut la diviser en autant que tu veux. C'est certes overkill, mais qui peut le plus peut le moins.
            L'autre fonction, ce n'est pas ça, je vais essayer de la décrire : il s'agit de présenter les répertoires par des rectangles dont la surface est proportionnelle à l'espace occupé (ça a le même rôle que Baobab sous GNOME). Quand on veut faire le ménage, c'est très utile.

            Après, chacun fait ce qu'il veut, bien sûr, je ne force personne. Je me contente de souligner ce pourquoi je ne l'utilise pas, malgré avoir tenté d'en saisir l'approche. Et j'imagine ne pas être le seul. Après, tu le dis toi-même, il y a des défauts, tu arrives à passer outre, mais tout le monde ne le peut pas forcément.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Vers où va KDE ?

              Posté par . Évalué à 2.

              J'interviens juste pour la forme pour confirmer qu'effectivement, tu n'es pas tout seul.
            • [^] # Re: Vers où va KDE ?

              Posté par . Évalué à 1.

              En effet, Dolphin peut diviser sa fenêtre, mais pas en plus de deux parties, quand Konqueror peut la diviser en autant que tu veux. C'est certes overkill, mais qui peut le plus peut le moins.

              Je ne trouve pas ça du tout overkill, il m'est déjà arrivé plusieurs fois de diviser la fenêtre en quatre pour voir quatre dossier différents en simultané.
              Aujourd'hui encore, je l'ai coupé en trois pour accéder à des dossiers sur des serveurs distants, et comme l'accès est un peu lent, je naviguait dans les répertoires des différents serveurs en parallèle.

              Il m'est aussi arrivé de couper la fenêtre en deux pour mettre des pages HTML en parallèle (un peu comme des frames).
            • [^] # Re: Vers où va KDE ?

              Posté par (page perso) . Évalué à 2.

              il s'agit de présenter les répertoires par des rectangles dont la surface est proportionnelle à l'espace occupé

              installe Kdirstat

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Vers où va KDE ?

                Posté par . Évalué à 2.

                Merci pour l'info, mais en regardant de plus près, KDirstat est pour KDE3, lequel n'est plus dispo que pour Debian stable... Et je ne pense pas que ça s'intègre dans Dolphin, si ?

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Vers où va KDE ?

                Posté par . Évalué à 2.

                On peut ouvrir un terminal et lancer fsview. En ouvrant avec konsole, hop ! compatibilité avec KDE (et avec tout le reste si on veut aussi).
            • [^] # Re: Vers où va KDE ?

              Posté par . Évalué à 2.

              L'autre fonction, ce n'est pas ça, je vais essayer de la décrire : il s'agit de présenter les répertoires par des rectangles dont la surface est proportionnelle à l'espace occupé (ça a le même rôle que Baobab sous GNOME). Quand on veut faire le ménage, c'est très utile.

              Ç a existe toujours, au moins dans konqueror.
              Je suis avec KDE 4.4 (sur une mdv 2010.1), et dans konqueror lorsque j'affiche un dossier, parmis les types d'affichage j'ai un "affichage de la taille des fichiers".
              Je crois qu'il s'appelle fsviewpart(.so) et dans mandriva il se trouve dans le paquet konq-plugins (avec plusieurs autres plugins pour konqueror).

              Et si on a installé filelight il y a aussi une "vue radialMap" qui est en fait un filelight intégré dans konqueror.
              • [^] # Re: Vers où va KDE ?

                Posté par . Évalué à 2.

                Je sais bien, Konqueror n'a pas perdu toutes ses fonctions.

                Malgré tout, c'est bien Dolphin qui est mis en avant pour gérer les fichiers, et c'est ce que je trouve dommage.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Vers où va KDE ?

                  Posté par (page perso) . Évalué à 7.

                  Eh bien fait une demande pour Dolphin! l'auteur est très réactif et très à l'écoute.
                  Je ne comprends pas très bien ces façons de se plaindre sans cesse: on n'a pas 4 mains pour coder, et on n'a qu'un seul cerveau, on ne pense pas forcément à tout. Si personne ne fait l'effort d'un rapport de bug ou d'une demande de fonction, ben faut pas s'attendre à ce que ça apparaisse miraculeusement. Même Saint Ignucius ne fait pas de miracles.

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                  • [^] # Re: Vers où va KDE ?

                    Posté par . Évalué à 1.

                    Désolé, je ne pensais pas que les développeurs avaient besoin d'un bug report pour savoir qu'il vaut mieux que le remplaçant d'un programme ait au minimum autant de fonctionnalités que le remplacé.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Vers où va KDE ?

                      Posté par (page perso) . Évalué à 7.

                      D'abord c'est essentiellement le développeur. Il n'a qu'une seule vie, et il code sur son temps libre, c'est pourquoi il y a des choses prévues qui ne sont pas encore prêtes. Et aussi parce qu'il y a des priorités, et des gens qui font des rapports de bugs, lesquels sont traités avant de coder d'autre choses.
                      Ensuite, Dolphin n'est pas un remplaçant. Le remplaçant c'est Konqueror 4, qui demeure très puissant. Dolphin est un outil qui essaie de rester simple, parce que plein de râleurs n'aimaient pas la politique du couteau suisse avec Konqueror.
                      Enfin, si ça se trouve ça marche chez le développeur et pas chez toi. Ou alors ça marchote dans le tronc de développement.

                      Donc fais un rapport de bug.

                      Je sais de quoi je parle, on a exactement le même problème sur un projet de SGBD: on ne peux pas faire tout ce qu'on a prévu, faute de temps, et il y a des utilisateur qui râlent à chaque nouvelle version parce qu'ils voudraient tel ou tel truc. Mais ils n'ont jamais rien dit avant. Ces tels ou tel truc sont d'ailleurs souvent presque prêts, mais faute de demande, je fais avancer le code lentement.

                      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                    • [^] # Re: Vers où va KDE ?

                      Posté par . Évalué à 3.

                      ou pas (Netscape Communicator => Firefox dans ses premières incarnations)
    • [^] # Re: Vers où va KDE ?

      Posté par . Évalué à 3.

      Je suis resté avec VLC, qui est maintenant écrit en Qt... C'est toujours ça de gagné pour l'intégration !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.