La gestion des architectures sera toujours gardées, car il y aura bien des paquets (ne fusse que le kernel) qui ne passeront pas avec LLVM, et qui auront besoin de GCC, ou de fichiers non-binaires mais dépendants de l'architecture (il me semble que ça existe, genre des dumps mémoire dépendants de la taille des pages).
Et oui, j'ai oublié de présenter LLVM. Toutes mes excuses à ceux qui se sont sentis perdus.
Je n'ai pas fait de recherches sur l'optimisation du côté de LLVM, j'ai recopié la doc. C'est donc égal à un -O0.
Pour les bibliothèques liées statiquement, hors le fait que je n'aime pas, il devrait être possible de les fournir dans le paquet, puis d'utiliser "clang -o binaire fichiers.s -L. -llib_statique", ou quelque-chose comme ça. C'est un domaine jamais exploré, je vais voir ce que je peux trouver.
Effectivement, c'est là un problème de Debian. J'ai cru lire à un moment que OSSv4 se trouvait dans les dépôts, mais comme Debian est très chipoteur sur les licences, dès que le troll de "propriétarisation" a pointé le bout de son nez, hop, plus de OSS chez Debian.
Et puis, c'est tellement bien expliqué, et tellement simple :
tar -xf archive
cd archive
./configure # qui ne vient pas des autotools d'ailleurs, c'est du fait-main
make
sudo make install
sudo make modules
amd64 désigne, chez Debian, le x86_64. C'est bien un ATOM, mais en 64-bit.
Jeune jeune, peut-être, ça ne fait qu'un an et demi :-° (et je le regrette de temps en temps, de ne pas avoir connu KDE 2, les noyaux 2.4 et 2.2, et d'autres choses un peu plus vieillottes).
Et puis, côté temps perdu, ça m'a pris 2 heures à tout casser pour que ça marche bien, et ça marche encore toujours bien (et avant, j'avais ALSA, qui juste-marche aussi, mais j'avais envie de tester).
Voici le texte du document. On ne sait malheureusement pas mettre les images, et le style est moche.
========================================
Pourquoi GNOME paraît plus léger que KDE
========================================
Le débat entre les utilisateurs de GNOME et ceux de KDE fait beaucoup parler de lui. Chacun avance des arguments qui permettent de valoriser son environnement de bureau, mais peu font une analyse précise sur un point de cette différence.
Ce document va mettre en lumière une petite différence qui fait tout entre les deux bureaux. La réputation de «lourd et complexe» de KDE, et «léger et simple» de GNOME s'explique en fait simplement, très simplement.
KDE complexe ? GNOME frais ?
Les défendeurs de GNOME le répètent suffisemment, leur bureau est plus léger. En tous cas, c'est ce qu'ils disent. Nous n'allons pas ici nous intéresser à la légèreté matérielle (consommation de mémoire, vitesse d'éxécution), mais bien de l'aspect.
En effet, KDE a toujours eu la réputation d'interface complexe et riche en fonctionnalités, très riche, trop riche. De nombreux trolls sont du genre «Non, pour que ça ressemble à KDE, il aurait fallu rajouter des boutons partout et complexifier l'interface».
La question est «Pourquoi ?». Pourquoi est-ce que KDE a une interface qui paraît lourde, et pourquoi GNOME respire tellement.
Les marges, voilà le secret
===========================
Et oui, le problème est tout simple. Voici la petite analyse qui m'a mené à cette conclusion.
Comparons tout d'abord une même fenêtre en GTK (GNOME) et Qt (KDE). La fenêtre choisie a été trouvée sur le site de PackageKit. Elle est toute simple et convient parfaitement :
Maintenant, je prends Qt Designer et essaie de refaire cette fenêtre. Voici ce que ça donne au bout de quelques minutes :
C'est plus ou moins réussi, mais comme on peut s'y attendre (ou pas), cette fenêtre est plus lourde. Plus lourde ? Et oui, elle étouffe un peu plus celui qui la regarde.
À première vue, c'est exactement la même. Les boutons sont les mêmes, ils ont une icône, l'icône de paquet est équivalent, et les contrôles sont placés au même endroit.
Première étape, changeons de thème, et utilisons Cleanlooks, concu pour ressembler à Clearlooks de GTK :
C'est déjà bien mieux. Les boutons sont un peu plus gros, et plus aérés. Les icônes ont également changé. Par contre, ce thème est moins clair que celui de l'image GTK plus haut, mais passons là-dessus.
Et c'est maintenant que ça va devenir intéressant ! Le principe est que cette fenêtre est trop lourde. Éliminer le thème Oxygen a déjà corrigé pas mal de défauts, mais la fenêtre reste encore moins agréable que la version GTK. Pour corriger cela, regardons attentivement la version GTK.
Et oui, elle a quelques caractéristiques :
* Les contrôles sont légers et fins, sauf les boutons qui sont gros
* Il y a beaucoup d'espace entre les contrôles
C'est ce dernier point qui est important. Cet espace permet de limiter le taux information/espace de la fenêtre, et de soulager le cerveau. Le cerveau devant regarder moins de choses, il aime mieux. Allons-y, configurons les marges et rétrécissons cette barre de progression. Retirons également le pourcentage d'avancement qui n'apporte rien :
C'est déjà beaucoup mieux ! Maintenant, toujours pour continuer dans l'allègement, nous allons éclarcir cette fenêtre et ses contrôles, et accessoirement changer de décorations de fenêtres :
Et bien voilà, notre fenêtre Qt est à présent quasiment identique à la version GTK, toute aussi légère du moins !
Et ce que ça donne sous KDE
Maintenant que notre fenêtre est légère, voyons voir ce que les réglages font sur KDE en entier. Pour tester, nous allons prendre une application couverte de boutons, habituellement qualifiée de lourde.
J'ai nommé ... Dolphin . Le résultat est spectaculaire !
Avouez qu'il a vraiment bien maigris. Il est à nouveau utilisable sans se saturer les yeux de détails. Pour information, voici ce que ça donne avec le thème et les décorations de fenêtres Oxygen d'origine :
Conclusion
==========
Voilà, nous avons vu qu'un simple changement de thème permet de rendre KDE léger. Maintenant, le graphique ne fait pas tout, mais voici quelques observations qui vont vous intéresser :
* L'impression de lourdeur de KDE résulte du fait que les fenêtres semblent s'ouvrir lentement. En effet, elles ne font que sembler, car j'ai testé plusieurs fois, elles s'ouvrent quasi-instantanément, aussi bien avec le thème Oxygen qu'avec le thème Cleanlooks.
C'est le cerveau, encore une fois, qui fait des siennes. Quand une fenêtre jailli devant notre regard, le cerveau, avant de se dire «la fenêtre est affichée», la lit dans son entièreté (même si on ne s'en rend pas compte). Chaque détail est pris en compte.
C'est donc là que se trouve le problème. Avec Oxygen, il y a bien trop de détails, ce qui fait que le cerveau prend plus de temps à lire la fenêtre (et d'autant plus que la fenêtre est grande et riche en contrôles, ce que KDE aime bien).
Le passage au thème Cleanlooks permet de simplifier l'apparence des fenêtres, et de les rendres plus facilement gérables par le cerveau (c'était la première étape). Ensuite, en les éclairsissant, on diminue le contraste de ces détails, que le cerveau peut encore oublier. On se concentre donc immédiatement sur l'apparition de la fenêtre, pas son contenu
* Notons tout de même que le thème Oxygen est aussi lourd pour la machine. En effet, il use et abuse de dégradés en tous genres et de vectoriel. Pour avoir lu son code source, je peux vous dire qu'il est déjà sur-optimisé, mais un tel niveau graphique n'est pas atteignable sans compromis, surtout que Oxygen n'utilise pas de pixmaps, ni de SVG. Tout est contruit et dessiné à la volée.
* Le changement de décorations de fenêtres a aussi eu son importance. Les fenêtres sont blanches, et si les décorations sont blanches aussi, on se retrouve avec un gros pâté, que les yeux ont du mal à identifier
Ce changement de thème permet donc de soulager le regard et le processeur, au plus grand bonheur de l'utilisateur. Bien sûr, certains préfèrent Oxygen, mais comme c'est configurable, ce n'est que mieux !
Conclusion finale : Ne jamais juger une application ou un bureau sur un screenshot ou son aspect, ces éléments sont configurables. Les screenshots de KDE sont lourds, car ils suivent la politique du «Un screenshot pour tout montrer». Ceux de GNOME sont par contre plus légers, car ils font un screenshot par chose à montrer (une boîte de configuration, un morceau d'application, etc).
Reproduire cet essai
====================
Pour obtenir un KDE léger comme je vous montre à la fin, les étapes sont extrêment simples :
1. Ouvrir la configuration du système : K»Favoris»Configuration du système
2. Aller dans «Apparence»
3. On se retrouve avec la configuration du style. Choisissez «Cleanlooks» dans la liste des styles
4. Si vous n'en pouvez déjà plus, cliquez sur «Appliquer» pour respirer un coup
5. Allez ensuite dans «Fenêtres» (dans la barre verticale à gauche)
6. Dans la liste déroulante qui contient «Oxygen», sélectionnez «Quartz», puis cliquez sur Ok
Votre bureau respire, mais pas totalement (il est trop sombre). Voici comment l'éclarcir :
1. Rouvrez la configuration du système et allez à nouveau dans «Apparence»
2. Cliquez sur «Couleurs», puis sur l'onglet «Couleurs» (ok, pas exessivement ergonomique, mais vous auriez fait quoi ?)
3. Vous avez une liste de noms avec une couleur en face. Mettez une couleur gris très très clair (quasi blanc), en cliquant sur le jeton de couleur puis en sélectionnant la couleur de votre choix, au éléments «Arrière-plan de fenêtre» et «Arrière-plan de bouton».
4. Cliquez sur Appliquer, et ajustez éventuellement les autres couleurs.
Si tu as un GNOME d'installé, il suffit, dans Configuration du système»Apparence»Style de choisir GTK+ dans la liste. KDE est donc exactement comme GNOME (c'est le principe de QGtkStyle, ça fonctionne super bien).
Si tu n'as pas de GNOME installé, tu utilises le style Cleanlooks, comme décrit à la fin du document.
Bien entendu, ça ne change que l'aspect graphique. Si une application KDE est mal conçue elle-même, on ne peut rien faire. Quoique, en explorant le menu Configuration de chaque application, on découvre avec joie qu'on peut choisir la position des menus et boutons de barre d'outils. Le menu est Configuration»Configurer les barres d'outils
Et encore mieux :D ! Dans /usr/share/kde4/apps/l'application, se trouve un ou plusieurs fichiers .rc. Chaque fichier .rc contient toute l'interface de l'application. Libre à toi de réorganiser ça exactement comme tu veux (supprimer les boutons de barre d'outils qui ne servent à rien, en ajouter d'autres, en déplacer, changer/supprimer les icônes ou le texte, etc). Ça fonctionne comme le menu de configuration des barres d'outils (donc c'est mieux de l'utiliser pour éviter les erreurs et donc le plantage/instabilité de l'application)
Malheureusement, l'astuce des .rc ne fonctionne que pour les menus et les barres d'outils. Heureusement que KDE utilise en majorité ces emplacements.
Comment désinstaller GNOME proprement ? apt-get remove libgtk2.0 marche, mais je perds également toutes mes applis GTK. Supprimer gnome-core ? il en reste un peu, j'ai essayé.
Comment désinstaller KDE ? apt-get remove kdelibs et on n'en parle plus (à la limite, il reste encore oxygen-icon-theme qu'on doit supprimer à la main). On peut aussi supprimer Qt, mais on perd les quelques rares applis Qt qui pourraient être installées.
Ce n'est donc pas de l'intégrisme, simplement, GNOME est connu pour être difficile à désinstaller, donc je ne l'installe pas (j'ai une toute petite partition système, et déjà plein de choses dessus). KDE par contre est facile à désinstaller, et a des dépendances précises (c'était d'ailleurs l'argument avancé quand Slackware a cessé de supporter GNOME)
Et pourquoi pas en PDF ? C'est libre il me semble, et correctement implémenté partout (alors que le .odt nécessite d'installer OpenOffice ou KOffice, ou autre application capable de le lire).
J'aurais bien aimé être objectif sur les temps de chargements, mais il y a plusieurs problèmes :
* Je n'ai pas GNOME d'installé (à la limite, ça s'arrange, mais pour après tout désinstaller, c'est difficile)
* Comment on mesure avec précision le temps de démarrage ? Un time ne se stoppe pas quand la fenêtre est démarrée.
En tous cas, à l'utilisation, tout ce que je peux dire, c'est que l'interface est fluide, ou en tous cas pas gênante. Quand je clique sur le bouton «Répondre» de Kmail, je ne dois pas attendre, la fenêtre s'affiche "tout de suite" (même si pour le CPU, c'est bien plus long).
Ensuite, je ne mélange pas. J'ai justement fait attention dans le document à toujours parler de la légèreté visuelle, et pas d'occupation CPU/Mémoire, sauf aux endroits indiqués.
Pour finir, oui, j'ai transformé KDE en GNOME, et c'était le but. C'était pour montrer que les développeurs ne font pas preuve d'incompétence ergonomique, loin de là, simplement qu'on est tous plus ou moins habitués à GNOME (qui ne l'a pas utilisé, à part ceux qui sont toujours restés sous WindowMaker, Fluxbox, XFCE* et autre ?). Rien n'empêche quelqu'un de développer un thème Qt aussi léger que Cleanlooks, mais différent. Je me suis contenté de trouver «l'astuce magique» qui rend GNOME plus léger visuellement, et de l'appliquer à KDE pour prouver que ça marche.
* Et encore, XFCE utilise GTK et, il me semble, quelques bibliothèques GNOME, donc graphiquement, XFCE est proche de GNOME
La gestion des paquets est un truc à la packages.debian.org . Je l'explique ici : http://www.logram-project.org/fr/node/376 (c'est encore une ancienne version avec plein d'imprécisions, la version actuelle est bien mieux).
Ensuite, il me semble que je ne confonds pas. Le but de Logram, ce sont deux choses :
1. Des applications développées pour KDE et Qt (l'environnement léger que je vous ai déjà présenté utilise Qt, et servira quand il faut pour une raison ou pour une autre un environnement léger de secours). Il y a aussi Confrunner, une application qui affiche une GUI à partir d'un fichier XML (exactement comme Xulrunner, sauf qu'il n'y a pas de JS, et que c'est orienté configuration (chaque contrôle est relié à une entrée de configuration quelque-part)), et Assistant, une documentation visant à prendre le débutant par la main (la doc de KDE est très bien, mais un peu sèche par endroits, et ce n'est pas son but d'apprendre à se servir d'un ordinateur).
2. Une distribution, pour empaqueter et proposer tout ça. La distribution est basée sur Debian, et ne touche pas trop au KDE de Debian. Elle propose ses artworks, et des paquets pour toutes les applis Logram que j'ai cité. Pour tester : ajouter "deb http://archive.logram-project.org Paradise main" dans son sources.list, puis "apt-get install logram-assistant logram-presentation logram-doc2html logram-confrunner logram-ksplash-theme logram-kdm-theme logram-wallpaper".
La distribution est très limitée, mais comme dit plus haut, les outils vont fleurir (envoi d'un fichier en un clic sur son compte sur le site web, pour un partage rapide sans devoir chercher Megaupload, omploader et d'autres. Non, directement depuis Konqueror, on pourra envoyer ses fichiers :) ). On trouvera dans ces outils également le gestionnaire de paquets/mise à jour (ou PackageKit si sa version KDE évolue bien), des outils de configuration graphique (j'ai pas développé confrunner pour rien), etc.
Encore pour la distrib, ce n'est pas une simple copie de Debian avec des artworks. On a déjà une version de GRUB2 qui propose de définir le mode graphique du noyau (set gfxpayload pour les connaisseurs). Je dois d'ailleurs encore proposer le patch à Debian. Il y a aussi du travail qui a été fait sur le temps de démarrage (ma Debian semi-Logram prend 12 secondes entre le GRUB et KDM).
Dans le wiki de Debian, ils dénoncent que PackageKit lui-même ne convient pas (et ils le démontrent en plusieurs point). PackageKit corrigera bien lui-même ces problèmes, mais il manque actuellement un équivalent de Synaptic et gnome-app-install pour KDE.
Même sous Debian, KDE est utilisable, et pleinement utilisable. Simplement, dans mon "utilisable", ça veut dire en environnement plus que complet, où tous les outils sont KDE.
Par exemple, j'ai besoin de partitionner mon disque dur. Il existe GParted. Mais qu'en est-il de KPartitionManager, sorti en version stable il y a quelques temps ? Il faudrait que quelqu'un rassemble tout ça dans un paquet (typiquement le contenu d'un LiveCD, pas un .deb), pour que les gens découvrent des applis KDE formidables mais peu connue.
C'est aussi un service qu'on rend aux applis. Pour reprendre l'exemple de KPartitionManager, il a été abandonné pendant quelque temps. S'il avait été aussi connu que son équivalent GNOME, GParted, cela ne serait pas arrivé.
Pour le wiki, effectivement, absolument tout existe. Simplement, vas-y pour intégrer un wiki, un forum, une gestion des paquets et une gestion des demandes. Par "intégrer", je demande bien plus qu'un design partagé.
Non, ce site ressemble plus à une "grosse forge" : les utilisateurs sont partagés, les composants sont partagés (la même template permet d'afficher un topic et les commentaires d'une demande par exemple), les groupes/droits et autres sont partagés.
Ce site joue aussi le jeu du "je propose largement plus que le minimum". Les forges proposent habituellement un forum, mais est-ce vraiment on bon forum ? Je n'ai absolument pas la prétention de rivaliser avec phpBB, c'est impossible, mais mon forum au moins gère le lu/non-lu (contrairement à celui de Drupal et de Redmine par exemple).
C'est donc une intégration poussée qui me motive. J'aurais très bien pu assembler phpBB, Mediawiki, Bugzilla pour obtenir un site ressemblant à celui de KDE (Drupal pour la page d'accueil, websvn, mediawiki, fluxBB je crois, etc).
Et puis, tout cela sera redistribué sous licence Libre, donc ça ne peut pas faire de mal.
Oui, c'est lourd de lancer du KDE sous GNOME, mais je parle justement de Qt.
Qt, c'est moins de 20Mio de mémoire partagée. En plus, Qt est complet, donc chaque application est moins lourde en code (en mémoire, je sais pas).
Bref, si au lieu de dire «Je fais en GTK pour que mon appli tourne sur Linux/Windows», ce serait bien que les gens disent «Je vais mon appli en Qt pour qu'elle tourne sous Linux et Windows». Une appli GTK n'est compatible qu'avec "une moitié" de Linux, une appli Qt est compatible avec tout.
Pour le fait que GTK ne dépend pas de GNOME, c'est justement ce que je lui reproche. C'est bien simple, GNOME a GTK sous la main. Tout ce qu'ils veulent mettre dans GTK, ils l'y mettent. Même un GTK "nu" se retrouve bourré de GNOME dedans.
Puis, il y a aussi les distribs comme Ubuntu qui ne savent pas empaqueter. J'installe Inkscape, foutu programme en GTK de nouveau, et comme Ubuntu a dit «Mouai, GTK sans gvfs, ça pue». Hop, je me prend gvfs, gnome-core. Ubuntu a dit «gnome-core sans gnome-panel, ça pue». Hop, j'ai gnome-panel, gnome-session, et tout un tas de trucs. J'ai donc plusieurs centaines de Mio pris par un truc que je ne vais pas utiliser, mais mon support KIO, et une intégration graphique, non, je n'ai pas.
Du côté de KDE maintenant. Le développement de Qt vise l'extrême portabilité, donc sous Windows, Qt doit être du Windows natif (donc utiliser les boîtes de dialogue natives, les contrôles natifs, etc). Qt manque donc de certaines fonctionnalité pour Linux (au hasard : les icônes Freedesktop). C'est là que KDE intervient, et nous fourni les kdelibs, surcouche à Qt.
Effectivement, si KDE avait forké Qt, tout cela serait dans Qt, et Qt serait bien plus lourd. Là, effectivement, Qt sous GNOME serait embêtant. Actuellement, c'est GTK qui nous fait le coup de tout intégrer, y compris ce qu'on ne veut pas.
Première partie du commentaire (oui, je réponds à l'envers)
gtk-qt-engine, c'est pas vraiment excellent. En gros, on a des énormes boutons au look Oxygen à quelques endroits, les onglets sont totalement pétés, et tout ce qui est taille ne marche plus (boutons trop petits, etc).
Pour les notifications, il y a quelques normes Freedesktop, mais Freedesktop se limite vraiment au strict minimum (juste pour que les applications "marchent" dans le sens "ne plantent pas au démarrage"). Ces spécifications sont donc très limitées dans les possibilités qu'elles offrent, et les deux DE se chargent de les dépasser, sauf que c'est plus une norme alors.
(mais ça j'ai pas mis dans le journal pour éviter qu'il se fasse moinsser pour une seule phrase)
Le but de Logram (une distrib que je compte développer) est de proposer un KDE utilisable, c'est à dire pas un KDE qui marchotte plus ou moins (empaquetage douteux, et le problème de ce journal).
Logram, c'est aussi pour le Libre en général. Par exemple, je développe son site web actuellement, qui regroupe tout ce qu'une distrib a besoin : wiki, forum, gestion des paquets, demande, websvn, etc. Tout ceci, je le fais générique (même la gestion des paquets utilise une BDD. Le seul truc distro-dependant dedans, ce sont les 100 lignes du script d'importation d'un dépôt APT).
Bref, ce site sera placé sous GPL et réutilisable par tout le monde.
Le lien avec le journal ? C'est que justement, je compte développer un gestionnaire de paquets graphique pour KDE, utilisant APT (si on veut du portable, on a déjà KPackageKit qui va bien finir par tourner). Pour ne pas réinventer la roue, je vais intégrer le site dedans (note des paquets, commentaires, informations supplémentaires, stats sur le site sur combien de personnes utilisent un paquet, etc).
Et ce qui est bien en plus, c'est que ce ne sera pas dépendant de Logram. Toute distribution basée sur Debian et disposant d'un administrateur sachant se servir d'un site web pourra utiliser le site, et le gestionnaire de paquets. Tout le monde est content :) .
Malheureusement, ça ne convient que pour les applications «normales», ou simples.
Par exemple, k3b est une appli qui utilise les kdelibs, et peut-être quelques autres choses. Par contre, elle ne passe pas son temps à lancer des services. Konqueror, ou Plasma, aurait déjà été bien plus difficile à utiliser sous GNOME.
Ici, avec PackageKit, c'est un calvaire sous KDE :
- Il utilise intensivement les notifications GNOME (voir screenshots), et donc, sous KDE, on ne voit rien
- Il est fondu avec gnome-power-managment (voir screens aussi), et donc ne marche pas bien sous KDE
Dire qu'une application marche sur un autre DE, c'est normalement qu'elle marche en entier, ou presque. Ici, PackageKit perd vraiment beaucoup d'intérêt. Maintenant, j'avoue que Synaptic marche très bien sous KDE, et que je l'ai même utilisé à un moment.
C'est plus cette mode du "tout en GTK" qui me perturbe. GTK est développé par GNOME. GTK3 sortira en même temps que GNOME 3.
Par contre, du côté KDE, depuis quand KDE 4.3.0 utilise systématiquement Qt 4.3.0. Non, ils sont indépendants. Il faudrait donc encourager ceux qui veulent faire du cross platform à utiliser Qt, qui est intégré aussi bien à KDE qu'à GNOME, plutôt que GTK qui nécessite le chargement de tous un tas de trucs bien lourds sous KDE.
Preuve de ce que j'avance : http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...) . Regardez comme la boîte de dialogue de gauche ressemble à du GTK ... c'est du Qt ! Jamais vous n'aurez une application GTK qui s'intégrera si bien dans un environnement Qt.
J'ai dit que ça virait au rêve à la fin. C'est simplement une suite de conclusion qu'on peut tirer de cette affaire.
En clair, sans détours, et sans rêves, MS a un gros problème qui peut leur faire beaucoup de mal, même avec un accord.
Ca ne peut faire que du bien (ou presque) au libre, car ça va prouver que MS n'est pas un bloc auquel personne ne touche. Qui sait, d'autres entreprises vont peut-être se mettre à chercher les brevets que MS peut enfreindre, pour les attaquer.
Même si on peut se poser des questions sur les formats Libres, MS vient tout de même de se prendre une bonne claque dans les dents.
En effets, ils ont amorcé leur descente aux enfers, qui durera quelques années. Ils admettent d'abord que Linux est un concurrent sérieux ( http://www.developpez.net/forums/d789309/club-professionnels(...) ), puis maintenant se prennent cette affaire de brevets.
Premier point : plus une entreprise est vieille, plus elle amasse des "cadavres dans le placard". En effet, depuis 20 ans, MS a largement eu le temps d'empiéter sur des brevets, de faire des choses qu'elle n'aurait pas du faire, etc. Plus le temps passe, plus MS risque de tomber, au profit du Libre, et d'Apple (qui reste tranquille dans son coin à attendre que le temps passe, pour obtenir une bonne part du gâteau).
Deuxième point, le FUD. MS a essayé de FUDer sur Linux, avec une histoire de brevets, ce qui veut dire qu'ils savent que les brevets sont importants. Ici, ce n'est pas un noyau "peu utilisé" en entreprise qui est touché, non, c'est un traitement de texte mondialement utilisé, surtout en entreprise.
Et là, ça devient intéressant. Même si MS fait appel, et qu'ils s'en tirent, ils ont perdu énormément de plumes :
- Les entreprises ne vont plus lui faire une confiance absolue, et vont voir que MS n'est pas tout blanc. Ils auront également peur d'arriver dans ces problèmes.
- Si Word disparaît, ou en tous cas la version OOXML, les entreprise vont l'avoir profond, car leurs documents seront perdus. Ils vont enfin découvrir l'avantage des formats libres et interopérables. Même si OOo avait été touché par un brevet de la sorte, et contraint de sortir en une version dépourvue du format ODF, d'autres applications (genre KOffice) aurait pu être utilisées (non-attaquées), ou le document aurait pu être converti en un autre format, libre du brevet (et tout aussi libre, genre celui d'Abiword, ou des premiers OOo, ou en XHTML, ou dans un nouveau format)
- Cela m'amène au 3eme point : les entreprises vont chercher des alternatives, et c'est là une aubaine pour OOo et les autres. Les entreprises vont cesser de se dire «Il n'existe que Word», il vont voir ailleurs.
Et un point que je détache des autres, parce qu'il est très incertain : si cela est bien médiatisé, c'est peut-être une grande chance pour Linux. En effet, si dans le journal parlé du soir, on a comme premier sujet «Microsoft retire Word de la vente», ils pourraient terminer leur journal par proposer des alternatives, genre Linux.
Et pour finir, MS peut soit verser de l'argent à cette entreprise, soit, mais c'est vraiment improbable, faire pression pour que les brevets logiciels disparaissent. En effet, MS a beaucoup plus à perdre maintenant. Comme dit plus haut, leur image de marque est fichue, et ils doivent passer cette affaire sous silence. Rendre les brevets illégaux peut donc les arranger, mais ça vire au rêve malheureusement.
Dans tous les cas, on peut se réjouir de cette nouvelle. C'est un grand coup dans MS, qui ne peut que leur faire du mal. Pour le reste, wait and see.
Tu sais, il faut voir la différence entre un bug de KDE et un bug normal.
Dans KDE, un bug, c'est par exemple «quand on clique sur Nouveau, on nous demande le nom du projet, alors qu'on l'avait déjà configuré par défaut dans les options». Ce sont de tout petits bugs de rien du tout, mais ils les corrigent quand-même.
10 000 gros bugs, ça voudrait dire que KDE 4.2 aurait été encore plus inutilisable que KDE 4.0-beta1, ce qui était loin d'être le cas.
De plus, KDE est vraiment énorme, et les bugs traîtent de kdelibs, kdebase, kdeadmin, kdegames (pas mal de bugs là), kdetoys, kdevelop, kdewebdev, etc, ainsi que les programmes externes utilisant le même bugtracker (amarok, koffice, k3b, et tant d'autres).
10 000 bugs, ça veut dire à peu près 100 bugs par "projet" KDE, et 100 petits bugs. C'est donc plus que convenable :) .
Avant de la proposer sur l'adresse e-mail donnée, j'aimerais avoir votre avis sur mon idée (que tout le monde peut reprendre) : jouer avec "i" et "3". Le logo représente un 3 dont chaque branche est un i . Le tout est oblique pour qu'on voie en même temps le 3 et les i .
Effectivement, mais je n'ai pas de paquet Opera dans les dépôts, donc c'est que ça coince quelque-part pour la licence, alors que ça marche pour Flash.
Donc pas spécialement une libération, mais une "moins-propriétairisation", pour qu'il puisse être redistribué.
Ou alors Ubuntu fait un coup à la Mandriva (pour quand j'avais testé) : proposer Opera dans le menu, et quand on clique dessus, ça le télécharge sur le site de Opera et ça l'installe. Ca devrait être possible, Mandriva l'a fait pour Google Earth.
S'ils veulent Opera dans Ubuntu, ils n'ont qu'à le libérer, et il sera proposé dans les dépôts au même titre que Konqueror, FireFox, Arora et tant d'autres.
Non mais, c'est vraiment vouloir le beurre, l'argent du beurre, et la laitière ( (c) pBpG dans son journal)
Là pour le moment, Opera ne fait qu'acquérir une mauvaise réputation, même si le coup avec MS est bon pour FF (et encore, imposer du LL n'est pas la solution, on n'est pas MS ici)
[^] # Re: Sympa ce journal
Posté par steckdenis (site web personnel) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.
La gestion des architectures sera toujours gardées, car il y aura bien des paquets (ne fusse que le kernel) qui ne passeront pas avec LLVM, et qui auront besoin de GCC, ou de fichiers non-binaires mais dépendants de l'architecture (il me semble que ça existe, genre des dumps mémoire dépendants de la taille des pages).
Et oui, j'ai oublié de présenter LLVM. Toutes mes excuses à ceux qui se sont sentis perdus.
[^] # Re: opt de taille
Posté par steckdenis (site web personnel) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 3.
Pour les bibliothèques liées statiquement, hors le fait que je n'aime pas, il devrait être possible de les fournir dans le paquet, puis d'utiliser "clang -o binaire fichiers.s -L. -llib_statique", ou quelque-chose comme ça. C'est un domaine jamais exploré, je vais voir ce que je peux trouver.
[^] # Re: pc libre ?
Posté par steckdenis (site web personnel) . En réponse au journal Test de Debian et Open Sound System version 4. Évalué à 5.
Je veux du Linux, je vais au magasin, on me force à acheter du Windows, je fais plein de démarches, je perds de l'argent, j'installe Linux.
Différent non ?
Et puis, Intel, lui, fourni ses spécifications et est doté d'un pilote libre de grande qualité (même si on en a bavé, mais le 2.8 est extra).
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par steckdenis (site web personnel) . En réponse au journal Test de Debian et Open Sound System version 4. Évalué à 5.
make debEt oui, qualité OSS : il génère des paquets .deb tout seul (et c'est propre, on sait désinstaller, etc).
[^] # Re: la fin d'un troll ou le début d'un autre ?
Posté par steckdenis (site web personnel) . En réponse au journal Test de Debian et Open Sound System version 4. Évalué à 2.
Effectivement, c'est là un problème de Debian. J'ai cru lire à un moment que OSSv4 se trouvait dans les dépôts, mais comme Debian est très chipoteur sur les licences, dès que le troll de "propriétarisation" a pointé le bout de son nez, hop, plus de OSS chez Debian.
Et puis, c'est tellement bien expliqué, et tellement simple :
tar -xf archive
cd archive
./configure # qui ne vient pas des autotools d'ailleurs, c'est du fait-main
make
sudo make install
sudo make modules
Et voilà.
[^] # Re: ATOM ou AMD64?
Posté par steckdenis (site web personnel) . En réponse au journal Test de Debian et Open Sound System version 4. Évalué à 6.
Jeune jeune, peut-être, ça ne fait qu'un an et demi :-° (et je le regrette de temps en temps, de ne pas avoir connu KDE 2, les noyaux 2.4 et 2.2, et d'autres choses un peu plus vieillottes).
Et puis, côté temps perdu, ça m'a pris 2 heures à tout casser pour que ça marche bien, et ça marche encore toujours bien (et avant, j'avais ALSA, qui juste-marche aussi, mais j'avais envie de tester).
[^] # Re: Hum ...
Posté par steckdenis (site web personnel) . En réponse au journal analyse google/linux. Évalué à 9.
C'est bon signe.
(ou alors parce que tout le monde remplace "Linux" par "Ubuntu", qui lui monte vraiment)
[^] # Re: Sympa
Posté par steckdenis (site web personnel) . En réponse au journal GNOME plus léger que KDE ?. Évalué à 10.
========================================
Pourquoi GNOME paraît plus léger que KDE
========================================
Le débat entre les utilisateurs de GNOME et ceux de KDE fait beaucoup parler de lui. Chacun avance des arguments qui permettent de valoriser son environnement de bureau, mais peu font une analyse précise sur un point de cette différence.
Ce document va mettre en lumière une petite différence qui fait tout entre les deux bureaux. La réputation de «lourd et complexe» de KDE, et «léger et simple» de GNOME s'explique en fait simplement, très simplement.
KDE complexe ? GNOME frais ?
Les défendeurs de GNOME le répètent suffisemment, leur bureau est plus léger. En tous cas, c'est ce qu'ils disent. Nous n'allons pas ici nous intéresser à la légèreté matérielle (consommation de mémoire, vitesse d'éxécution), mais bien de l'aspect.
En effet, KDE a toujours eu la réputation d'interface complexe et riche en fonctionnalités, très riche, trop riche. De nombreux trolls sont du genre «Non, pour que ça ressemble à KDE, il aurait fallu rajouter des boutons partout et complexifier l'interface».
La question est «Pourquoi ?». Pourquoi est-ce que KDE a une interface qui paraît lourde, et pourquoi GNOME respire tellement.
Les marges, voilà le secret
===========================
Et oui, le problème est tout simple. Voici la petite analyse qui m'a mené à cette conclusion.
Comparons tout d'abord une même fenêtre en GTK (GNOME) et Qt (KDE). La fenêtre choisie a été trouvée sur le site de PackageKit. Elle est toute simple et convient parfaitement :
Maintenant, je prends Qt Designer et essaie de refaire cette fenêtre. Voici ce que ça donne au bout de quelques minutes :
C'est plus ou moins réussi, mais comme on peut s'y attendre (ou pas), cette fenêtre est plus lourde. Plus lourde ? Et oui, elle étouffe un peu plus celui qui la regarde.
À première vue, c'est exactement la même. Les boutons sont les mêmes, ils ont une icône, l'icône de paquet est équivalent, et les contrôles sont placés au même endroit.
Première étape, changeons de thème, et utilisons Cleanlooks, concu pour ressembler à Clearlooks de GTK :
C'est déjà bien mieux. Les boutons sont un peu plus gros, et plus aérés. Les icônes ont également changé. Par contre, ce thème est moins clair que celui de l'image GTK plus haut, mais passons là-dessus.
Et c'est maintenant que ça va devenir intéressant ! Le principe est que cette fenêtre est trop lourde. Éliminer le thème Oxygen a déjà corrigé pas mal de défauts, mais la fenêtre reste encore moins agréable que la version GTK. Pour corriger cela, regardons attentivement la version GTK.
Et oui, elle a quelques caractéristiques :
* Les contrôles sont légers et fins, sauf les boutons qui sont gros
* Il y a beaucoup d'espace entre les contrôles
C'est ce dernier point qui est important. Cet espace permet de limiter le taux information/espace de la fenêtre, et de soulager le cerveau. Le cerveau devant regarder moins de choses, il aime mieux. Allons-y, configurons les marges et rétrécissons cette barre de progression. Retirons également le pourcentage d'avancement qui n'apporte rien :
C'est déjà beaucoup mieux ! Maintenant, toujours pour continuer dans l'allègement, nous allons éclarcir cette fenêtre et ses contrôles, et accessoirement changer de décorations de fenêtres :
Et bien voilà, notre fenêtre Qt est à présent quasiment identique à la version GTK, toute aussi légère du moins !
Et ce que ça donne sous KDE
Maintenant que notre fenêtre est légère, voyons voir ce que les réglages font sur KDE en entier. Pour tester, nous allons prendre une application couverte de boutons, habituellement qualifiée de lourde.
J'ai nommé ... Dolphin . Le résultat est spectaculaire !
Avouez qu'il a vraiment bien maigris. Il est à nouveau utilisable sans se saturer les yeux de détails. Pour information, voici ce que ça donne avec le thème et les décorations de fenêtres Oxygen d'origine :
Conclusion
==========
Voilà, nous avons vu qu'un simple changement de thème permet de rendre KDE léger. Maintenant, le graphique ne fait pas tout, mais voici quelques observations qui vont vous intéresser :
* L'impression de lourdeur de KDE résulte du fait que les fenêtres semblent s'ouvrir lentement. En effet, elles ne font que sembler, car j'ai testé plusieurs fois, elles s'ouvrent quasi-instantanément, aussi bien avec le thème Oxygen qu'avec le thème Cleanlooks.
C'est le cerveau, encore une fois, qui fait des siennes. Quand une fenêtre jailli devant notre regard, le cerveau, avant de se dire «la fenêtre est affichée», la lit dans son entièreté (même si on ne s'en rend pas compte). Chaque détail est pris en compte.
C'est donc là que se trouve le problème. Avec Oxygen, il y a bien trop de détails, ce qui fait que le cerveau prend plus de temps à lire la fenêtre (et d'autant plus que la fenêtre est grande et riche en contrôles, ce que KDE aime bien).
Le passage au thème Cleanlooks permet de simplifier l'apparence des fenêtres, et de les rendres plus facilement gérables par le cerveau (c'était la première étape). Ensuite, en les éclairsissant, on diminue le contraste de ces détails, que le cerveau peut encore oublier. On se concentre donc immédiatement sur l'apparition de la fenêtre, pas son contenu
* Notons tout de même que le thème Oxygen est aussi lourd pour la machine. En effet, il use et abuse de dégradés en tous genres et de vectoriel. Pour avoir lu son code source, je peux vous dire qu'il est déjà sur-optimisé, mais un tel niveau graphique n'est pas atteignable sans compromis, surtout que Oxygen n'utilise pas de pixmaps, ni de SVG. Tout est contruit et dessiné à la volée.
* Le changement de décorations de fenêtres a aussi eu son importance. Les fenêtres sont blanches, et si les décorations sont blanches aussi, on se retrouve avec un gros pâté, que les yeux ont du mal à identifier
Ce changement de thème permet donc de soulager le regard et le processeur, au plus grand bonheur de l'utilisateur. Bien sûr, certains préfèrent Oxygen, mais comme c'est configurable, ce n'est que mieux !
Conclusion finale : Ne jamais juger une application ou un bureau sur un screenshot ou son aspect, ces éléments sont configurables. Les screenshots de KDE sont lourds, car ils suivent la politique du «Un screenshot pour tout montrer». Ceux de GNOME sont par contre plus légers, car ils font un screenshot par chose à montrer (une boîte de configuration, un morceau d'application, etc).
Reproduire cet essai
====================
Pour obtenir un KDE léger comme je vous montre à la fin, les étapes sont extrêment simples :
1. Ouvrir la configuration du système : K»Favoris»Configuration du système
2. Aller dans «Apparence»
3. On se retrouve avec la configuration du style. Choisissez «Cleanlooks» dans la liste des styles
4. Si vous n'en pouvez déjà plus, cliquez sur «Appliquer» pour respirer un coup
5. Allez ensuite dans «Fenêtres» (dans la barre verticale à gauche)
6. Dans la liste déroulante qui contient «Oxygen», sélectionnez «Quartz», puis cliquez sur Ok
Votre bureau respire, mais pas totalement (il est trop sombre). Voici comment l'éclarcir :
1. Rouvrez la configuration du système et allez à nouveau dans «Apparence»
2. Cliquez sur «Couleurs», puis sur l'onglet «Couleurs» (ok, pas exessivement ergonomique, mais vous auriez fait quoi ?)
3. Vous avez une liste de noms avec une couleur en face. Mettez une couleur gris très très clair (quasi blanc), en cliquant sur le jeton de couleur puis en sélectionnant la couleur de votre choix, au éléments «Arrière-plan de fenêtre» et «Arrière-plan de bouton».
4. Cliquez sur Appliquer, et ajustez éventuellement les autres couleurs.
[^] # Re: Sympa
Posté par steckdenis (site web personnel) . En réponse au journal GNOME plus léger que KDE ?. Évalué à 3.
Si tu n'as pas de GNOME installé, tu utilises le style Cleanlooks, comme décrit à la fin du document.
Bien entendu, ça ne change que l'aspect graphique. Si une application KDE est mal conçue elle-même, on ne peut rien faire. Quoique, en explorant le menu Configuration de chaque application, on découvre avec joie qu'on peut choisir la position des menus et boutons de barre d'outils. Le menu est Configuration»Configurer les barres d'outils
Et encore mieux :D ! Dans /usr/share/kde4/apps/l'application, se trouve un ou plusieurs fichiers .rc. Chaque fichier .rc contient toute l'interface de l'application. Libre à toi de réorganiser ça exactement comme tu veux (supprimer les boutons de barre d'outils qui ne servent à rien, en ajouter d'autres, en déplacer, changer/supprimer les icônes ou le texte, etc). Ça fonctionne comme le menu de configuration des barres d'outils (donc c'est mieux de l'utiliser pour éviter les erreurs et donc le plantage/instabilité de l'application)
Malheureusement, l'astuce des .rc ne fonctionne que pour les menus et les barres d'outils. Heureusement que KDE utilise en majorité ces emplacements.
[^] # Re: Perte de temps
Posté par steckdenis (site web personnel) . En réponse au journal GNOME plus léger que KDE ?. Évalué à 2.
Comment désinstaller GNOME proprement ? apt-get remove libgtk2.0 marche, mais je perds également toutes mes applis GTK. Supprimer gnome-core ? il en reste un peu, j'ai essayé.
Comment désinstaller KDE ? apt-get remove kdelibs et on n'en parle plus (à la limite, il reste encore oxygen-icon-theme qu'on doit supprimer à la main). On peut aussi supprimer Qt, mais on perd les quelques rares applis Qt qui pourraient être installées.
Ce n'est donc pas de l'intégrisme, simplement, GNOME est connu pour être difficile à désinstaller, donc je ne l'installe pas (j'ai une toute petite partition système, et déjà plein de choses dessus). KDE par contre est facile à désinstaller, et a des dépendances précises (c'était d'ailleurs l'argument avancé quand Slackware a cessé de supporter GNOME)
[^] # Re: Perte de temps
Posté par steckdenis (site web personnel) . En réponse au journal GNOME plus léger que KDE ?. Évalué à 10.
Et pourquoi pas en PDF ? C'est libre il me semble, et correctement implémenté partout (alors que le .odt nécessite d'installer OpenOffice ou KOffice, ou autre application capable de le lire).
[^] # Re: Perte de temps
Posté par steckdenis (site web personnel) . En réponse au journal GNOME plus léger que KDE ?. Évalué à 4.
J'aurais bien aimé être objectif sur les temps de chargements, mais il y a plusieurs problèmes :
* Je n'ai pas GNOME d'installé (à la limite, ça s'arrange, mais pour après tout désinstaller, c'est difficile)
* Comment on mesure avec précision le temps de démarrage ? Un time ne se stoppe pas quand la fenêtre est démarrée.
En tous cas, à l'utilisation, tout ce que je peux dire, c'est que l'interface est fluide, ou en tous cas pas gênante. Quand je clique sur le bouton «Répondre» de Kmail, je ne dois pas attendre, la fenêtre s'affiche "tout de suite" (même si pour le CPU, c'est bien plus long).
Ensuite, je ne mélange pas. J'ai justement fait attention dans le document à toujours parler de la légèreté visuelle, et pas d'occupation CPU/Mémoire, sauf aux endroits indiqués.
Pour finir, oui, j'ai transformé KDE en GNOME, et c'était le but. C'était pour montrer que les développeurs ne font pas preuve d'incompétence ergonomique, loin de là, simplement qu'on est tous plus ou moins habitués à GNOME (qui ne l'a pas utilisé, à part ceux qui sont toujours restés sous WindowMaker, Fluxbox, XFCE* et autre ?). Rien n'empêche quelqu'un de développer un thème Qt aussi léger que Cleanlooks, mais différent. Je me suis contenté de trouver «l'astuce magique» qui rend GNOME plus léger visuellement, et de l'appliquer à KDE pour prouver que ça marche.
* Et encore, XFCE utilise GTK et, il me semble, quelques bibliothèques GNOME, donc graphiquement, XFCE est proche de GNOME
[^] # Re: Retrousse tes manches…
Posté par steckdenis (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 2.
Ensuite, il me semble que je ne confonds pas. Le but de Logram, ce sont deux choses :
1. Des applications développées pour KDE et Qt (l'environnement léger que je vous ai déjà présenté utilise Qt, et servira quand il faut pour une raison ou pour une autre un environnement léger de secours). Il y a aussi Confrunner, une application qui affiche une GUI à partir d'un fichier XML (exactement comme Xulrunner, sauf qu'il n'y a pas de JS, et que c'est orienté configuration (chaque contrôle est relié à une entrée de configuration quelque-part)), et Assistant, une documentation visant à prendre le débutant par la main (la doc de KDE est très bien, mais un peu sèche par endroits, et ce n'est pas son but d'apprendre à se servir d'un ordinateur).
2. Une distribution, pour empaqueter et proposer tout ça. La distribution est basée sur Debian, et ne touche pas trop au KDE de Debian. Elle propose ses artworks, et des paquets pour toutes les applis Logram que j'ai cité. Pour tester : ajouter "deb http://archive.logram-project.org Paradise main" dans son sources.list, puis "apt-get install logram-assistant logram-presentation logram-doc2html logram-confrunner logram-ksplash-theme logram-kdm-theme logram-wallpaper".
La distribution est très limitée, mais comme dit plus haut, les outils vont fleurir (envoi d'un fichier en un clic sur son compte sur le site web, pour un partage rapide sans devoir chercher Megaupload, omploader et d'autres. Non, directement depuis Konqueror, on pourra envoyer ses fichiers :) ). On trouvera dans ces outils également le gestionnaire de paquets/mise à jour (ou PackageKit si sa version KDE évolue bien), des outils de configuration graphique (j'ai pas développé confrunner pour rien), etc.
Encore pour la distrib, ce n'est pas une simple copie de Debian avec des artworks. On a déjà une version de GRUB2 qui propose de définir le mode graphique du noyau (set gfxpayload pour les connaisseurs). Je dois d'ailleurs encore proposer le patch à Debian. Il y a aussi du travail qui a été fait sur le temps de démarrage (ma Debian semi-Logram prend 12 secondes entre le GRUB et KDM).
[^] # Re: Retrousse tes manches…
Posté par steckdenis (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 3.
Même sous Debian, KDE est utilisable, et pleinement utilisable. Simplement, dans mon "utilisable", ça veut dire en environnement plus que complet, où tous les outils sont KDE.
Par exemple, j'ai besoin de partitionner mon disque dur. Il existe GParted. Mais qu'en est-il de KPartitionManager, sorti en version stable il y a quelques temps ? Il faudrait que quelqu'un rassemble tout ça dans un paquet (typiquement le contenu d'un LiveCD, pas un .deb), pour que les gens découvrent des applis KDE formidables mais peu connue.
C'est aussi un service qu'on rend aux applis. Pour reprendre l'exemple de KPartitionManager, il a été abandonné pendant quelque temps. S'il avait été aussi connu que son équivalent GNOME, GParted, cela ne serait pas arrivé.
Pour le wiki, effectivement, absolument tout existe. Simplement, vas-y pour intégrer un wiki, un forum, une gestion des paquets et une gestion des demandes. Par "intégrer", je demande bien plus qu'un design partagé.
Non, ce site ressemble plus à une "grosse forge" : les utilisateurs sont partagés, les composants sont partagés (la même template permet d'afficher un topic et les commentaires d'une demande par exemple), les groupes/droits et autres sont partagés.
Ce site joue aussi le jeu du "je propose largement plus que le minimum". Les forges proposent habituellement un forum, mais est-ce vraiment on bon forum ? Je n'ai absolument pas la prétention de rivaliser avec phpBB, c'est impossible, mais mon forum au moins gère le lu/non-lu (contrairement à celui de Drupal et de Redmine par exemple).
C'est donc une intégration poussée qui me motive. J'aurais très bien pu assembler phpBB, Mediawiki, Bugzilla pour obtenir un site ressemblant à celui de KDE (Drupal pour la page d'accueil, websvn, mediawiki, fluxBB je crois, etc).
Et puis, tout cela sera redistribué sous licence Libre, donc ça ne peut pas faire de mal.
[^] # Re: La belle affaire...
Posté par steckdenis (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 7.
Qt, c'est moins de 20Mio de mémoire partagée. En plus, Qt est complet, donc chaque application est moins lourde en code (en mémoire, je sais pas).
Bref, si au lieu de dire «Je fais en GTK pour que mon appli tourne sur Linux/Windows», ce serait bien que les gens disent «Je vais mon appli en Qt pour qu'elle tourne sous Linux et Windows». Une appli GTK n'est compatible qu'avec "une moitié" de Linux, une appli Qt est compatible avec tout.
Pour le fait que GTK ne dépend pas de GNOME, c'est justement ce que je lui reproche. C'est bien simple, GNOME a GTK sous la main. Tout ce qu'ils veulent mettre dans GTK, ils l'y mettent. Même un GTK "nu" se retrouve bourré de GNOME dedans.
Puis, il y a aussi les distribs comme Ubuntu qui ne savent pas empaqueter. J'installe Inkscape, foutu programme en GTK de nouveau, et comme Ubuntu a dit «Mouai, GTK sans gvfs, ça pue». Hop, je me prend gvfs, gnome-core. Ubuntu a dit «gnome-core sans gnome-panel, ça pue». Hop, j'ai gnome-panel, gnome-session, et tout un tas de trucs. J'ai donc plusieurs centaines de Mio pris par un truc que je ne vais pas utiliser, mais mon support KIO, et une intégration graphique, non, je n'ai pas.
Du côté de KDE maintenant. Le développement de Qt vise l'extrême portabilité, donc sous Windows, Qt doit être du Windows natif (donc utiliser les boîtes de dialogue natives, les contrôles natifs, etc). Qt manque donc de certaines fonctionnalité pour Linux (au hasard : les icônes Freedesktop). C'est là que KDE intervient, et nous fourni les kdelibs, surcouche à Qt.
Effectivement, si KDE avait forké Qt, tout cela serait dans Qt, et Qt serait bien plus lourd. Là, effectivement, Qt sous GNOME serait embêtant. Actuellement, c'est GTK qui nous fait le coup de tout intégrer, y compris ce qu'on ne veut pas.
Première partie du commentaire (oui, je réponds à l'envers)
gtk-qt-engine, c'est pas vraiment excellent. En gros, on a des énormes boutons au look Oxygen à quelques endroits, les onglets sont totalement pétés, et tout ce qui est taille ne marche plus (boutons trop petits, etc).
Pour les notifications, il y a quelques normes Freedesktop, mais Freedesktop se limite vraiment au strict minimum (juste pour que les applications "marchent" dans le sens "ne plantent pas au démarrage"). Ces spécifications sont donc très limitées dans les possibilités qu'elles offrent, et les deux DE se chargent de les dépasser, sauf que c'est plus une norme alors.
[^] # Re: Retrousse tes manches…
Posté par steckdenis (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 1.
(mais ça j'ai pas mis dans le journal pour éviter qu'il se fasse moinsser pour une seule phrase)
Le but de Logram (une distrib que je compte développer) est de proposer un KDE utilisable, c'est à dire pas un KDE qui marchotte plus ou moins (empaquetage douteux, et le problème de ce journal).
Logram, c'est aussi pour le Libre en général. Par exemple, je développe son site web actuellement, qui regroupe tout ce qu'une distrib a besoin : wiki, forum, gestion des paquets, demande, websvn, etc. Tout ceci, je le fais générique (même la gestion des paquets utilise une BDD. Le seul truc distro-dependant dedans, ce sont les 100 lignes du script d'importation d'un dépôt APT).
Bref, ce site sera placé sous GPL et réutilisable par tout le monde.
Le lien avec le journal ? C'est que justement, je compte développer un gestionnaire de paquets graphique pour KDE, utilisant APT (si on veut du portable, on a déjà KPackageKit qui va bien finir par tourner). Pour ne pas réinventer la roue, je vais intégrer le site dedans (note des paquets, commentaires, informations supplémentaires, stats sur le site sur combien de personnes utilisent un paquet, etc).
Et ce qui est bien en plus, c'est que ce ne sera pas dépendant de Logram. Toute distribution basée sur Debian et disposant d'un administrateur sachant se servir d'un site web pourra utiliser le site, et le gestionnaire de paquets. Tout le monde est content :) .
</mode rêve (ou pas, le site est quasi fini)>
[^] # Re: La belle affaire...
Posté par steckdenis (site web personnel) . En réponse au journal Les gens aiment les standards de fait. Évalué à 10.
Malheureusement, ça ne convient que pour les applications «normales», ou simples.
Par exemple, k3b est une appli qui utilise les kdelibs, et peut-être quelques autres choses. Par contre, elle ne passe pas son temps à lancer des services. Konqueror, ou Plasma, aurait déjà été bien plus difficile à utiliser sous GNOME.
Ici, avec PackageKit, c'est un calvaire sous KDE :
- Il utilise intensivement les notifications GNOME (voir screenshots), et donc, sous KDE, on ne voit rien
- Il est fondu avec gnome-power-managment (voir screens aussi), et donc ne marche pas bien sous KDE
Dire qu'une application marche sur un autre DE, c'est normalement qu'elle marche en entier, ou presque. Ici, PackageKit perd vraiment beaucoup d'intérêt. Maintenant, j'avoue que Synaptic marche très bien sous KDE, et que je l'ai même utilisé à un moment.
C'est plus cette mode du "tout en GTK" qui me perturbe. GTK est développé par GNOME. GTK3 sortira en même temps que GNOME 3.
Par contre, du côté KDE, depuis quand KDE 4.3.0 utilise systématiquement Qt 4.3.0. Non, ils sont indépendants. Il faudrait donc encourager ceux qui veulent faire du cross platform à utiliser Qt, qui est intégré aussi bien à KDE qu'à GNOME, plutôt que GTK qui nécessite le chargement de tous un tas de trucs bien lourds sous KDE.
Preuve de ce que j'avance : http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...) . Regardez comme la boîte de dialogue de gauche ressemble à du GTK ... c'est du Qt ! Jamais vous n'aurez une application GTK qui s'intégrera si bien dans un environnement Qt.
[^] # Re: Descente aux enfers
Posté par steckdenis (site web personnel) . En réponse au journal Comment les brevets logiciels se retournent contre leurs promoteurs ?. Évalué à 4.
En clair, sans détours, et sans rêves, MS a un gros problème qui peut leur faire beaucoup de mal, même avec un accord.
Ca ne peut faire que du bien (ou presque) au libre, car ça va prouver que MS n'est pas un bloc auquel personne ne touche. Qui sait, d'autres entreprises vont peut-être se mettre à chercher les brevets que MS peut enfreindre, pour les attaquer.
En tous cas, ça va faire du bruit.
# Descente aux enfers
Posté par steckdenis (site web personnel) . En réponse au journal Comment les brevets logiciels se retournent contre leurs promoteurs ?. Évalué à 2.
Même si on peut se poser des questions sur les formats Libres, MS vient tout de même de se prendre une bonne claque dans les dents.
En effets, ils ont amorcé leur descente aux enfers, qui durera quelques années. Ils admettent d'abord que Linux est un concurrent sérieux ( http://www.developpez.net/forums/d789309/club-professionnels(...) ), puis maintenant se prennent cette affaire de brevets.
Premier point : plus une entreprise est vieille, plus elle amasse des "cadavres dans le placard". En effet, depuis 20 ans, MS a largement eu le temps d'empiéter sur des brevets, de faire des choses qu'elle n'aurait pas du faire, etc. Plus le temps passe, plus MS risque de tomber, au profit du Libre, et d'Apple (qui reste tranquille dans son coin à attendre que le temps passe, pour obtenir une bonne part du gâteau).
Deuxième point, le FUD. MS a essayé de FUDer sur Linux, avec une histoire de brevets, ce qui veut dire qu'ils savent que les brevets sont importants. Ici, ce n'est pas un noyau "peu utilisé" en entreprise qui est touché, non, c'est un traitement de texte mondialement utilisé, surtout en entreprise.
Et là, ça devient intéressant. Même si MS fait appel, et qu'ils s'en tirent, ils ont perdu énormément de plumes :
- Les entreprises ne vont plus lui faire une confiance absolue, et vont voir que MS n'est pas tout blanc. Ils auront également peur d'arriver dans ces problèmes.
- Si Word disparaît, ou en tous cas la version OOXML, les entreprise vont l'avoir profond, car leurs documents seront perdus. Ils vont enfin découvrir l'avantage des formats libres et interopérables. Même si OOo avait été touché par un brevet de la sorte, et contraint de sortir en une version dépourvue du format ODF, d'autres applications (genre KOffice) aurait pu être utilisées (non-attaquées), ou le document aurait pu être converti en un autre format, libre du brevet (et tout aussi libre, genre celui d'Abiword, ou des premiers OOo, ou en XHTML, ou dans un nouveau format)
- Cela m'amène au 3eme point : les entreprises vont chercher des alternatives, et c'est là une aubaine pour OOo et les autres. Les entreprises vont cesser de se dire «Il n'existe que Word», il vont voir ailleurs.
Et un point que je détache des autres, parce qu'il est très incertain : si cela est bien médiatisé, c'est peut-être une grande chance pour Linux. En effet, si dans le journal parlé du soir, on a comme premier sujet «Microsoft retire Word de la vente», ils pourraient terminer leur journal par proposer des alternatives, genre Linux.
Et pour finir, MS peut soit verser de l'argent à cette entreprise, soit, mais c'est vraiment improbable, faire pression pour que les brevets logiciels disparaissent. En effet, MS a beaucoup plus à perdre maintenant. Comme dit plus haut, leur image de marque est fichue, et ils doivent passer cette affaire sous silence. Rendre les brevets illégaux peut donc les arranger, mais ça vire au rêve malheureusement.
Dans tous les cas, on peut se réjouir de cette nouvelle. C'est un grand coup dans MS, qui ne peut que leur faire du mal. Pour le reste, wait and see.
[^] # Re: Plus de 10 000... Correction de bugs ?
Posté par steckdenis (site web personnel) . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 8.
Dans KDE, un bug, c'est par exemple «quand on clique sur Nouveau, on nous demande le nom du projet, alors qu'on l'avait déjà configuré par défaut dans les options». Ce sont de tout petits bugs de rien du tout, mais ils les corrigent quand-même.
10 000 gros bugs, ça voudrait dire que KDE 4.2 aurait été encore plus inutilisable que KDE 4.0-beta1, ce qui était loin d'être le cas.
De plus, KDE est vraiment énorme, et les bugs traîtent de kdelibs, kdebase, kdeadmin, kdegames (pas mal de bugs là), kdetoys, kdevelop, kdewebdev, etc, ainsi que les programmes externes utilisant le même bugtracker (amarok, koffice, k3b, et tant d'autres).
10 000 bugs, ça veut dire à peu près 100 bugs par "projet" KDE, et 100 petits bugs. C'est donc plus que convenable :) .
# Paquets Debian
Posté par steckdenis (site web personnel) . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 3.
J'ai hâte d'y être :) .
[1] : http://incoming.debian.org/ (vers le millieu-début, on voit les paquets KDE)
# Ma contribution
Posté par steckdenis (site web personnel) . En réponse au journal i3 recherche un contributeur pour son logo. Évalué à 10.
Avant de la proposer sur l'adresse e-mail donnée, j'aimerais avoir votre avis sur mon idée (que tout le monde peut reprendre) : jouer avec "i" et "3". Le logo représente un 3 dont chaque branche est un i . Le tout est oblique pour qu'on voie en même temps le 3 et les i .
Le SVG : http://omploader.org/vMjF3Ng/i3.svg
Le PNG en 420x420 : http://omploader.org/vMjF3Nw/i3.png
J'espère que ça vous plaît :) .
[^] # Re: Libération ?
Posté par steckdenis (site web personnel) . En réponse au journal Opera souhaite aussi le choix du navigateur dans OS X et Ubuntu. Évalué à 1.
Donc pas spécialement une libération, mais une "moins-propriétairisation", pour qu'il puisse être redistribué.
Ou alors Ubuntu fait un coup à la Mandriva (pour quand j'avais testé) : proposer Opera dans le menu, et quand on clique dessus, ça le télécharge sur le site de Opera et ça l'installe. Ca devrait être possible, Mandriva l'a fait pour Google Earth.
# Libération ?
Posté par steckdenis (site web personnel) . En réponse au journal Opera souhaite aussi le choix du navigateur dans OS X et Ubuntu. Évalué à 9.
Non mais, c'est vraiment vouloir le beurre, l'argent du beurre, et la laitière ( (c) pBpG dans son journal)
Là pour le moment, Opera ne fait qu'acquérir une mauvaise réputation, même si le coup avec MS est bon pour FF (et encore, imposer du LL n'est pas la solution, on n'est pas MS ici)
[^] # Re: Le Libre peut être gratuit
Posté par steckdenis (site web personnel) . En réponse au journal De la gratuité du Libre. Évalué à 1.
Mouais, ce serait plutôt «Les meilleurs jeux du moment», ou «Pack des 10 meilleurs jeux», etc.
Heureusement que c'est pas moi qui ai du lui créer sa boîte de CD :-° .