Journal Qt dans Ubuntu

Posté par  (site web personnel) .
Étiquettes :
22
18
jan.
2011
Mark Shuttleworth, le "Dictateur bienveillant auto-désigné à vie" d'Ubuntu, vient de publier un billet intéressant sur son blog.

Alors qu'Ubuntu n'intégrait par défaut aucune application basée sur le toolkit Qt cela pourrait bien changer pour la version qui suivra Natty Narwhal en octobre prochain. Mark indique que les développeurs de Canonical vont travailler avec Ryan Lortie, grand spécialiste de dconf, afin de développer des bindings pour Qt.
Mark semble espérer que ces bindings inciteront les responsables des applications KDE à inclure cette compatibilité dconf dans leurs logiciels : "I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community".

Une fois que ce travail d'infrastructure sera terminé et qu'il permettra d'installer des applications Qt s'intégrant bien dans l'environnement alors tout est ouvert : "should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install".

On a l'impression que Mark Shuttleworth agite une carotte sous le nez des développeurs KDE en faisant miroiter la perspective d'une intégration par défaut de leurs applications dans la distribution GNU/Linux la plus populaire au monde. Bien entendu il prend bien soin de passer un peu de pommade aux développeurs GNOME pour tenter de désamorcer les critiques : "The decision to be open to Qt is in no way a criticism of GNOME. It’s a celebration of free software’s diversity and complexity".

Ce concept mixant des applications basées sur plusieurs toolkits semble quand même un peu bizarre. Depuis l'origine Ubuntu se base sur GNOME et prône la simplicité avec une seule application par défaut pour chaque tâche. Pourquoi chercher ainsi à intégrer des logiciels Qt ou même KDE ? Est-ce que Kubuntu n'est pas justement fait pour les gens qui préfèrent KDE ? Et puis comment faire tenir Qt en plus sur le CD d'installation qui est déjà plein jusqu'à la gueule ? Est-ce que la consommation mémoire typique ne va pas être impacté par ce mix de toolkit ?

Toutes ces questions rendent plus floues les perspectives à long terme d'Ubuntu. L'orientation claire et précise qui existait au lancement du projet semble s'être évaporée.
Si on ajoute à ça le remplacement de Rhythmbox par Banshee et la divergence entre le bureau Unity développé par Canonical et le Shell du futur GNOME 3, on ne peut s'empêcher de penser qu'il y a de l'eau dans le gaz entre Ubuntu et le projet GNOME.
  • # C'est très bien

    Posté par  (site web personnel) . Évalué à 10.

    Il est intéressant de s'atarder sur la seule phrase en gras de l'article :
    it’s the values which are important, and the toolkit is only a means to that end
    En gros, ce qui est intéressant, c'est ce qu'une application permet de faire, le besoin auquel elle répond. Le choix de QT/GTK/autre c'est finalement une décision technique dont l'utilisateur final se fiche complètement.

    Evidemment, le problème qu'il y aura si des applications Qt sont livrés avec Ubuntu par défaut, c'est le "look and feel". Ca demandera encore du travail pour qu'on ne puisse pas différencier entre une application écrite en Qt et une application GTK. Mais ça devrait être possible.

    Je trouve que c'est une excellente nouvelle. Pour ma part, je préfère le "look and feel" des applications GTK (plus minimaliste en général), mais j'utilise Qt plutôt que GTK/Gnome quand il s'agit de développer quelque chose, parce que c'est tellement plus puissant et multi plateformes.
    • [^] # Re: C'est très bien

      Posté par  . Évalué à 3.

      Entièrement d'accord, L'important , c'est la qualité de l'application . Par exemple, j'ai jamais pu me faire Brasero et j'installe donc systématiquement K3B.

      Après , je sais que tout le monde n'est pas comme moi mais je trouve que c'est une perte de temps de se prendre la tête à supporter "Look and Feel" de GTK sur QT.
      A une époque où la moitié des applications se trouvent être des pages web aux ergonomies diverses et variés.

      Avoir des applications GTK qui côtoient des applications QT , c'est juste un problème d'économie de mémoire et d'espace disque dur.
    • [^] # Re: C'est très bien

      Posté par  . Évalué à 3.

      Le choix de QT/GTK/autre c'est finalement une décision technique dont l'utilisateur final se fiche complètement.

      Tu te contredis puisque toi-même tu déclares préférer GTK+ quand tu es utilisateur.

      En ce qui me concerne, le choix du toolkit n'est pas du tout anecdotique, et je n'utiliserai probablement jamais une application qui utilise GTK+, tellement ça me rebute. ;-)

      Donc, non, ce choix n'est pas qu'une décision technique.
      • [^] # Re: C'est très bien

        Posté par  . Évalué à 1.

        Tu pourrais détailler un peu ta position ? En quoi ce n'est pas anecdotique ? Je ne vois pas en quoi le choix d'un toolkit à un impact si important au point que l'on se prive d'une application développé dans un autre.

        Je suis juste curieux :-)
        • [^] # Re: C'est très bien

          Posté par  . Évalué à 6.

          Je pense que c'est tout simplement une question d'ergonomie, et d'environnement.

          Par exemple, je préfère quand mes applis ont le même comportement, que ce soit au niveau des composants (les clics sur les barres de défilement ne font pas la même chose en GTK et en Qt), des fenêtres (typiquement « ouvrir » et « enregistrer sous ») ou des raccourcis (clavier et souris, comme le Control molette).

          Et puis il y a les détails, par exemple si je monte un répertoire distant avec GNOME, seules les applications utilisant GVFS les verront.

          L'un n'est pas nécessairement mieux que l'autre, mais il est important que toutes les applications aient le même comportement de base.

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

          • [^] # Re: C'est très bien

            Posté par  (site web personnel) . Évalué à 4.

            >Par exemple, je préfère quand mes applis ont le même comportement, que ce soit au niveau des composants (les clics sur les barres de défilement ne font pas la même chose en GTK et en Qt), des fenêtres (typiquement « ouvrir » et « enregistrer sous ») ou des raccourcis (clavier et souris, comme le Control molette).

            Perso je préfère une application qui fonctionne bien et qui propose toutes les fonctions dont j'ai besoin que d'être obligé d'utiliser un programme moins complet mais qui utilise le même toolkit que mon bureau
            • [^] # Re: C'est très bien

              Posté par  . Évalué à 2.

              L'un n'empêche pas l'autre.

              Pour ma part, je n'ai pas ce problème, même si ça n'a pas toujours été le cas; surtout pour trouver un équivalent à K3B, mais Brasero me convient largement. Avant, c'était XCDRoast, toute une époque…

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

        • [^] # Re: C'est très bien

          Posté par  . Évalué à 8.

          En ce qui me concerne, ce n'est pas tant le look que le feel qui me fait rejeter en bloc GTK+, car je suis carrément allergique à ce toolkit.

          Ce que je n'aime pas dans GTK+ est parfois assez difficile à expliquer, car c'est assez viscéral, mais je vais essayer:
          - les widgets sont vraiment, vraiment trop gros; j'ai presque toujours l'impression que l'interface prend trop de place dans l'application que celle-ci n'est pas assez centrée sur le contenu sur lequel on travaille;
          - la réactivité des widgets m'a toujours paru asthmatique;
          - apparemment, utiliser GTK+, c'est aussi aimer une certaine philosophie de l'interface qui me rebute assez, il y a quasiment toujours un truc qui m'ennuie à mort dans les interfaces GTK+, ce n'est pas forcément à cause de GTK+, mais c'est le choix des dévs; par exemple, les fenêtres flottantes dans Gimp ou Mypaint, qui sont de bons logiciels côté fonctionnalités, mais les choix d'interface m'exaspèrent; il y a toujours un truc mal foutu dans un logiciel GTK+, mais je ne sais pas pourquoi ^^. Le seul logiciel que je tolère, c'est Inkscape...
          - il y a une saloperie de bug sur les menus déroulants, qui parfois ne s'affichent qu'à moitié et il faut à utiliser une saloperie de flèche pour tout voir; ce bug existe depuis trèèèèès longtemps et je l'ai vu sur Linux comme sur Windows, sur toutes mes machines; c'est super-chiant, à lui seul, ce bug persistant devrait avoir soulevé une révolte chez les utilisateurs de GTK+ ;-)
          - le look n'est pas terrible non plus, quand j'y pense, mais s'il n'y avait que ça à redire, ça irait...
          • [^] # Re: C'est très bien

            Posté par  (site web personnel) . Évalué à 3.

            >>> les widgets sont vraiment, vraiment trop gros

            Tu a essayé Clearlooks compact ? Lien http://martin.ankerl.com/2007/11/04/clearlooks-compact-gnome(...)
            Pour le reste je ne dis rien, c'est une pure question de goût.
            • [^] # Re: C'est très bien

              Posté par  . Évalué à 4.

              Je fais le même reproche, et vu les screenshots, franchement c’est pas mieux avec ce thème : sur-utilisation du gras dans Tracker, qui le rend, de facto, inutile ; widget plus petit, mais alors quel espace gâché entre, le save as est assez révélateur, alors qu’on aurait pu y gagner pour afficher ce qui est utile (le contenu du système de fichiers). Moi aussi j’ai une haine viscérale de gtk mais je ne saurai pas plus dire exactement à quoi ça tient, je crois que c’est tout un tas de petits détails. Là encore je vois dans save as l’utilisation incohérente des icônes dans les boutons, la barre d’ascenceur un peu trop flashy pour un élément somme toute assez secondaire, mais je suis sûr qu’il y a plein d’autres trucs.
            • [^] # Re: C'est très bien

              Posté par  . Évalué à 1.

              Ah merci, je ne connaissais pas. Ça réduira probablement le nombre de jurons que je pousse quand j’utilise GTK+. ^^
          • [^] # Re: C'est très bien

            Posté par  (site web personnel) . Évalué à 2.

            >Le seul logiciel que je tolère, c'est Inkscape...

            Ah ? Moi je le classe dans les pires: lent, moche, faisant des trucs sale avec Gtk...

            ->il y a une saloperie de bug sur les menus déroulants, qui parfois ne s'affichent qu'à
            >moitié et il faut à utiliser une saloperie de flèche pour tout voir; ce bug existe depuis
            >trèèèèès longtemps et je l'ai vu sur Linux comme sur Windows, sur toutes mes machines;
            >c'est super-chiant, à lui seul, ce bug persistant devrait avoir soulevé une révolte chez les
            >utilisateurs de GTK+ ;-)

            Ce n'est pas un bug, c'est le fonctionnement de Gtk... Comme Gtk utilise un menu et pas un liste, pas d'ascenseur... Mais c'est pas un truc qui me gène...

            >le look n'est pas terrible non plus, quand j'y pense, mais s'il n'y avait que ça à redire, ça
            >irait...

            Bah, moi je trouve que Gtk avec Oxygen-gtk ca roxorise pas mal... J'aime beaucoup le thème d'Ubuntu (10.10) aussi...

            Après, l'avantage de Oxygen-gtk, c'est de transmettre le comportement de Qt à Gtk...
            • [^] # Re: C'est très bien

              Posté par  (site web personnel) . Évalué à 7.

              C'est le fonctionnement normal de gtk d'afficher un menu vide avec une petite flèche en bas pour afficher le contenu du menu ? Parce que je crois que c'est de souci que l'on parle, pas du fait que parfois il y a une flèche quand il n'y a plus de place dans le menu.

              Cela-dit le comportement de KDE4 sur ce point est aussi critiquable. Plutôt que de limiter le nombre d'items affichés dans un menu en proposant un moyen d'accéder aux items restants (flèche, sous-menu, ascenceur, effet fisheye,...), plusieurs colonnes sont affichées dans le menu. Par exemple, dans dolphin en voulant faire un déplacer vers "Dossier racine > usr > share", ça me cache tout l'écran. Ca le fait aussi digikam quand on veut associer un tag à un contact Kontact.
              Dans KDE3 ça présentait un sous-menu au bas du menu ce qui était 100x plus intelligent.

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

            • [^] # Re: C'est très bien

              Posté par  . Évalué à 6.

              Ce n'est pas un bug, c'est le fonctionnement de Gtk... Comme Gtk utilise un menu et pas un liste, pas d'ascenseur... Mais c'est pas un truc qui me gène...

              Mmm… it’s not a bug, it’s a feature… ?
              http://img651.imageshack.us/img651/1743/gtkbug.png

              Really?…

              Nan, je n’y crois pas. Pas une seconde. ^^
              Là, c’est sous Windows, avec une grosse liste à dérouler, mais j’ai le même genre de merde sous Linux, quelle que soit la taille du menu, même s’il y a largement la place pour tout afficher. GTK+ adore afficher des demi-menus vides. ^^
              Ce bug existe depuis que je connais Linux (2004?), et il est inratable, puisque ça arrive très souvent, voire systématiquement… ça dépend de l’humeur de la bête.
    • [^] # Re: C'est très bien

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Ce qui me plaît dans l'histoire, c'est l'éventuelle promesse d'une installation plus aisée des programmes en Qt.

      En ce moment, installer Minitube sur une LTS est un cauchemar : la seule version qui fonctionne est pour Natty (qui est en alpha), et on ne peut qu'attendre un backport officiel avant que YouTube ne modifie à nouveau son protocole. L'autre solution consistant à compiler Qt 4.6, super fun pour quelqu'un comme moi qui veut juste mater YouTube sur son netbook à plus de deux images par secondes.

      Or, en novembre dernier, les devs évoquaient la possibilité d'assouplir un peu la redoutable BiannualForcedDeathMarch™ en cherchant un moyen de mettre à jour aisément les applis qui en ont réellement besoin (http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-movi(...) ). Si l'inclusion d'un Qt "discret" dans l'Ubuntu de base peut me permettre de mettre à jour VLC ou Kdenlive (hum, quoique celui-là...) au moins aussi facilement que sous un Windows, alors je suis carrément pour.
    • [^] # Re: C'est très bien

      Posté par  . Évalué à 1.

      Evidemment, le problème qu'il y aura si des applications Qt sont livrés avec Ubuntu par défaut, c'est le "look and feel".

      Tant qu'elle ne ressemble pas à l'horrible GTK sans thème! c'est bonnard!
      Je n'ai jamais compris pourquoi cette bibliothèque n'intégrait pas directement par défaut les paramètres d'un thème.

      Une appli GTK sans .gtkrc, c'est d'un laid.

      Même si ça corrige assez rapidement, je trouve ça dommage de devoir faire cette étape.
    • [^] # Re: C'est très bien

      Posté par  (site web personnel) . Évalué à 6.

      "Evidemment, le problème qu'il y aura si des applications Qt sont livrés avec Ubuntu par défaut, c'est le "look and feel". Ca demandera encore du travail pour qu'on ne puisse pas différencier entre une application écrite en Qt et une application GTK. Mais ça devrait être possible."

      Le "thème" GTK de QT4 reproduit parfaitement GTK, jusqu'à permettre l'appel du gestionnaire de fichiers de GTK lorsqu'on ouvre un fichier à partir d'une telle application dans un environnement GNOME.

      L'intégration est DÉJÀ quasiment parfaite en terme de Look.

      Il reste le "feel"...
  • # Vendredi - 3

    Posté par  (site web personnel) . Évalué à 7.

    Maintenir Ubuntu et Kubuntu est trop compliqué. Et surtout, cela offre un choix qui peut perturber l'utilisateur.
    Donc on commence par ajouter QT à Ubuntu.
    Comme QT prend de la place, on oublie la version CD, et on met tout ça sur DVD.
    Et comme un DVD fournit plein d'espace, on met Ubuntu et Kubuntu sur le même DVD.

    Nos deux distribs se retrouvent sur le même DVD, Ubuntu contient déjà QT... => Plus qu'à merger, et au final, on ne conserve qu'une Kubuntu sur DVD.
  • # Virage à Qt toute, moussaillon !

    Posté par  . Évalué à 10.

    Au contraire, je pense que la stratégie de Canonical sur le long terme semble se clarifier.
    Le rapprochement qui semble s'opérer avec Nokia notamment sur la gestion du multitouch (le mainteneur de utouch Duncan McGregor est *très* intéressé par Qt Quick), le portage d'Unity2D sur Qt/QML, ça met la puce à l'oreille.
    http://blog.qt.nokia.com/2010/12/22/my-new-years-resolution-(...)
    http://www.webupd8.org/2011/01/unity-2d-qt-now-available-in-(...)

    Il est fort probable qu'à long terme, le bureau Unity repose sur Qt et un sous-ensemble de la plateforme GNOME. C'est une stratégie qui peut être payante sur le long terme, Canonical s'intéresse beaucoup aux "opportunistic developers" c-a-d les développeurs qui veulent écrire des petites applications vite fait (bien fait ?) officiellement les hobbyistes mais on peut envisager les pisseurs de code en entreprise. Qt a une doc complète ET cohérente, un environnement de développement intégré complet, la portabilité a peu de frais et cerise sur le gateau, les roadmaps de Nokia et Canonical convergent.
    En plus, avoir un bureau différent, entièrement maitrisé par Canonical est une excellente façon de se démarquer du lot.
    • [^] # Re: Virage à Qt toute, moussaillon !

      Posté par  . Évalué à 6.

      ça met la puce à l'oreille
      Ce qui m'avait mis la puce à l'oreille, c'est le nom: unity.
      Suite à son blog qui disait qu'on pourrait construire gnome sur qt et vu les réactions qu'il avait suscitées, en voyant le nom je m'étais dit "tiens, il veut unifier les 2 lui mêmes puisque les communauté gnome et kde ne veulent pas le faire d'elles mêmes".
      C'est couillu, c'est la chose à faire dès lors que l'on pense que la duplication de travail plus le manque de ressources des projets libres est un problème critique et bien sur, ça ne marchera pas. canonical n'a pas les ressources pour le mener à bien seul parce que c'est énorme comme projet et les autres projets, les destop et les autres distros, ne voudront pas suivre, c'est trop ancré dans leur culture pour les desktop et dans leur intérêt pour les autres distros.

      Ca me rappelle Liberty Linux.
      Plutot que chacun dupliquer le même travail de notre coté, on va travailler ensemble au core d'une distro, et on rajoutera de la valeur ajoutée dans ce qu'on mettra par dessus et les services associés.
      Bien entendu ça n'a pas intéressé les gros une seule seconde. Pourquoi sacrifier de la marque ou de l'identité, c'est à dire souvent des idiosyncrasies, dans un effort où on va être celui qui travaille le plus, pour que ça profite ensuite directement à des concurrents commerciaux? Non, si vous êtes interressés par ce qu'on fait, venez travailler avec nous plutôt, pas l'inverse.

      Donc dans le cas présent, est que kde4 va accepter de travailler avec dconf?
      position de départ, ils détestent dconf:
      http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html
      et maintenant?
      http://aseigo.blogspot.com/2011/01/qt-acceptance-growing-nex(...)
      Si j'ai bien compris: "on veut pas que vous deveniez notre upstream, nous sommes votre upstream, venez travailer avec nous ou à la rigueur dans freedestop, ou dans le cas présent, avec Qt. Donc construisez vos propositions dans QT (sous forme de plugin?) et ne faites pas des libs spéciales pour obtenir des apps Qt "pour ubuntu". PS on veut pas de dconf ni de gtk"
      C'est pas gagné, je suis pas surpris et c'est aussi rationnel comme position que l'autre.

      J'ai pas vu de réactions encore sur le planet gnome mais j'ai trouvé ça:
      http://www.vuntz.net/journal/post/2011/01/18/Cross-distribut(...)
      Il y a de l'espoir, ça semble encore possible de trouver des gens de bonne volonté qui vont travailler ensemble simplement à faire des ponts entre les projets. C'est peut être la seule solution possible, un mouvement grassroot de devs qui disent "on en a marre de réinventer les mêmes roues", mais bon pour l'instant, c'est plutot l'inverse qui est toujours à la mode.
      Pourtant, un des trucs qui m'avaient plus dans le logiciel libre il y a 15 ans, c'est qu'on m'avait dit qu'on pouvait facilement réutiliser des bouts d'autres loiciels plutot que de toujours réinventer la roue. J'attends toujours de voir cette promesse se réaliser.
      • [^] # Re: Virage à Qt toute, moussaillon !

        Posté par  (site web personnel) . Évalué à 4.

        Ce que propose Vincent Untz est àmha la suite logique du travail qu'il avait entamé au FOSDEM l'année dernière aux côtés d'ennael sur la traduction des descriptions de paquets
        http://archive.fosdem.org/2010/schedule/events/dist_pkg_desc

        (dommage les slides n'ont pas été mis en ligne, il y avait une bonne synthèse du travail upstream que cela nécessite). Pour le "toujours réinventer la roue", je te trouve bien lapidaire :-) (Il y a souvent une bonne raison... et pleins de mauvaises, "c'est la vie").
        • [^] # Re: Virage à Qt toute, moussaillon !

          Posté par  . Évalué à 2.

          Ce que propose Vincent Untz est àmha la suite logique du travail qu'il avait entamé au FOSDEM l'année dernière aux côtés d'ennael sur la traduction des descriptions de paquets
          Gens de bonne volonté.

          Pour le "toujours réinventer la roue", je te trouve bien lapidaire :-) (Il y a souvent une bonne raison... et pleins de mauvaises, "c'est la vie").
          Pourtant, je lance pas de pierre, et je dis bien que je comprends les raisons de chacuns, qu'elles sont aussi rationnelles les unes que les autres, suivant les point de vue. En fait, je trouve qu'il n'y a que de bonnes raisons. C'est le seul moyen de dépasser l'antagonisme pour pouvoir avoir une vue d'ensemble.
      • [^] # Re: Virage à Qt toute, moussaillon !

        Posté par  . Évalué à 2.

        Avoir un systeme de configuration centralisé retirerait un point de la liste ici :
        http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.de(...)
        • [^] # Re: Virage à Qt toute, moussaillon !

          Posté par  . Évalué à 2.

          Rhô, en faire un pauvre commentaire alors que ça méritait largement sa place dans un journal du vendredi. Il n’y a plus aucun respect !

          Morceau choisi :

          « Changing the default sound card if [?! Oo on parle bien pour le bureau ?] you have more than one of them »
        • [^] # Re: Virage à Qt toute, moussaillon !

          Posté par  . Évalué à 3.

          il existe, le système de configuration centralisé. C'est /etc/.
          Windows ne dispose pas d'un système de configuration centralisé.
          ( va trouver comment foutre une lettre sur un disque dur sous Windows 7 , va trouver les journaux systèmes sous Windows 7 , va trouver comment défragmenter sous Windows 7 )

          Sedullus dux et princeps Lemovicum occiditur

          • [^] # Re: Virage à Qt toute, moussaillon !

            Posté par  . Évalué à 2.

            > il existe, le système de configuration centralisé. C'est /etc/.

            Bof, ce n'est pas parce qu'il est plutot de mauvaise fois qu'il faut l'être aussi:
            1) la syntaxe des fichiers dans /etc n'est pas consistente, cohérente
            2) leur gestions non plus puisque la prise en compte des modif peut être très variée (automatique, nécéssite un SIGHUP, reboot)

            Comme tu l'as dit toi même Windows n'a pas vraiment de configuration centralisée, mais Linux non plus, pas la peine de prétendre le contraire..
            • [^] # Re: Virage à Qt toute, moussaillon !

              Posté par  . Évalué à 3.

              1) la syntaxe des fichiers dans /etc n'est pas consistente, cohérente
              2) leur gestions non plus puisque la prise en compte des modif peut être très variée (automatique, nécéssite un SIGHUP, reboot)

              C'était pas la question.

              Sedullus dux et princeps Lemovicum occiditur

            • [^] # Re: Virage à Qt toute, moussaillon !

              Posté par  (site web personnel) . Évalué à 2.

              La pensée unique n'a jamais été une bonne solution. De plus une solution bonne à l'instant t s'avère souvent pas si bonne à t+1.

              Il est très facile avec cfengine par exemple d'écrire quelques règles qui s'adaptent au différent cas.

              Sinon, il y a un module Perl très amusant Config::Model qui a des petits dans sa suite.

              http://sourceforge.net/apps/mediawiki/config-model/
        • [^] # Re: Virage à Qt toute, moussaillon !

          Posté par  . Évalué à 4.

          en fait la majorité des points sont d'une mauvaise fois pas croyable; il additionne les problèmes de toutes les distribs + tous les environnement de burreau + utilisation avancé des machines.

          Par exemple il dit que toute la conf doit pouvoir être faite par interface graphique; j'ai installé mon portable y a 5 jours, j'ai pas tapé une seule ligne de commande, et tout est configuré nickel.
          Difficulté de choisir sa sortie par défaut? Kmix le fait, un clique dans le haut parleur de la boite à miniature. Et je ne parle pas de la capture qui est juste rangé dans un onglet du même kmix

          Pour les imprimantes je dirais qu'il y a plus d'imprimantes non gérés pas win7 que linux mais bon...

          Pour la viedo accélération, j'ai plus de plantage avec vlc/fallout3/assassin creed/fallout new vegas que sous nux.

          Pour qt qui casserai souvent sa backward compatibility, c'est surtout lors du passage du 3 au 4, pas tous les 4 matins (often).

          enfin bref les 4/5 des remarques sont bidons ou ont un comportement pire sous windows.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Je trouve aussi que c'est très bien.

    Posté par  . Évalué à 9.

    Et je vais même réagir un peu, notamment à ton dernier paragraphe (il y a d’autres choses qui m'ont fait bondir, mais passons).

    Toutes ces questions rendent plus floues les perspectives à long terme d'Ubuntu. L'orientation claire et précise qui existait au lancement du projet semble s'être évaporée.
    Si on ajoute à ça le remplacement de Rhythmbox par Banshee et la divergence entre le bureau Unity développé par Canonical et le Shell du futur GNOME 3, on ne peut s'empêcher de penser qu'il y a de l'eau dans le gaz entre Ubuntu et le projet GNOME.


    J'ai le souvenir, mais c'est sans doute un mauvais souvenir d'une mauvaise interprétation puisque j'ai l'air d'êter le seul à penser ça, qu'Ubuntu n'a jamais était une distribution Gnome par destination. L'utilisation de gnome étant circonstanciel : la volonté était de créer une distribution facile d'accès et qui faciliterai la transition depuis l'OS mentionné dans le bug n°1. Gnome s'est alors imposé parce que le noyau fondateur d'Ubuntu a pensé, à ce moment là, que c'était le choix qui répondrais le mieux à ces objectifs. Ce qui a par la suite effacé un peu cette ligne directrice pour moi c'est l'élévation au rang de spin-off officiels les variante K et X et compagnie.

    De même, jamais, à ma connaissance, Shuttleworth a dit "on ne délivrera que des application GTK/Gnome". Il a dit un truc du genre, "on prendra les meilleurs application (au sens centrée sur l'utilisateur et non pas performance/fonctionnalité) disponibles et nous n'en maintiendront qu'une pour chaque tâche". Et d'ajouter, "libre à la communauté de proposer autant d'alternative qu'elle veut". Ce qui est étonnant, et sans verser dans la polémique, c'est qu'il y a quelques applications Qt/KDE vraiment bien pensées et réalisées (mieux que leurs équivalents GTK/Gnome donc) qui n'ont pas étaient intégrées avant. Ce qui aurait été cohérent avec ce que je comprend du projet.

    Par ailleurs, je ne crois pas qu'il y ait de l'eaud ans le gaz avec Gnome, simplement, ce projet a fait quelques choix récemment qui n'ont pas était jugé comme allant dans la même direction qu'Ubuntu. Licence libre tout ça, Ubuntu a parfaitement le droit de choisir les composants qu'ils veulent garder et de trouver un remplaçant pour les autres. Parce que finalement, c'est toujours ce qu'à fait Ubuntu, un gros travail sur l'intégration et l'eye-candy en laissant aux autres (lire l'upstream) le soin de faire de l'upstream. Ça leur a souvent été repproché, mais je pense que quand on fait bien un truc, il vaut essayer de le faire encore mieux plutôt que de se disperser ailleurs (et on a pas tous les moyens d'un Red-hat ou d'un Novell).

    Évidement tout ceci n'est que mon avis et il est vraisemblablement biaisé par ce que j'ai bien voulu comprendre et retenir de ces dernières années d'événements dans l’écosystème.
    • [^] # Re: Je trouve aussi que c'est très bien.

      Posté par  (site web personnel) . Évalué à 7.

      >>> Ubuntu n'a jamais était une distribution Gnome par destination (...) a volonté était de créer une distribution facile d'accès

      Tu as sans doute raison mais on peut arguer que le choix d'un environnement de bureau complet et intégré participe de la facilité d'utilisation. Ubuntu n'a jamais été "GNOME pur jus" car il y avait Firefox à la place d'Epiphany et OOo à la place d'Abiword/Gnuméric...Mais il n'empêche qu'on trouvait quand même une certaine cohérence.
      Je pense que quels que soient les efforts d'intégration on ne pourra pas avoir un produit fini vraiment bien léché si on mixe des applications reposant sur des toolkits complètement différents.

      Si le seul critère est vraiment la qualité intrinsèque de chaque application alors pourquoi est-ce qu'on ne se retrouverait pas avec un immonde gloubiboulga de softs GtK/GNOME plus des softs Qt/KDE plus des softs Tcl/Tk plus des softs Java/SWING plus des softs UNO/OOo plus des softs EFL/Enlightenment, etc ?

      >>> il y a d’autres choses qui m'ont fait bondir, mais passons

      Au contraire, n'hésite pas ! C'est ma tentative de troll du mardi alors ce serait bête de gâcher ;-)
      • [^] # Re: Je trouve aussi que c'est très bien.

        Posté par  . Évalué à 3.

        >>Si le seul critère est vraiment la qualité intrinsèque de chaque application alors pourquoi est-ce qu'on ne se retrouverait pas avec un immonde gloubiboulga de softs GtK/GNOME plus des softs Qt/KDE plus des softs Tcl/Tk plus des softs Java/SWING plus des softs UNO/OOo plus des softs EFL/Enlightenment, etc ?

        Ca me rappel les premières distributions linux : on avait tous les softs en X exemplaires.
        • [^] # Re: Je trouve aussi que c'est très bien.

          Posté par  . Évalué à 2.

          >> Ca me rappel les premières distributions linux : on avait tous les softs en X exemplaires. <<

          Avec les problèmes de copier/coller quand les toolkits n'étaient pas bien compatible, de look n'feel inconsistent, etc.

          Et depuis Gnome et KDE sont devenu de + en + "enveloppant" donc même s'il y a eu un effort d'unification je doute que ce soit beaucoup mieux maintenant..
      • [^] # Re: Je trouve aussi que c'est très bien.

        Posté par  . Évalué à 3.

        Si le seul critère est vraiment la qualité intrinsèque de chaque application alors pourquoi est-ce qu'on ne se retrouverait pas avec un immonde gloubiboulga de softs GtK/GNOME plus des softs Qt/KDE plus des softs Tcl/Tk plus des softs Java/SWING plus des softs UNO/OOo plus des softs EFL/Enlightenment, etc ?

        Allons plus loin, tout le monde sait qu'il n'y a que les applications écrites en Objective-C qui valent la peine. Mieux, une seule config pour les gouverner tous !

        Je m'emporte, je m'emporte...
  • # Il faut résonner en terme de Toolkit et non en tant que DE

    Posté par  . Évalué à 5.

    Pour moi, Mark s'est rendu compte que Qt avait beaucoup d'avantages et de cohérence dans l'API par rapport à GTK, et le passage à la licence LGPL a dû finir de le convaincre que c'était un bon choix.

    La différence notable entre KDE et Gnome est au niveau philosophie d'un Desktop Environnement et non du toolkit, ça ne me choque pas de faire un Gnome avec Qt.
  • # Ce n'est pas nouveau

    Posté par  (site web personnel) . Évalué à 3.

    Cela fait un moment de Mark fait un appel du pied à Qt, cf cet article de juillet 2008:
    http://derstandard.at/3413801/Shuttleworth-Apple-is-driving-(...) (voir page 2):

    Shuttleworth: Well, I think it would be perfectly possible to deliver the values of GNOME on top of Qt. There are licensing issues, GNOME is very much built on the LGPL, allowing companies to build their own products on a free software system, giving them some freedom and flexibility in their choice of licensing.

    Oui, c'est clair que que ça chatouille Shuttleworth de voir GNOME passer à Qt, tout simplement parce que derrière Qt, il y a Nokia, et que c'est du lourd par rapport aux quelques boîtes derrière GTK+. GTK qui à peu près à la même époque peinait par manque de mainteneurs.
    • [^] # Re: Ce n'est pas nouveau

      Posté par  . Évalué à 4.

      Cela n'a probablement rien avoir avec Nokia mais plutot a la qualite du toolkits. Il y a un monde entre les deux et Gtk cours toujours apres Qt. Cela a ete le cas depuis le debut et cela l'est encore malgre le fait que l'enorme majorite des distributions proposent par defaut un bureau Gnome (les bureaux KDE etant un spin-off du bureau principal avec beaucoup moins de devs et beaucoup moins de finitions). On peut d'ailleurs se demander comment avec si peu de moyens, en comparaison, ils arrivent a faire truc d'une tel qualite!

      Apres question gout je trouve Gnome tres moyen (c'est tres personnel vu que c'est une impression) quel que soit le theme et surtout passer par "regedit" pour pouvoir faire un tout petit peu de configuration je trouve ca immonde!
      • [^] # Re: Ce n'est pas nouveau

        Posté par  (site web personnel) . Évalué à 1.

        et surtout passer par "regedit" pour pouvoir faire un tout petit peu de configuration je trouve ca immonde!

        C'est ballot, c'est une des choses que j'apprécie le plus, et qui permet de sortir les fonctionnalités avancées hors de l'interface graphique, afin de la garder simple (et pas simpliste). De plus, contrairement à la base de registres Windows, gconf documente toutes les clés, et chaque information est traduite dans la langue de l'utilisateur. On est loin du truc obscur qu'est regedit...
        • [^] # Re: Ce n'est pas nouveau

          Posté par  . Évalué à 1.

          Lorsque tu cherches a changer un comportement particulier que tu es sur que cela doit etre faisable (remettre les icons dans le menu par exemple) et que tu ne connais pas la cle et que les termes de recherches auxquels tu penses ne donnent rien, tu fais comment? Tu te tapes la lecture de toutes les cles et leurs docs?

          Personnellement je prefere de tres tres loin systemconfig meme si des fois il y a des trucs pas tres logique comme "Comportement Web" pour configurer les bureaux virtuels (mais je soupconne que c'est une "coquille" introduite par les traductions kubuntu (kde 4.6rc).
          • [^] # Re: Ce n'est pas nouveau

            Posté par  . Évalué à 2.

            Personnellement je prefere de tres tres loin systemconfig meme si des fois il y a des trucs pas tres logique comme "Comportement Web" pour configurer les bureaux virtuels (mais je soupconne que c'est une "coquille" introduite par les traductions kubuntu (kde 4.6rc).

            C'était un bug dans la traduction officielle de KDE pour la version 4.6, ça a été corrigé.

            « 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: Ce n'est pas nouveau

            Posté par  . Évalué à 2.

            Oui, mais, on pourrait très bien avoir un programme de type "systemconfig" au dessus de dconf.

            Dconf, ça n'est pas l'interface de type "regedit" qu'on voit quand on veut l'éditer sous gnome. Dconf, c'est une interface centralisée de stockage de configuration sous forme binaire avec une API plutôt bien foutue. C'est très bas niveau et c'est plutôt efficace. En tout cas, c'est plus efficace que le stockage sous forme de fichiers textes éparses de KDE.

            En faite, à mes yeux, ce serait un vrai progrès que KDE utilise dconf tout en conservant l'interface de configuration actuelle.
            • [^] # Re: Ce n'est pas nouveau

              Posté par  (site web personnel) . Évalué à 6.

              Enfin, lorsque j'entends parler de configuration au format binaire, je fuis... En plus, il y a un service associé, l'objectif est vraiment de faire pire que Microsoft ?

              La base de registre est une terrible daube ou on mélange paramètre de configuration et variable de programme.

              Les paramètres de configuration n'ont absolument pas besoin de service (daemon) puisque chargés une seule fois au lancement de l'application et modifiés très rarement. Les anciens bureaux avait un bouton 'Restart' pour les relancer si on changeait la configuration, c'est moins sexy mais à mon sens tout aussi fonctionnel et bien moins dangereux que d'avoir des paramètres variables qui se propagent instantanément à toutes les applications.

              Mais ou sont les principes d'UNIX de faire simple, par couche avec des applications pères fils bien séparées !
              • [^] # Re: Ce n'est pas nouveau

                Posté par  . Évalué à 2.

                Les paramètres de configuration n'ont absolument pas besoin de service (daemon) puisque chargés une seule fois au lancement de l'application et modifiés très rarement

                Faux. Il y a pleins d'exemples de paramètres modifés régulièrement, comme par exemple la configuration proxy, qui dépend de l'endroit où je suis connecté.

                Et puis si avec ton environnement je dois relancer ma session à chaque fois que je change de fond d'écran, non merci, je retourne sous GNOME…

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

                • [^] # Re: Ce n'est pas nouveau

                  Posté par  (site web personnel) . Évalué à 1.

                  C'est sur qu'au cours d'une session, le paramètre du proxy change tout le temps... Et puis, si le proxy dépend du type de la connexion, c'est bien un truc à régler en central ou à récupérer via dhcp qui peux très bien être gérer par une variable d'environnement (et en plus, cela marche très bien).

                  Quand au fond d'écran, il suffit de lancer un programme pour le changer. A une époque, on utilisais xsetroot. Bref, pas besoin de base de registre pour faire cela. Surtout, c'est bien un paramètre dont les applications tierce n'ont que faire.

                  Bref, tu donnes deux mauvais exemples
                  • [^] # Re: Ce n'est pas nouveau

                    Posté par  . Évalué à 2.

                    C'est sur qu'au cours d'une session, le paramètre du proxy change tout le temps... Et puis, si le proxy dépend du type de la connexion, c'est bien un truc à régler en central ou à récupérer via dhcp qui peux très bien être gérer par une variable d'environnement (et en plus, cela marche très bien).

                    Non, ça peut dépendre de ce que l'utilisateur veut faire. Je prend cet exemple en connaissance de cause, puisque c'est mon cas : selon le proxy que j'utilise, je n'ai pas accès aux mêmes choses.

                    De plus, avec l'hibernation, on peut changer d'endroit sans fermer sa session, donc oui, il m'arrive fréquemment de changer de proxy au cours de la même session.


                    Quand au fond d'écran, il suffit de lancer un programme pour le changer. A une époque, on utilisais xsetroot. Bref, pas besoin de base de registre pour faire cela. Surtout, c'est bien un paramètre dont les applications tierce n'ont que faire.

                    Déjà, sous GNOME, ce n'est pas une application que tu lances. C'est Nautilus qui le gère, et lorsque la clef change, il est en notifié pour actualiser l'affichage.

                    Et non, ce n'est pas un paramètre que les autres applications peuvent ignorer, tout simplement parce qu'elles peuvent être plusieurs à le définir : je peux le faire depuis l'applet Apparence comme je peux afficher mes photos avec Eog ou Shotwell, où c'est tout de même plus pratique si dans l'appli elle-même je peux me dire « tiens, je vais mettre celle-ci en fond d'écran ».

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

                    • [^] # Re: Ce n'est pas nouveau

                      Posté par  (site web personnel) . Évalué à 2.

                      Tu as une utilisation avancée du proxy et les programmes surchargent le paramétrage global. As-tu vraiment besoin de changer le proxy globalement pour toutes les applications à tout instant, car si elles ont toutes les mêmes proxy à un instant t, c'est bien un paramètre système.

                      Pour qui est du fond d'écran, je sais que sous gnome c'est nautilus qui fait cela ce qui a mon sens est idiot car n'a rien à voir avec un gestionnaire de fichier et fait dépendre un truc visuel global d'un gestionnaire de fichier particulier. Enfin, cela fait longtemps que j'ai quitté GNOME car je ne suis pas fanat de la direction qu'ils prennent.

                      Le soucis est que GNOME est conçu en suivant la trace des autres, Windows et MacOSX. Donc si tu veux copier les autres, tu risques de te retrouver dans les mêmes travers.

                      Rien n'empêche plusieurs programmes de lancer xsetroot ou un équivalent pour changer de fond d'écran, il n'y aucun besoin d'un gestionnaire d'évènement de type variable globale pour cette problématique. Le dernier programme qui paramètre gagne, point final.

                      Je pense personnellement qu'il y a d'autres voies possibles. Je ne dis pas qu'il ne faut absolument pas de bus de type d-bus couplé à gconf, je pense qu'il ne sers à rien d'en abuser et qu'au final, cela n'apporte pas grand chose si ce n'est de la complexité et beaucoup de dangerosité.

                      Le modèle de base d'UNIX des processus père fils et des variables d'environnements transmissibles permet de faire beaucoup. Dans les cas pointus, il est possible d'aller au delà de ce modèle simple. Ce n'est pas la peine non plus d'oublier ce modèle simple pour tout mettre en global !

                      Pour ce qui est du réveil, c'est comme pour un 'ReStart' d'environnement de bureau, tu peux très bien envoyer un signal CONT via kill ou équivalent aux applications pour prendre en compte un réveil.

                      On avait des choses simples qui marchait bien comme 'newgrp' qui ne sont quasiment plus utilisable dans ce paradigme global, idem avec un gestion de l'umask... On n'a plus cette notion de container et d'héritage de l'OS. Les applications ré-implémentent la gestion des onglets, du threading, du sandboxing... quand à avoir un comportement différent en fonction de la vie de l'application et de l'histoire de ses parents, ce n'est plus guère possible. Personnellement, j'aurais préféré que toute cette énergie soit mise dès le début dans le coeur de l'OS.
            • [^] # Re: Ce n'est pas nouveau

              Posté par  . Évalué à 5.

              En quoi est-ce plus efficace?

              Tout ce qui s'apparente a une base de registre me donne de l'urticaire. J'aime bien les fichiers textes pour aller pouvoir bidouiller dedans quand je le souhaite pout tel ou tel raison. Desole je parle beaucoup moins bien le binaire.
              • [^] # Re: Ce n'est pas nouveau

                Posté par  . Évalué à 1.

                > J'aime bien les fichiers textes pour aller pouvoir bidouiller dedans quand je le souhaite pour tel ou tel raison.

                J'aime bien aussi quand la configuration a été pensé pour et que ça a un sens.

                Mais là, on parle de KDE. Rien que l'idée d'aller m'aventurer dans l'arborescence de configurations me donne la nausée. C'est horrible, on ne retrouve rien et les fichiers sont
                vides de commentaires. Enfin, ça, c'est quand ils existent parce que par défaut ils ne sont pas créés.

                Donc, bon, comme c'est fait pour se configurer en mode graphique de toute façon, autant les enregistrer en binaire et éviter de devoir faire le parsing à chaque lancement. Et puis bon, tu parles moins bien le binaire mais il existe des outils au-dessus pour pouvoir les éditer : cf. gconf et systemconfig.
            • [^] # Re: Ce n'est pas nouveau

              Posté par  (site web personnel) . Évalué à 2.

              <quelques reserve car je peux me planter>

              KDE à une couche qui gere les configurations, Kconfig, qui est utilisé par les applis KDE, systemsettings... .

              Si on modifie Kconfig pour gerer cela dans dconf, allégeant kconfig au passage, les applis ne serait pas a modifier....

              Mais cela impliquerai que dconf sache faire tout ce que kconfig sait faire. Est-ce le cas?

              Cela implique également que les mainteneurs de Kconfig soit d'accord. Le sont-ils?

              </quelques reserve car je peux me planter>
              • [^] # Re: Ce n'est pas nouveau

                Posté par  . Évalué à 2.

                Il y a eu au moins eu un précédent avec dbus.

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

  • # question

    Posté par  (Mastodon) . Évalué à -2.

    >Est-ce que Kubuntu n'est pas justement fait pour les gens qui préfèrent KDE ?
    Est ce que Kubuntu n'est pas justement fait pour ... tous ?
  • # Ne réveillez pas un troll qui s'endort

    Posté par  . Évalué à 2.

    J'ai vu passer une petite analyse d'un compère DLFPien sur Planet Libre et j'aimerais vous la partager:

    http://www.planet-libre.org/index.php#post8378

    Je rejoins son opinion à plein de niveaux:
    supériorité technique de Qt sur Gtk, incohérence des bureaux mainstream lié au modèle "bazar", MS parle de Qt pas de KDE, ...

Suivre le flux des commentaires

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