Mate-Desktop est sorti en version 1.10 assez récemment. Un des manques de cette version est la migration annoncée vers GTK3.
Dans une dépêche intéressante sur LinuxFr, on apprend que la migration a été repoussée car les versions successives de GTK3 ont tendances à introduire des changements rendant la migration de Mate Desktop assez laxative en terme de stabilité.
Cependant, Archlinux, la distribution de naissance du projet Mate Desktop est avec la Fedora Linux l’une des rares à proposer des paquets expérimentaux pour Mate-Desktop en GTK3. De plus, si on regarde le statut du développement de la version GTK3, seul trois entrées sont encore en orange, du moins, au 16 juin 2015, au moment où je rédige l’article : mate-panel, mate-notifiction-daemon et mate-control-center.
Des éléments assez chatouilleux, donc.
Étant de nature curieuse, j’ai donc installé une Archlinux avec Xorg et j’ai installé la version GTK3 de Mate-Desktop, qui fêtera ses 4 ans le… 18 juin 2015 ! Déjà 4 ans… Comme le temps passe vite 🙂
Au moment d’installer Mate-Desktop, en lieu et place des groupes mate et mate-extra, j’ai utilisé mate-gtk3 et mate-extra-gtk3.
Pour faire des comparaisons entre les deux versions de Mate Desktop, j’ai installé en parallèle une Archlinux avec Mate-Desktop en GTK2.
J’ai ensuite capturé en vidéo les deux versions. Le but de cette vidéo étant de voir les différences au niveau de l’apparence, de la goumandise mémoire ou encore les quelques bugs graphiques de la version GTK3 qui est encore expérimentale.
La version GTK3 est légèrement plus gourmande (225 Mo au démarrage contre 186 Mo pour la génération précédente). Il y a quelques bugs d’affichages comme dans le panneau d’affichage où les aperçus des thèmes ne s’affichent pas ou encore le réglage des polices qui contiennent des beaux placards noirs au lieu de l’aperçu des polices.
La version GTK3 semble cependant être plus rapide au niveau de l’affichage des menus, même si le lissage des polices apparait comme bizarre. On peut aussi noter que le thème en version gtk3 semble plus uniforme que dans sa version GTK2.
Mis à part le bug bizarre qui me donne des polices d’affichages un peu trop grosse au lancement de la session – sûrement un bug de VirtualBox) – cette préversion de Mate Desktop au format GTK3 est intéressante. Vivement Mate-Desktop 1.12.0 🙂
En général j’aime assez le vert mais avec Mate j’ai pas vraiment d’accroche, j’ai testé quelques jours sans m’attarder, certainement que j’aurais du persévérer mais je suis content que tu nous fasses découvrir cet environnement de bureau qui mériterait un petit changement de couleur.
A pluche.
Le vert, c’est la couleur de l’espoir. Et on peut modifier le thème facilement 😀
Bon et bien voilà, il suffit de tester pour voir que GTK3 n’apporte rien par rapport à GTK2, à part consommer davantage de mémoire!! vilain.
Sinon LXDE c’est vachement bien!! Tu n’en parle pas souvent pourquoi??
N’apporte rien ? Si ce n’est un code plus jeune, mieux maintenu ? C’est vrai, pourquoi utiliser une nouvelle version d’une bibliothèque si l’ancienne est encore fonctionnelle ? 🙂
Pour Lxde, je n’aime pas cet environnement. Je lui préfère LXQt, c’est tout.
Je suis tout à fait d’accord avec toi, pourquoi utiliser une nouvelle version [experimentale] d’une bibliothèque si l’ancienne est encore fonctionnelle ? Bonne question 😉
Je trouve qu’LXDE fonctionne très bien, particulièrement sur les vieilles machines déclarées « obsolètes » pour Window$…
Après, ce qu’on appelle « LXDE » c’est simplement le gestionnaire de fenêtres Openbox auquel on rajoute quelques outils comme Lxsession, Lxpanel, ou encore le petit gestionnaire de fichier PCManFM… Le tout très léger, simple et rapide à mettre en place, même sur une vieille machine! 🙂
Je trouve que ce gestionnaire de fenêtres Openbox fonctionne très bien, très stable, je n’ai jamais eu de soucis avec lui…
C’est Openbox le gestionnaire de fenêtres par défaut d’LXDE, de RazorQT et d’LXQT, on en parle pas assez souvent.
Après, personnellement j’aime bien utiliser LXQT avec Kwin le gestionnaire de fenêtres de KDE, c’est joli…
Peut-on considérer qu’une bibliothèque existant depuis février 2011 (dont 4 ans) est expérimentale ?
Pour Lxde, je sais très bien ce que c’est. Mais j’avoue que je préfère encore Xfce dans ce cas. RazorQT est techniquement mort, remplacé par LXQt.
Et je préfère largement LXQt avec OpenBox en dessous.
Xfce est un environnement complet avec son propre gestionnaire de fenêtres xfwm4 donc il n’est pas exactement dans l
Je suppose que tu as dû avoir une fausse manipulation. Avec Xfce, on peut descendre à 150 ou 200 Mo, tout dépendant du nombre de services en tache de fond.
Kwin est largement plus lourd qu’OpenBox. Si c’est pour avoir quelques beaux effets 3D, autant utiliser un outil comme compton qui sera 15 fois plus léger 🙂
Oups, j’ai appuyé involontairement sur le bouton « Laisser un commentaire » avant de terminer mon message donc je reprend:
Xfce est un environnement complet avec son propre gestionnaire de fenêtres (xfwm4) donc il n’est pas exactement dans la même catégorie qu’LXDE et LXQT.
Openbox est programmé en C ,comme GTK.
Kwin est programmé en C++ , comme LXQT.
Donc LXQT devrait normallement mieux fonctionner avec Kwin qui est plus proche de lui « génétiquement ».
Après chacun ses goûts…
La proximité « génétique » n’empèche pas une lourdeur plus importante.
Si on prend la taille des paquets, sur archlinux, OpenBox pèse 1,2 Mo installé, hors dépendances -> https://www.archlinux.org/packages/community/x86_64/openbox/
Kwin ? 19,3 Mo, en dehors des dépendances -> https://www.archlinux.org/packages/extra/x86_64/kwin/
Soit 17 fois plus sur le disque ?
Quant à Xfwm4 ? 2,1 Mo ! -> https://www.archlinux.org/packages/extra/x86_64/xfwm4/
J’aurais tendance à penser qu’un logiciel qui demande 20 Mo d’espace disque sera toujours plus gourmand en mémoire qu’un logiciel qui n’en pèse à peine plus d’un Mo.
A mon avis si l’objectif est d’utiliser l’environnement LXQT au maximum de ses possibilités alors il faut utiliser le maximum d’applications écrites en C++/QT pour tourner avec lui, donc éviter le mélange C/GTK avec du C++/QT.
Ca me semble logique.
Donc Openbox n’est pas le meilleur choix dans l’absolu pour LXQT, il faudra trouver autre chose.
Peut-être aurait-il été plus logique de continuer à dévelloper la branche LXDE « pur GTK » avec Openbox, et en parrallèle continuer à dévellopper la branche RazorQT en « pur QT » avec un nouveau gestionnaire de fenêtres en QT et tout le reste ?
Pour l’instant je trouve LXQT légèrement « bancal » à cause de ce point précis, mais bon…
LXQt est à l’origine la fusion des équipes de Lxde et RazorQT pour mutualiser les efforts et créer une synergie. De plus, openbox n’est pas une obligation. C’est juste le gestionnaire de fenêtre préféré des codeurs. Libre à l’utilisateur de prendre Pekwm par exemple.
Essayé sur Manjaro et on sent quand même une différence. Manque toujours l’appli météo plus complète et un moyen de passer une application d’un bureau à l’autre en glissant la fenêtre de l’appli.