Le principe de GTK-Qt Theme Engine est sûrement la réponse au problème :
C'est un thème pour GTK qui appelle Qt pour dessiner les graphismes au lieu de le faire soi-même comme les autres thèmes conventionnels.
Le même principe va permettre à OpenOffice.org d'être intégré à KDE. Concrètement en utilisant le bureau KDE, une application comme GIMP qui utilise GTK va automatiquement demander a Qt de dessiner les composants graphiques via GTK-QT Theme Engine. Qt va ensuite utiliser le thème utilisé par KDE (par exemple Keramik ou plastik). Les performances sont plus faibles qu'un thème GTK normal puisqu'il y a une couche supplémentaire mais la différence semble vraiment négligeable.
Le même principe de "thème" est aussi suivie dans un autre projet pour OpenOffice.org qui permet d'intégrer OpenOffice.org dans le bureau KDE.
GTK-QT Theme Engine et OOo KDE Native Widget Framework sont encore à un stade alpha de développement.
Le 1er lien contient une interview de l'auteur de GTK-QT Theme Engine avec des explications techniques sur son fonctionnement.
Aller plus loin
- News GTK-Qt Theme Engine sur dot.kde (6 clics)
- Téléchargement de GTK-Qt Theme Engine (13 clics)
- Capture d'écran de GTK-Qt Theme Engine (11 clics)
- News OOo KDE sur dot.kde (3 clics)
- OOo KDE Native Widget Framework (5 clics)
- Capture d'écran de OOo KDE (5 clics)
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par MrPingouin . Évalué à 3.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par farib . Évalué à 1.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Lionel Fournigault . Évalué à 4.
s'agit d'une toolkit extrèmement bien pensée et puissante, quant au look chacun peut choisir parmi un grand nombre de themes et au final je dirais que QT c'est beau et ca plait
à une majorité d'utilisateurs de Linux.
Bonne journée et bon week-end
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par - - . Évalué à 1.
oui mais GTK a aussi de bons coté et quant au look chacun peut choisir parmi un grand nombre de themes et au final je dirais que GTK c'est beau et ca plait
donc l'inverse serait bien aussi et vive qt/gtk et le reste de l'univers
le fin du fin, serait qu'un soft kde utilise les boites de dialogues communes de gnome (avec gnome-vfs, gtk2.4 etc) quand il tourne sous gnome-session
et l'inverse quand un soft gnome tourne sous la supervision de kde.
mais bon, faut bien admettre, et comprendre _définitivement_ que Gnome et KDE correspond à des mentalités et buts _différents_ , il y a des _raisons_ derrière l'existence simultanée de gnome et de kde.
je connais des gens qui aiment beaucoup kde ,là ou moi je prefere nettement gnome (non je n'argumente pas, et mon opinion ne fait aucun mal à KDE). et oui j'ai vu kde 3.2beta, c très bien.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Romain Vinot . Évalué à 4.
On y arrive : cf la dernière release de Sodipodi.
Bon d'accord, ça n'est pas à l'exécution mais à la compilation. Tu peux choisir quelle boîte de dialogue tu veux utiliser (Gnome ou KDE).
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par enicolas . Évalué à -2.
Ce n'est juste pas possible parce que QT n'affiche pas en utilisant un toolkit, mais dessine tout lui-même.
Voilà voilà.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par bad sheep (site web personnel) . Évalué à 1.
QT est un toolkit (même plus, mais je parle pour la partie graphique)
GTK est un toolkit
Motif est un toolkit
GTK aussi affiche tout lui même, c'est le principe !
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Erwan . Évalué à 2.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Superted . Évalué à 1.
C'est marrant comme ces deux messages sont très révélateur de la mentalité trollienne.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Erwan . Évalué à 1.
Si GTK ne prévoit pas des mécanismes assez générique permettant d'utiliser un autre toolkit (comme qt) c'est mal barré. Si Qt ne permet pas d'être utilisé par un autre toolkit c'est mal barré aussi.
Tu es en train de decrire le sujet de la news, pas son inverse: Gtk qui utilise Qt pour afficher ses controles.
En ce qui concerne "l'inverse", on sait que Gtk peut etre utilise par d'autres toolkit car c'est ce que fait Mozilla en appuyant son toolkit sur Gtk dans sa version X11. C'est aussi ce que projette de faire OpenOffice. Donc ca ne depend plus que de Qt.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, mais c'est un non-sens.
Qt est au même niveau que GTK+, l'un ne peut pas utiliser l'autre. Les deux dessinent à coup d'appels à la XLib.
on sait que Gtk peut etre utilise par d'autres toolkit car c'est ce que fait Mozilla
Avec une toolkit d'un niveau d'abstraction supérieur (comme le SWT d'Eclipse par exemple). Ça n'est pas le cas de Qt.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Philippe F (site web personnel) . Évalué à 4.
C'est tout a fait vrai.
> l'un ne peut pas utiliser l'autre
C'est tout a fait faux.
cf la derniere release de sodipodi qui integre des dialogues KDE dans une appli gtk.
L'etape d'apres est deja prevue:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/qtgtk/README?re(...)
Donc les deux peuvent etre utilises en parallele sans trop de problemes.
> Les deux dessinent à coup d'appels à la XLib.
Oui et non. Oui parce sous X11, a un moment donne, pour dessiner sur un serveur X, il faut faire appel a la Xlib.
Non, car dans gtk comme dans Qt, il a deux niveau de dessinage. Le premier, c'est celui ou tu dessines sur le contexte graphique, x11 donc sous unix, cocoa sous macos, win32 sous windows.
Le second, c'est celui ou tu dessines les controles graphiques. Qt et Gtk passent tous deux par un moteur de theme. Ce n'est donc pas Qt ou Gtk qui dessinne, mais le moteur de theme a qui on dit "dessine moi un bouton enfonce, dessine moi une checkbox, ..."
A noter que sous windows XP, Qt utilise le moteur de theme de XP, et donc les applis Qt ont un look natif.
Ce qu'a fait le mec dans le cas qui nous occupe, c'est appeler le moteur de theme de Qt depuis le moteur de theme de Gtk. Il serait tout aussi facile (mais c'est un exercice different) d'utiliser le moteur de Gtk dans des applications Qt ou KDE.
En ce qui concerne Mozilla, je suis moins sur. Il me semble qu'il y a un moteur de theme Mozilla, qui utilise gtk pour dessiner sur l'ecran, sans utiliser les themes gtk proprement dit. Ca fait donc un troisieme moteur de theme.
A priori, avec un peu de volonte, il est possible de croiser des themes dans tous les sens, voire de developper un meta-moteur de theme qui serait utilise par tous les autres moteurs de themes.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Pour le dessin des widgets, oui, tu as raison. Pour tout le reste (gestion des evts), non. Tu n'aurais jamais QPushButton qui crée un GtkButton, comme Superted et Erwan avaient l'air de le dire.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par fred point . Évalué à 1.
gdi sous win32, plutot non ?
> A noter que sous windows XP, Qt utilise le moteur de theme de XP, et donc les applis Qt ont un look natif.
Donc Qt sait utiliser un autre toolkit pour afficher les éléments simples. Cela semble donc, comme tu le dis, tout à fait faisable.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Philippe F (site web personnel) . Évalué à 1.
Pour dessinage, hum, je me suis un peu laisse aller.
Pour ce qui est de mozilla, en y resongeant, je crois que les controles graphiques (boutons, barre URL, ...) sont en fait en gtk et beneficient du theme gtk mais que mozilla a des themes pour autre chose: le jeu d'icones, la couleur du navigateur, ...
En reponse a Guillaume, pour l'instant, on a pas en effet de melange de deux toolkits dans une meme fenetre donc en effet, pas de GtkButton dans un QWidget. Cela dit, ca pourrait arriver dans le futur.
-> qq'un a prouve qu'on pouvait connecter des signaux Gtk a des slots Qt et l'inverse.
-> En utilisant QXEmbed, il est possible d'encastrer une fenetre X dans une autre. Tout widget Qt est une fenettre X, donc il est deja possible d'encastrer n'importe quel widget Qt dans une appli Gtk.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par thecat . Évalué à 3.
désolé pour le hs mais bon "dessinage" , c'est un "thème" sur le mot dessin ?
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Thomas RIBO . Évalué à 1.
Apparemment, ce qui est décrit dans la news est un theme-engine, c'est-à-dire carrément un moteur, du code donc, pour dessiner le thème.
Le thème Liquid pour KDE fonctionne exactement sur ce principe : pour que ce soit rapide, les machins sont dessinés avec du code. On pourrait très bien mettre dans ce code des appels vers GTK+, ce qui semble justement être fait dans la lib présentée dans la news.
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par bobert . Évalué à 6.
http://web.ticino.com/Sagittarius/gtk-qt-engine-0.2-1mdk.i586.rpm(...)
* Sur la capture d'écran du dernier lien on voit un bel OpenOffice.org Writer relooké éditant un document... Microsoft !! Provocation ? C'est moi qui suis susceptible au p'tit matin ?
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par NiCoS . Évalué à 2.
# Et les icônes ?
Posté par Romain Vinot . Évalué à 10.
Il reste encore plein d'autres problèmes pour avoir vraiment un bureau unifié :
- le problème des icônes standards (c'est beurk le mélange des icônes KDE et Gnome suivant l'appli) de façon à ce que l'icône Open ou Save soit le même partout.
- le problème des noms de menu et des emplacements de bouton (le Oui/Non de KDE et le Non/Oui de Gnome)
- le problème des dialogues standards (ouverture de fichier, impression...) : en passe d'être résolu également : une appli Gtk ouvrira un dialogue QT dans l'environnement KDE et vice-versa.
- le problème des interfaces : ça me fait ch... lorsque je suis obligé de double-clicker pour ouvrir un répertoire sous OpenOffice alors que mon bureau sous KDE est configuré pour le single-click !
Bref, ça avance, mais c'est pas fini...
[^] # Re: Et les icônes ?
Posté par - - . Évalué à 3.
avec GTK 2.4 les icones "standards" sont gérés par le thème GTK. QT n'aura donc qu'à utiliser les icones d'un thème GTK 2.4
l'inverse je ne sais pas.
[^] # Re: Et les icônes ?
Posté par gnumdk (site web personnel) . Évalué à 1.
Pour les bouttons, a part un changement d'avis de la theme kde... Les deux projets ne poursuivent pas le meme but, alors que kde s'inspire de windows, gnome lui suit macosx... Pour vous en convaincre, comparez gnome-netinfo avec l'equivalent macosx, j'ai rarement vu deux applis se ressembler autant :)
[^] # Re: Et les icônes ?
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Et toujours dans gnome-network , si on lance gnome-remote-desktop, ça ressemble comme 2 gouttes d'eau à "Connexion Bureau à distance" sous Windows. Pour te paraphraser, j'ai rarement vu deux applis se ressembler !
De plus dire que GNOME suit MacOS X est d'une stupidité sans limite, et pour cause, GNOME est né bien avant MacOS X !!!
[^] # Re: Et les icônes ?
Posté par Matthieu Moy (site web personnel) . Évalué à -1.
Si on dit "Gnome 2.4 suit MacOS X", ça te va mieux ?
[^] # Re: Et les icônes ?
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Non.
Avant d'écrire des phrases pareil, faudrait commencer par utiliser Mac OS X.
J'ai Mac OS X 10.2.7 sur mon iMac et franchement, je ne trouve pas de point commun entre Mac OS X et GNOME. Ha si yen a un, dans les 2 cas la corbeille s'appelle "Corbeille". C'est fou ça !
[^] # Re: Et les icônes ?
Posté par gnumdk (site web personnel) . Évalué à 0.
Sauf que gnome 1 et gnome 2 n'ont rien en commun !!! Gnome suit le meme principe que macosx, un gui simple sans trop d'options... Les widgets de gnome sont proche de ceux de macosx, la facon dont les applis sont présentées aussi, l'outil de recherche de gnome ressemble comme deux gouttes d'eau a celui de macosx, l'appli de monitoring du reseau aussi...
[^] # Re: Et les icônes ?
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
ha oui, alors là tout est dit, on peut rien rajouter !
[^] # Re: Et les icônes ?
Posté par jcs (site web personnel) . Évalué à 2.
[^] # Re: Et les icônes ?
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Et les icônes ?
Posté par oliv . Évalué à 2.
Mais ils ont corrigé un 2eme bug avec les dernières versions des toolkits et environements qui empêchait le DnD entre applications. Maintenant (depuis KDE 3.1), on peut glisser et déposer un fichier de Konqueror dans Gimp 1.3. :) (ce qui n'était pas possible dans le 3.0).
[^] # Re: Et les icônes ?
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
Si le theme engine prend en charge la notion des icones standard, ca marche.
Si il permet de choisir le placement Oui/Non ou Non/Oui, ca marche aussi.
etc.
Tout semble dependre du niveau d'abstraction fournie par la notion de "theme engine". Des experts Gnome peuvent peut-être donner leur avis pour nous éclairer...
Des experts KDE peuvent peut-être nous dire si un tel niveau d'abstraction existe avec Qt.
[^] # Re: Et les icônes ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
C'est typiquement ce genre de travail que je voudrais voir aux RMLL. D'ailleurs, c'est ce travail de convergence qui m'a fait imaginer les RMLL en 1999,
J'aimerais que des développeurs de Gnome et Kde prennent le sujet en main afin qu'on puisse le faire une bonne place aux RMLL 2004 qui se dérouleront à Bordeaux.
Si vous avez des idées sur cela n'hésitez pas à nous contacter.
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Gnurou (site web personnel) . Évalué à 1.
La version 0.2 est presque utilisable (eclipse se lance parfaitement avec, mais certaines scrollbars sont buguées et les checkbox n'apparaissent pas en entier chez moi), j'y passerai sans doute définitivement à la prochaine version.
# Vivement qu'on arrete de s'enfoncer
Posté par Manwe . Évalué à 7.
KXUL est déjà en préparation (Interpréteur pour KDE).
A quand un GXUL pour gnome et un XXUL pour etre sur que ca fonctionne partout.
En plus, ca permettrait à l'utilisateur de modifier lui meme le visuel et certains comportements de ses applications.
http://xulfr.org/(...)
http://www.mozilla.org/projects/xul/(...)
http://www.xulplanet.com/(...)
http://xul.sourceforge.net/(...)
Franchement, autant faire OpenOffice en XUL dès maintenant...
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Troy McClure (site web personnel) . Évalué à 7.
Donc tu proposes de remplacer un framework lourd pour les programmeurs par un framework lourd pour les utilisateurs :°)
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Elrik de Melnibone . Évalué à -1.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Richard Van Den Boom . Évalué à 3.
Je suis un programmeur plutôt genre gros nase (globalement, j'ai fais du fortran durant mes études de physique). Je me suis mis à Python et avec PyQT, j'ai pu coder une application graphique à peu près décente en environ un mois de boulot pas vraiment acharné, apprentissage du langage et de l'API PyQT inclus.
En quoi est-ce donc "lourd à programmer"?
Qu'est-ce que XUL (donc les exemples d'utilisation actuels genre Mozilla sont pas vraiment révélateurs de grandes possibilités suplémentaires par rapport aux autres toolkits) peut changer à ça?
Je ne dis pas que tu as tort mais ne connaissant pas XUL, je n'en vois pas trop l'avantage pour le moment.
Richard.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Manwe . Évalué à 4.
Ensuite, de n'écrire qu'une fois l'interface quelle que soit l'OS / le Window Manager utilisé.
De plus, ces interfaces sont automatiquement compatibles WEB à travers Firebird ou Mozilla, ou meme gràce à un des multiples interpréteurs XUL en Java.
Les plus beaux exemples sont, je pense, Firebird et Thunderbird que je ne trouve pas lourds du tout !
Je ne propose pas :
- XUL -> KXUL -> Qt/Gtk -> Ecran mais plutot
- XUL -> KXUL -> Ecran
- XUL -> GXUL -> Ecran
- XUL -> XXUL -> Ecran
- XUL -> WinXUL -> Ecran
- XUL -> MacXUL -> Ecran
Sachant que tous sont possibles et chaque systeme améliore régulierement son framework.
Ca existe déjà depuis bien longtemps dans certains languages comme vous le faites remarquer mais l'objectif est d'en avoir un complet et le plus universel possible entierement en XML.
Je suis persuadé que ca va se répendre exponentiellement.
PS : MS aussi s'y met avec XAML.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par enicolas . Évalué à 0.
Tout le monde le fait aussi avec QT ou GTK. Ca s'appel le modèle de programmation MVC. Rien de nouveau.
> Ensuite, de n'écrire qu'une fois l'interface quelle que soit l'OS / le Window Manager utilisé.
Idem avec QT ou GTK : tu écris ton application une seule fois, c'est le toolkit qui est porté sur les diverses plateformes.
> De plus, ces interfaces sont automatiquement compatibles WEB
Ca veut dire quoi une "GUI compatible WEB"... ???
> Je suis persuadé que ca va se répendre exponentiellement.
C'est bizarre, actuellement, à part Mozilla, personne n'a accroché. Elle a du mal à décoler ton exponentielle !
> PS : MS aussi s'y met avec XAML.
Ca me ferait plustôt dire que c'est la voie à ne pas suivre alors, vu la propention de Microsoft à toujours choisir la mauvaise solution à un problème...
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Manwe . Évalué à 0.
C'est du Modele Vue Controlleur mais l'interface est pas (forcément) compilée et en XML, donc éditable.
Ca devient facile d'unifier les visuels d'un environnement, de supprimer des fonctionnalités, d'inverser leur emplacement, sans avoir à recompiler le logiciel et sans risque.
Faut voir si on perd vraiment breaucoup à interpreter au lieu de compiler.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par tanguy_k (site web personnel) . Évalué à 2.
> Idem avec QT ou GTK : tu écris ton application une seule fois, c'est le toolkit qui est porté sur les diverses plateformes.
Nan c'est beaucoup plus puissant.
Utilise Glade et libglade (le seul truc de bien avec GTK...) ou encore Qt Designer et le chargement dynamique des .ui, et tu comprendras.
Avec Glade tu dessines ton interface graphique. Aucun besoin d'avoir des connaissances en programmation. Ca genere un simple XML.
Ensuite le XML qui decrit l'interface est charge et interprete dynamiquement au lancement du programme.
- separation beaucoup plus grande entre l'interface et le reste
- simplicite du code -> temps de developpement, meilleure maintenabilite, moins de lignes de code...
- l'interface graphique peut etre faite par une personne tierce sans probleme
- pas de temps de compilation de l'interface
- changement de l'interface tres tres facile (modifier le fichier XML et relancer le binaire sans recompiler)
- meilleure portabilite: il suffit de creer un nouvel interpreteur pour le code XML sur la plateforme que l'on veut. On pourrait meme faire un interpreteur pour handicapes par example sans meme devoir recompiler le code source des programmes. Ou meme un interpreteur HTML avec le programme qui tourne en cgi sur le serveur web.
- l'interface graphique peut tourner sur une machine et le reste sur une autre.
- ...
Au niveau performance, il est toujours possible de revenir a du binaire: transformer le XML en du code source (Qt le fait).
Mais avec Glade et Qt Designer il faut tout de meme programmer en dur les actions que vont avoir l'interface sur le reste du programme.
J'imagine (je ne sais pas car je ne l'ai jamais utilise) que XUL est plus puissant qu'un truc comme libglade car il va encore plus loin au niveau de la separation de l'interface et du programme.
XUL a ete pense depuis le debut dans cette optique.
De toute facon je ne vois pas ce qu'une separation encore plus pousse entre une interface graphique et son programme pourrait avec de mal, c'est une evolution logique. Wait and see.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Philippe F (site web personnel) . Évalué à 2.
Sans blague ? Tu veux dire qu'il ne t'ecrit pas ton programme tout seul, tu as encore du code a ecrire ? Mon dieu, c'est atroce. Vivement l'IDE qui comprend tout seul ce que tu veux faire, et ou tu n'as meme pas besoin de toucher le clavier.
> XUL est plus puissant qu'un truc comme libglade car il va encore plus
> loin au niveau de la separation de l'interface et du programme.
> XUL a ete pense depuis le debut dans cette optique.
Ok, on peut faire des boutons et des machins en XUL. Mais on peut deja le faire avec Qt Desgner. Sous KDE, les menu d'une application et sa barre d'outils sont aussi definis par un fichier XML donc on est a mon avis au meme niveau que XUL.
Mais si tu crois que faire une interface grapnique, c'est faire un programme tu te trompes. Mon experience de programmation en Qt et de KDE, c'est que l'interface devient facile a coder. Il reste plus qu'a faire l'intelligence et pour ca, XUL ne peut pas t'aider.
De plus, si tu veux faire un programme evolue, tu as besoin d'avoir un controle tres precis de tes elements graphiques, et souvent, tu es amenu a en inventer. J'aimerai voir un KOffice, KDevelop ou khtml ecrit en XUL. Pour khtml, je sens venir le "mais il y a gecko justement". Et bien non, gecko, c'est un composant de mozilla ecrit un C avec les Netscape Portable Library, il n'apporte rien de plus en terme de facilite de develloppement par rapport a Qt. C'est juste que l'interface est plus facilement modifiable, mais c'est aussi le cas avec Qt si tu utilises des .ui charges dynamiquement.
Citation du "joy of XUL" sur le site de Mozilla, a propos du calendrier ecrit en XUL:
<<
the UI code is written in JavaScript, [...] the interaction logic worked with no effort. However, since the libical library is written in C, more significant effort was required to migrate this component to the other platforms.
>>
Donc en resume, c'est tout pareil que Qt, sauf que tu as du C et du javascript pour developper ton appli. L'avantage de Qt, c'est qu'au moins, la portabilite est _tres_ facile, contrairement a l'exemple donne ici.
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo. Et Komodo, l'IDE d'ActiveState developpe en technos mozilla est un IDE les plus lents que j'ai jamais utilise (ceci dit, c'etait avant d'utiliser des IDE full java). Donc, je suis tres scriptique face a cet argument.
Pour resumer le fond de ma pensee: XUL, c'est bien pour des applications relativement simples, qui peuvent tout aussi bien etre ecrites en Visual Basic, PyQt voire Kommander (http://quanta.sourceforge.net/main2.php?snapfile=snap02(...)).
Quand tu dois coder des choses complexes, tu as besoin d'un vrai toolkit, et c'est la ou tu apprecie la puissance d'un vrai truc comme Qt ou Gtk.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est quoi ton probleme ? j'explique simplement comment ca fonctionne rien de plus, j'ai jamais dit que c'etait difficile...
Si tu veux je change un mot dans la phrase pour que tu arretes de t'exciter: avec Glade et Qt Designer il faut evidemment programmer en dur les actions que vont avoir l'interface sur le reste du programme.
> XUL est plus puissant qu'un truc comme libglade
J'ai pas dit que c'etait plus puissant, j'ai dit que ca devrait etre plus puissant car concu des le depart pour. J'ai bien precise que je n'avais jamais utilise XUL. Si j'imagine que XUL est plus puissant que libglade c'est aussi parceque si ca ne l'etait pas, ils auraient utilise libglade. Apres je peux me tromper puisque j'ai jamais essaye.
> firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo.
La puissance des ordinateurs evoluent. Probablement que l'overhead d'une approche comme XUL sera negligeable dans 5 ans par rapport aux fonctionnalites que ca apporte aux developpeurs/utilisateurs. Mais refuser la technologie en voyant que les defaults sans voir les avantages est stupide.
< ma pensee>c'est comme ca que l'on aboutit aujourd'hui a des aberrations comme programmer en C des applications desktop</ ma pensee>
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Erwan . Évalué à 1.
Il y a une idee repandue qui dit que "XUL est la meilleure facon de decrire les interfaces graphiques". C'est ce que je pense aussi, mais vouloir balayer Gtk et Qt est stupide. Deja, Mozilla se base sur Gtk dans sa version Linux... Mais ce serait bien que glade et Qt Designer adoptent le format XUL, car techniquement c'est tres complet et avoir un format commun faciliterait beaucoup les choses pour tout le monde: apprentissage plus simple, portage plus simple.
Par contre, ce qui me herisse les cheveux:
Pour ce qui est de la legerete de XUL, firebird prend 27 mo de memoire en ce moment sur ma machine windows alors que opera qui fait la meme chose tourne autour de 12 Mo.
Ce qui est leger c'est la facon dont on programme.
Je suis d'accord sur les fait que les auteurs de Mozilla ont eu tort de tout melanger: Gecko Runtime Engine (GRE ; eh oui, Gecko n'est pas seulement le moteur de rendu mais c'est aussi lui qui traite le XUL), navigateur, lecteur de courriel... Ils ont maintenant fait le choix de separer tout ca.
La taille de Firebird diminue a mesure que les developpeurs parviennent a isoler le code inutile au navigateur. Regarde la taille des release depuis la 0.1. La derniere operation sera la separation de la GRE pour etre partagee avec Thunderbird.
Pour finir, avec de l'interprete dedans ce sera forcement plus gros. C'est le prix a payer, mais quand tu vois les extensions sur http://www.mozdev.org(...) il n'y a pas photo. Dire que Opera fait la meme chose que Firebird, c'est n'avoir jamais essaye de coder une extension firebird (on fait des choses tres puissantes en trois lignes) ou meme d'installer une des nombreuses extensions se trouvant sur http://www.mozdev.org(...)
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par __caffeine__ . Évalué à 4.
Maintenant, pourquoi ça ne marchera pas sur un desktop comme KDE (et sans doute pour Gnome, que je connais moins, les connaisseurs complèteront) ?
KDE c'est plus que des widgets supplémentaires pour Qt, c'est tout un bureau qui interagit et qui a été pensé ainsi dès le début. Le système des KParts permet d'utiliser des morceaux entiers d'applications dans d'autres, on peut piloter une appli à partir d'une autre avec DCOP, tout un tas de trucs que je me vois mal retranscrire dans un fichier XUL (du moins en l'état actuel des choses).
Les services auquels une appli XUL+javascript accède actuellement sont implémentés par XPCOM, un ensemble de services avec un cadre bien précis et pas généraliste comme, disons, KDE ou même wxWindows. XUL est donc en grande partie défini par ce que XPCOM peut et a le droit de faire; ce qui m'amène au point suivant, la sécurité: offrir un accès direct au matériel pour des choses comme OpenGL ou du son à une technologie destinée avant tout au web, c'est ouvrir des trous de sécurité énormes (voir le nombre de failles IE en rapport avec l'intégration de bidules qui causent directement à DirectX)
Si tu veux profiter de toutes les fonctionnalités avancées qui font un desktop moderne (OpenGL, fonctionnalités multimedia, intégration des applis les unes avec les autres), tu te retrouveras à écrire des extensions de XUL pour chaque spécificité (XUL-Kparts, XUL-bonobo, XUL-GL, XUL-scintilla...) et tu auras du code pas vraiment plus portable qu'un fichier Glade à utiliser avec Qt-designer...
Ceci dit, XUL a ses avantages (très rapide à apprendre et à utiliser), je le vois très bien prendre sa place chez Gnome ou KDE pour de "petites" applis (un aggrégateur de news, une interface graphique à une appli en ligne de commande), mais ça ne collera simplement pas pour des choses plus intégrées au système.
Et pour finir sur un [:troll]:
à quand XUL-emacs ?
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Gniarf . Évalué à 1.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Mouais. L'idée n'est pas neuve, même Motif avait déjà ça y a 10 ans (ça s'appelait wml). Le problème c'est que ça marche très bien pour "dessiner" ton interface, mais pour la gestion de l'interactivité c'est vite délicat.
Toutes ces idées géniales au prime abord s'écroulent devant le même problème : "the devil is in the details".
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Manwe . Évalué à 1.
http://www.devx.com/DevX/Article/17899(...)
Il semble aussi etre d'accord avec moi pour l'exponentielle :)
Objectif de programmation : assembler des briques avec toujours la possibilité de créer les manques si "The Evil is in the detail".
Je vote : OpenOffice en XUL, Qt/Gtk compatibles XUL que ce soit en compilation ou interpretation.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Éric (site web personnel) . Évalué à 2.
Un peu comme fait déjà glade avec son fichier XML quoi ... ;)
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Erwan . Évalué à 2.
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Jérôme FIX (site web personnel) . Évalué à 4.
Il existe sous QT une manière d'utiliser les .ui à la manière des fichiers de glade.
http://doc.trolltech.com/3.2/designer-manual-6.html(...)
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Moby-Dik . Évalué à 2.
En plus, ca permettrait à l'utilisateur de modifier lui meme le visuel et certains comportements de ses applications.
Ouais, vachement user-friendly les fichiers de ressources en XML. Ma grand-mère te customise ça en un clin d'oeil.
Franchement, autant faire OpenOffice en XUL dès maintenant...
T'as raison, c'est pas assez lourd OpenOffice. Relançons les ventes de processeurs !
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Manwe . Évalué à 1.
Je suis pas persuadé que le résultat soit plus lourd...
Franchement, je demande à voir.
Je pense que l'équipe OpenOffice se retrouve avec le meme problème (l'héritage de l'organisation de programmation de StarOffice) que l'équipe Mozilla avec le Blob Netscape.
Au vu des résultats obtenus (Stabilité et Performance) par l'équipe Mozilla, je me demande si ce n'est pas un exemple à suivre.
Sinon, je serait quand meme partisant que Gtk puisse compiler ou utiliser du XUL. Et pareil pour tous les autres. Qu' on adopte au maximum un langage commun...
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Éric (site web personnel) . Évalué à 3.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par MagicNinja . Évalué à 4.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Romain Vinot . Évalué à 5.
Ensuite, ça reste un but difficile à atteindre : as-tu déjà réussi à trouver un thème GTK ou QT qui reproduise EXACTEMENT le(s) toolkit(s) de WIndows ? Il y a toujours quelques différences de quelques pixels quelque part qui annule tous les bénéfices de la chose.
Il faut également penser à gérer les problèmes de couleur (sous KDE tu peux changer les couleurs de tout et n'importe quoi, il faut que cela soit également pris en compte par les applis GTK : d'où le moteur de thème qtPixmap).
Pour OpenOffice, ça n'est pas une solution puisque le toolkit par défaut n'est pas thémable du tout.
Et enfin, ça ne résoud que les problèmes de thème, pas les autres problèmes d'intégration (cf ci-dessus).
Cela dit, ça marche relativement bien : cf BlueCurve (RedHat), Galaxy (Mandrake) mais aussi Keramik/Geramik, ThinKeramik/ThinGeramik.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par jujubinche007 . Évalué à 1.
nazes certes, mais ils existent.. (apple / X11 / win ... )
alors ? y'a pas moyen de réutiliser ça ?
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Etienne Juliot (site web personnel) . Évalué à 3.
Il y a un projet démarré dans ce sens, mais l'auteur ne veut pas changer sa licence, qui empêche toute intégration dans Eclipse.
http://dot.kde.org/1028559499/1028663211/1033493333/1033507405/(...)
http://www.laurentm.com/10Goto10/archives/java/000071.html(...)
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par totolaricot . Évalué à 1.
IBM a ecrit un port de SWT pour Qt. Ca fait longtemps qu'il existe, et il est sans doute aussi stable que le reste des portages. Le probleme est purement legale. Comme je l'ai indique, il s'agit de la license the Qt (GPL/LGPL) qui n'est pas compatible avec celle de SWT (CPL).
En consequence, Eclipse ne peut pas distribuer SWT-Qt via le site Open Source. Ca n'est pas la faute d'IBM, mais bel et bien une restriction venant de la FSF (createur des licenses GPL et LGPL).
En generale, la question suivante est "pourquoi IBM ne change pas la license de Eclipse et utilise la LGPL au lieu de la CPL?". La reponse est tres simple... CPL EST INFINIMENT PLUS RELAXE QUE LGPL. La preuve en est que SWT-Qt ne peut pas etre distribue parceque la LGPL force des contraintes sur les travaux derives de projets sous la LGPL.
Pour une fois, je donne raison a IBM qui a decide de creer une licence SANS AUCUNE CONTRAINTES. La license CPL est du meme ordre que la license BSD, et n'impose aucune contraintes pour la redistribution.
Dans tous les cas, cette restriction ne s'impose que pour des travaux publics qui incluent le source (Eclipse.org). IBM n'est pas impacte par cette restriction lorsqu'il distribue WSAD sous forme de "closed source". Et donc, la version WSDD (device developer) inclue une version de SWT-Qt pour developer sur des platformes embedded.
makes sense?!
http://www.laurentm.com/10Goto10/(...)
PS: je suis un francais expatrie en amerique du nord depuis 8 ans, et ravi de voir que Linux est populaire en france. :) Pour ce qui est des details techniques, je participe en ce moment a l'ecriture d'un livre a paraitre cette annee sur SWT et JFace (la couche graphique au dessus de SWT).
# La fusion, c'est pour bientôt ???
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 4.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par BoB . Évalué à 2.
- QT/GTK sont tous les deux plus grands toolkits. Une fusion rendrait toutes les interfaces d'un coup bien plus homogènes.
- Mais la concurence, c'est bien!! Je pense que les deux se stimulent mutuellement.
- Enfin, je crois que techniquement c'est pas vraiment possible (trop de différences).
Bref, sans être un expert, je pencherais pour la solution xul, qui permet que tous les softs utilisent le même toolkit, mais en plus c'est pas déterminé à la compilation (ce qui est embêtant si on décide de changer, ou que plusieurs personnes travaillent sur le même ordinateur...)
[^] # Re: La fusion, c'est pour bientôt ???
Posté par enicolas . Évalué à -1.
- GTK c'est du C, QT c'est du C++. Donc ca ne sera jamais possible d'avoir qqchose de commun à cause du langage.
- GTK utilise des widgets "natifs" (win32, motif, QT maintenant), QT dessine tout lui-même, ce n'est pas la même approche du tout
[^] # Re: La fusion, c'est pour bientôt ???
Posté par enicolas . Évalué à 0.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par tanguy_k (site web personnel) . Évalué à 1.
Ouah on en apprend des choses ici ! Je suis sur que tu as des liens pour etayer ce que tu viens de dire. Parceque moi j'ai des liens qui prouvent l'inverse.
http://gaim.sourceforge.net/downloads.php(...)
Essayes Gaim 0.74 pour Windows (GTK 2.2.4), ca ressemble de loin a du natif win32 mais des que l'on veut sauvegarder une conversation, on obtient la fameuse boite de dialogue de GTK toute pourrie. Il ne faut pas confondre wxWindows et GTK.
En revanche Qt sous Windows c'est deja beaucoup plus ressemblant a du natif (perso je vois pas la difference): http://psi.affinix.com/?page=download(...)
La boite de dialogue pour ouvrir un fichier sonore est une boite de dialogue native win32 a 100%
> Il ne faut pas oublier que QT n'est libre que sur certaines plateformes !
- GTK sous MacOSX ? y'a presque rien, neant juste un pauv screenshot qui demontre que GTK sous mac c'est justement pas du natif: http://gtk-osx.sourceforge.net/pix/gtktestthing.aqua.buttons.jpg(...)
Qt est dispo sous license GNU GPL sous MacOSX et fonctionne parfaitement depuis pas mal de temps deja. Au passage KOffice vient d'etre porte sous MacOSX: http://ranger.befunk.com/screenshots/qt-mac-kspread-20040101.png(...)
- GTK sous Windows ?
J'ai eu le malheur de programmer avec -> plus jamais !
Donc oui si tu veux GTK est libre sur toutes les plateformes mais comme c'est inutilisable... Au moins avec Qt si tu payes ca fonctionne sur toutes les plateformes.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par Christophe Fergeau . Évalué à 1.
Super... Ça ne change pas grand chose au fait quetu peux pas faire un truc libre sous windows avec Qt (tout du moins un truc gpl)
gtk+ tu peux faire des applis libres ou non sous linux et windows sans débourser un centime par contre. Si le support macosx te manque, libre à toi de l'ajouter ;)
[^] # Re: La fusion, c'est pour bientôt ???
Posté par tanguy_k (site web personnel) . Évalué à 0.
Super et on dit encore plus de conneries...
Hop un contre-exemple: http://psi.affinix.com/(...) en Qt dispo sous Unix, MacOSX et Windows.
http://psi.affinix.com/forums/index.php?act=ST&f=1&t=428(...) Psi is released under the General Public Licence
Tu peux programmer des logiciels libres avec Visual, Borland... pourtant c'est des logiciels proprietaires que tu payes. De meme il y a des tonnes de logiciels libres pour Windows alors que c'est proprietaire et payant.
> Si le support macosx te manque, libre à toi de l'ajouter ;)
Si le support Qt Win32 sous licence GNU GPL te manque, libre à toi de l'ajouter ;)
Et hop un project Qt win32 sous licence GNU GPL: http://kde-cygwin.sourceforge.net/qt3-win32/(...)
[^] # Re: La fusion, c'est pour bientôt ???
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par tanguy_k (site web personnel) . Évalué à 0.
Ecrire dans la licence de son programme en plus de la GPL: j'autorise le link de mon soft avec la lib bidule ca change pas grand chose.
De toute facon cette close est tellement ambigue que j'ai l'impression que personne ne la respecte:
Combien de softs libres GPL programmes en Visual Basic, Delphi, .NET et avec le JDK de Sun ? A la rigueur win32 SDK ok c'est la lib native de Windows mais le reste pour moi c'est des surcouches proprios.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par Christophe Fergeau . Évalué à 4.
Bah ca change que t'as plus le droit de repomper du code GPL à droite et à gauche sans rien demander à personne pour l'intégrer dans ton projet, ça fait quand même une grosse différence à mes yeux
[^] # Re: La fusion, c'est pour bientôt ???
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Qu'est-ce qu'il faut pas lire... GTK a ses propres widgets, comme Qt.
[^] # Re: La fusion, c'est pour bientôt ???
Posté par Éric (site web personnel) . Évalué à 1.
Je crois que c'est un peu le principe de wxwindow (qui permet de sortir en gtk, en natif win, en motif ...). Quelqu'un pour confirmer l'éventuelle possibilité ?
# Et ce n'est pas fini....
Posté par cmiramon . Évalué à 1.
Plusieurs développeurs KDE sont en train de travailler à un système de pseudo-fichiers pour les Ioslaves de KDE. Cela veut dire concrètement que si vous accédez à un fichier par ssh avec l'ioslave fish, vous pourrez créer un pseudo-fichier sur votre répertoire home puis ouvrir le fichier dans OpenOffice ou dans n'importe quelle application linux.
Du code de qualité alpha fonctionne déjà. Une fois le code un peu mieux stabilisé, nous ferons certainement une annonce sur le dot.
Charles
# Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par halt . Évalué à 2.
OOo n'est pas assez lourd déjà?
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par tanguy_k (site web personnel) . Évalué à 1.
Lis les commentaires sur dot.kde et tu comprendras.
http://dot.kde.org/1073557624/1073579730/(...)
The emulation works the following way: It uses QStyle to draw to a pixmap, which is then copied to the screen. Then OOo's toolkit draws the text over it. The difference between this approach and real Qt/KDE application is one bitblt operation (pixmap->screen).
The memory usage? One instance of KApplication, one instance of each widget to be "emulated" (QPushButton, QRadioButton, ...), and one temporary QPixmap. And of course shared Qt and KDE libraries, which anyone running KDE has in the memory anyway.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Les gens qui voudront un truc rapide feront du Gtk natif, ceux qui seront prets a sacrifier un peu pourront faire du Gtk-Qt. Mais le "un peu" sacrifié, ce n'est que pour le dessin des widgets, donc, par exemple, pas pour le boot.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par halt . Évalué à 1.
C'est pas forcément très gênant mais ça fait pas très .... propre.
[^] # Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par gnumdk (site web personnel) . Évalué à -1.
- Sous macosx ca rame a fond
- Sous windows : niquel
- Sous kde: niquel
-Sous gnome: je pense que ca peut etre amélioré, il me semble que gtk est un peu lent au rafraichissement(je parle du bureau de gnome qui ne clignote jamais(pas comme celui de kde:) mais semble ramer un peu quand on deplace un fenetre et que le sys est chargé... cela n'arrive pas sous kde
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.