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.
[^] # Re: La belle affaire...
Posté par steckdenis . 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.