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 RB . É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 Elfir3 . É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 Albert_ . É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 monde_de_merde . É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 Damien Thébault . É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 Misc (site web personnel) . É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 Antoine . Évalué à 5.
Ben apparemment, cela concerne les interfaces permettant de coder des thèmes :
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 gnumdk (site web personnel) . É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 Gabin . É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 neil . Évalué à 2. Dernière modification le 23 janvier 2012 à 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) :
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 ElVirolo (site web personnel) . Évalué à 2.
Tu peux aussi installer cinnamon-git depuis l'AUR ! Ça tourne nickel.
[^] # Re: Commentaires
Posté par neil . Évalué à 2.
C'est celle que j'utilise.
[^] # Re: Commentaires
Posté par Jeanuel (site web personnel) . Évalué à 7.
Je trouve ça logique de s'inscrire pour signaler un bug. C'est pas un wiki non plus.
[^] # Re: Commentaires
Posté par neil . É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 CrEv (site web personnel) . É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 BB . É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 CrEv (site web personnel) . É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 ecyrbe . É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 Antoine . É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 neil . É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 Antoine . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.