Journal Nouvelle version de Cinnamon, le fork de Gnome-shell de Linux Mint

Posté par . Licence CC by-sa
Tags :
14
23
jan.
2012

Bonjour à tous,

Je vous écris ce bref journal pour vous annoncer la sortie de la version 1.2 de Cinnamon. Pour ceux qui ne connaissent pas encore Cinnamon, c'est un fork de Gnome-shell écrit par Clément Lefebvre, le créateur de Linux Mint, qui devrait être l'interface principale de Linux Mint 13, à sortir au printemps.

La version 1.2 de Cinnamon est présentée par Lefebvre comme étant stable. Quelles nouveautés depuis la dernière version ? Entre autres :
- L'outil cinnamon-settings permet de modifier la position du panel
- apparition des plugins (différents des extensions car pourront à terme être déplacés comme sous Gnome 2)
- nouveaux thèmes, dont Minty, que je trouve très joli
- apparition des effets de bureau type Compiz

Le tout me paraît pour l'instant aussi stable que joli. Si vous voulez le tester, des paquets existent pour Linux Mint, Ubuntu, Arch (dans l'AUR) et Fedora.

Sous Mint, il suffit d'installer cinnamon et cinnamon-session depuis le dépôt officiel.

Annonce des nouveautés : http://cinnamon.linuxmint.com/?p=119
PPA non-officiel pour Ubuntu : https://launchpad.net/~merlwiz79/+archive/cinnamon-ppa

  • # heuu

    Posté par . Évalué à 9.

    Cela parait une bien meilleure idée de forker gnome-shell tout en bénéficiant des libs de gnome3 plutôt que forker gnome2 avec mate qui a toutes les peines du monde à fonctionner correctement.

    Par contre, aujourd'hui on voit fleurir tout un tas d'extensions autour de gnome-shell qui est censé être super scriptable. La question est donc: pourquoi 'cinnamon' ne peut-il pas être un script au dessus de gnome-shell ? De tous les scripts que j'ai vu, je n'en ai pas vraiment vu un qui restaure le comportement des virtual desktops à "l'ancienne". Donc ne serait il pas intelligent de contribuer à l'"extendabilité" de gnome-shell afin de pouvoir faire des extensions qui ont vraiment les capacités de modifier plus profondément son comportement ?

    • [^] # Re: heuu

      Posté par . Évalué à 3.

      J'en rajoute une dose, étant un fork de gnome3, pourquoi ne pas avoir une certaine compatibilité entre les 2 projets ? Il me semble que gnome-shell a déjà les effets de type compiz depuis un certain temps, comment se fait-il qu'il y ait besoin de redévelopper cette partie la ?

    • [^] # Re: heuu

      Posté par . Évalué à 10.

      Donc ne serait il pas intelligent de contribuer à l'"extendabilité" de gnome-shell afin de pouvoir faire des extensions qui ont vraiment les capacités de modifier plus profondément son comportement ?

      Pour pouvoir contribuer faudrait que les devs Gnome soit legerement plus ouvert mais bon cela changera dans la prochaine ere peut etre.

    • [^] # Re: heuu

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

      Il me semble, je ne retrouve plus l'annonce qui le dit, que la décision de forker gnome-shell a été prise parce que le système d'extension ne permettait pas d'aller assez loin au goût des développeurs de Mint.

    • [^] # Re: heuu

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

      Quand on voit certains commentaires de Owen Taylor (mainteneur de Gnome Shell), ça fait plaisir d'avoir un système avec autant de customisation:
      https://bugzilla.gnome.org/show_bug.cgi?id=647686#c2

      Globalement, j'ai pas vu beaucoup de développeurs de Gnome Shell parler à fond de possibilités de customisation. C'est plutôt "on fait une interface pour les tablettes, laisse-nous faire de toute façon tu comprends rien".

      • [^] # Re: heuu

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

        je pige, tu es sur d'avoir donné le bon lien ?

        Car ici, j'ai le sentiment qu'ils font comme le kernel, et déclare "on peut pas garantir la stabilité des interfaces internes".

        • [^] # Re: heuu

          Posté par . Évalué à 5.

          Ben apparemment, cela concerne les interfaces permettant de coder des thèmes :

          From the perspective of the GNOME Shell team, GNOME Shell themes are both not
          interesting and not supportable ... we cannot commit to any stability of the
          CSS class names or actor hierarchy

          Donc a priori les thèmes tierce-partie pour Gnome Shell (s'il y en a) vont vite être obsolètes.

          • [^] # Re: heuu

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

            De toute façons dans la logique Gnome-shell devs, si le thème est pas noir, c'est de la merde vu que ca casse l'experience utilisateur... Donc, vu qu'un thème tout noir ou un thème tout noir c'est pareil, pourquoi avoir des themes...

    • [^] # Re: heuu

      Posté par . Évalué à -4.

      Gnome-Shell n'a pas besoin d'être forké, la 3.2 + extensions.gnome.org fait excellement bien le boulot.

  • # Commentaires

    Posté par . Évalué à 2. Dernière modification le 23/01/12 à 22:40.

    J'ai eu envie de tester, vu que Gnome Shell bugge un peu chez moi, en plus de mettre un long moment à se lancer (autant que pour booter la machine), qu'il y a trop de trolls sur les développeurs, et que les extensions c'est pas encore ça.

    Malheureusement, impossible de langer l'outil de configuration, une trace Python me signale que Arch n'est pas pris en compte (je teste la version Git) :

    Error enabling NTP: OS variant not supported

    Je me dit pas grave, je vais configurer ça à la main, mais je n'ai pas pu trouver de documentation pour ça sur le site web.

    J'ai regardé dans les sources, le README est un peu bref. Il m'apprend juste que le logiciel est sous GPLv2+ (une info qui n'est pas sur le site web non plus), je me demande pourquoi pas GPLv3+, et je ne trouve pas de répertoire doc/.

    J'ai cherché le gestionnaire de bogues. Il n'est pas indiqué dans le site web. Enfin si, il faut lire un des commentaires pour le trouver. Malheureusement, le logiciel utilise la forge propriétaire GitHub qui me demande de m'inscrire pour signaler un bug (!).

    Voilà, ça à l'air cool, mais ça manque encore un peu de gestion de projet. J'espère qu'un paquet pour la version 1.2 sera bientôt dans AUR ! Bonne continuation à Cinnamon.

    • [^] # Re: Commentaires

      Posté par . Évalué à 2.

      Tu peux aussi installer cinnamon-git depuis l'AUR ! Ça tourne nickel.

    • [^] # Re: Commentaires

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

      Je trouve ça logique de s'inscrire pour signaler un bug. C'est pas un wiki non plus.

      • [^] # Re: Commentaires

        Posté par . Évalué à 1.

        Sauf que quand tu veux poster des rapports ou des souhaits ou des patchs pour les logiciels que tu utilises, plusieurs centaines, ça fait quand même un nombre incroyable de comptes à ouvrir. Plusieurs dizaines sachant que la plupart sont centralisés. C'est courant de devoir s'inscrire pour faire un rapport de bug, mais c'est loin de faciliter les contributions.

        • [^] # Re: Commentaires

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

          Dans ce cas tu viens finalement de donner un argument fort à la centralisation sur des plateformes comme github : un seul compte me permet de rapporter des bugs, demandes, envoyer des patchs, etc à plein de logiciels différents, tous héberger à un seul endroit.
          Si chaque programme avait son propre bug tracker ça serait pire.

          • [^] # Re: Commentaires

            Posté par . Évalué à 2.

            Au contraire, une plateforme centralisée ne peut se permettre de donner des droits d’écriture au tout-venant car le risque de spam est plus important (plus de personnes potentiellement touchée). Alors qu’un petit projet avec son propre bug tracker peut ouvrir aux connexions anonymes les droits nécessaires.

            • [^] # Re: Commentaires

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

              Mouai, enfin il y a vraiment très peu de projets où tu peux écrire, soumettre un patch ou un bug sans être enregistré.
              La version anonyme n'existe quasiment pas.
              Là au moins on mutualise la connexion.

            • [^] # Re: Commentaires

              Posté par . Évalué à 5.

              Même pour un projet obscur, le spam arrive à te trouver...
              J'ai du moi même tout verrouiller sur un projet, alors qu'il n'avait déjà pas de contributions, hormis celle des spammeurs.

            • [^] # Re: Commentaires

              Posté par . Évalué à 7.

              Les rapports de bug anonymes c'est une mauvaise idée, car le rapporteur anonyme n'aura pas de notification quand le développeur lui posera une question.
              Or beaucoup de bugs nécessitent un minimum d'interaction avec le rapporteur pour diagnostiquer le problème, et discuter d'une solution souhaitable.

              • [^] # Re: Commentaires

                Posté par . Évalué à 2.

                Bah tu peux juste mettre un captcha (ou utiliser le même système anti-spam que le formulaire d'inscription), et laisser ton adresse e-mail dans le rapport de bogue.

                • [^] # Re: Commentaires

                  Posté par . Évalué à 1.

                  Oui, mais ça complique la vie des autres parce qu'il faut penser à notifier le type à la main. C'est quand même beaucoup plus pratique quand poster sur un bug envoie automatiquement le message à toutes les personnes concernées.

Suivre le flux des commentaires

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