Articles précédents : Développeur
- [22] UML2PHP5 version 0.3
- [2] Résumé GNOME 13-12-2003
- [11] "Débats virtuels" autour des *BSD
- [13] Les coulisses du développement de Python
- [20] Résumé GNOME 06-112-2003
- [32] Anjuta 1.2
- [10] Le nouvel OpenZaurus est arrivé !
- [17] Résumé GNOME 29.11.2003
- [36] Concours de Développement pour Eclipse
- [77] Créer des applets Web avec Mozilla et XUL
Liens connexes
- News GTK-Qt Theme Engine sur dot.kde (1120 hits)
- Téléchargement de GTK-Qt Theme Engine (1031 hits)
- Capture d'écran de GTK-Qt Theme Engine (1824 hits)
- News OOo KDE sur dot.kde (473 hits)
- OOo KDE Native Widget Framework (624 hits)
- Capture d'écran de OOo KDE (1993 hits)
Dépêche modérée par
Développeur : GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par tanguy_k (page perso, ). Modéré le 09 janvier 2004.
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.
![[en]](../../../images/en.png)
News GTK-Qt Theme Engine sur dot.kde (1120 hits)-
Téléchargement de GTK-Qt Theme Engine (1031 hits)
-
Capture d'écran de GTK-Qt Theme Engine (1824 hits)
-
News OOo KDE sur dot.kde (473 hits)
-
OOo KDE Native Widget Framework (624 hits)
-
Capture d'écran de OOo KDE (1993 hits)
> Lire la dépêche (78 commentaires, moyenne: 2).
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.
Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Le procédé inverse existe-t-il ? Ca m'intéresse bien, je n'ai pas de desktop intégralement qt ou gtk (anti-icones), mais de manière générale je trouve que hum, vous savez comme tout le monde dit, "qt saih moche".
-
[^]Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par farib () le 09/01/2004 à 08:07. (lien). Évalué à 1.Hum, je dirais plutôt que le Qt par défaut, sans thèmes, est moche. J'ai quelques applis KDE mais pas le bureau KDE complet (j'ai le bureau Gnome), et j'ai pas installé encore les superbes thèmes disponibles sur kde-look.org, et effectivement, c'est pas terrible.
-
[^]Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Lionel Fournigault () le 09/01/2004 à 08:08. (lien). Évalué à 4.Le procédé inverse me semble plus difficile. Sinon concernant QT les faits sont tétus, il
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 Michel Galle () le 09/01/2004 à 08:52. (lien). Évalué à 1.qu'y a t'il de compliquer à ecrire pour QT un thème appelant des widgets GTK ?
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 (page perso, ) le 09/01/2004 à 11:03. (lien). Évalué à 4.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.
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 () le 09/01/2004 à 12:51. (lien). Évalué à -2.> qu'y a t'il de compliquer à ecrire pour QT un thème appelant des widgets GTK ?
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 (page perso, ) le 09/01/2004 à 13:24. (lien). Évalué à 1.ça veut rien dire ça...
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 (page perso, ) le 09/01/2004 à 09:07. (lien). Évalué à 2.Que l'inverse soit possible ou non ne depend que de Qt.
-
[^]Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Superted () le 09/01/2004 à 09:24. (lien). Évalué à 1.Ba non, ça dépend des deux. Il faut qu'il soient capable d'interopérer ensemble, mais dans l'autre sens. 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.
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 (page perso, ) le 09/01/2004 à 11:25. (lien). Évalué à 1.Ce que j'ai dit n'a rien d'un troll.
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 (page perso, ) le 09/01/2004 à 13:56. (lien). Évalué à 1.Ce que j'ai dit n'a rien d'un troll.
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 Fremy (page perso, ) le 09/01/2004 à 14:46. (lien). Évalué à 4.> Qt est au même niveau que GTK+
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 (page perso, ) le 09/01/2004 à 15:56. (lien). Évalué à 1.C'est tout a fait faux.
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 (page perso, ) le 09/01/2004 à 16:07. (lien). Évalué à 1.> 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.
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 Fremy (page perso, ) le 10/01/2004 à 09:35. (lien). Évalué à 1.Tout a fait, c'est gdi, pas win32. Win32 est aussi une boite a outil graphique.
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 () le 09/01/2004 à 21:27. (lien). Évalué à 3.>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.
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 (page perso, ) le 09/01/2004 à 14:04. (lien). Évalué à 1.Méééheu, c'est pareil...
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
* Un package Mandrake 9.2 concocté par le sieur Sagittarius:
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 (page perso, ) le 09/01/2004 à 08:11. (lien). Évalué à 2.Mais non, c'est pour montrer la bonne importation des documents MS Office sous OpenOffice ;o)
Et les icônes ?
Pas mal du tout...
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 Michel Galle () le 09/01/2004 à 08:58. (lien). Évalué à 3.pour les icones dans les applciations, cela devrait s'arranger
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 () le 09/01/2004 à 12:35. (lien). Évalué à 1.C'etait deja le cas avec les anciennes version de gtk...
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 (page perso, ) le 09/01/2004 à 17:39. (lien). Évalué à 2.Ben voyons.
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 (page perso, ) le 09/01/2004 à 18:01. (lien). Évalué à -1.Et Kde est né bien avant Windows XP, donc, Kde ne copie pas Windows XP, c'est ça ?
Si on dit "Gnome 2.4 suit MacOS X", ça te va mieux ?-
[^]Re: Et les icônes ?
Posté par Christophe Merlet (page perso, ) le 09/01/2004 à 18:09. (lien). Évalué à 4.> Si on dit "Gnome 2.4 suit MacOS X", ça te va mieux ?
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 () le 09/01/2004 à 19:36. (lien). Évalué à 0."GNOME est né bien avant MacOS X !!! "
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 (page perso, ) le 09/01/2004 à 20:19. (lien). Évalué à 3.> Les widgets de gnome sont proche de ceux de macosx
ha oui, alors là tout est dit, on peut rien rajouter !
-
-
-
-
-
[^]Re: Et les icônes ?
Posté par jcs (page perso, ) le 09/01/2004 à 10:22. (lien). Évalué à 2.Sans oublier le problème du drag'n'drop entre les applications.
-
[^]Re: Et les icônes ?
Posté par Christophe Fergeau () le 09/01/2004 à 10:37. (lien). Évalué à 2.C'est censé être à peu près standardisé (ie pour des trucs simples ca doit marcher, pour des trucs plus complexes, si ca fonctionne pas c'est un bug qui doit être corrigé)
-
[^]Re: Et les icônes ?
Posté par oliv () le 09/01/2004 à 12:23. (lien). Évalué à 2.Il y a un bug ouvert chez KDE pour un problème d'implémentation du XDnD depuis 2-3 ans, qui n'évolue pas.
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 (page perso, ) le 09/01/2004 à 11:51. (lien). Évalué à 1.Si j'ai bien compris, cela repose sur le "theme engine". Tout dépend donc de ce que le theme engine gère (désolé, moi j'aime la ligne de commande, les mondes Gnome et KDE je m'en sert assez peu) et de comment il peut evoluer.
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 (page perso, ) le 09/01/2004 à 13:39. (lien). Évalué à 2.Bref, ça avance, mais c'est pas fini...
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
Tout bonnement génial.
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
Seule la programmation en XUL (XML User Interface Language) pourra nous sortir de ces systemes de Framework graphiques lourds à programmer, non compatibles et dont la compatibilité entre versions est délicate à gèrer.
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 (page perso, ) le 09/01/2004 à 09:30. (lien). Évalué à 7.> Seule la programmation en XUL (XML User Interface Language) pourra nous sortir de ces systemes de Framework graphiques lourds à programmer
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 () le 09/01/2004 à 09:35. (lien). Évalué à -1.merci pour la lourdeur !
-
[^]Re: Vivement qu'on arrete de s'enfoncer
Posté par Richard Van Den Boom () le 09/01/2004 à 09:36. (lien). Évalué à 3.Développe.
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 Ulmo () le 09/01/2004 à 10:54. (lien). Évalué à 4.L'objectif premier est de séparer completement UI et Traitement.
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 () le 09/01/2004 à 12:55. (lien). Évalué à 0.> L'objectif premier est de séparer completement UI et Traitement.
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 Ulmo () le 09/01/2004 à 13:34. (lien). Évalué à 0.Mais si, mais si. Si c'est pas XUL, ca aura un autre nom mais un systeme de ce type va s'imposer. :)
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 (page perso, ) le 09/01/2004 à 14:38. (lien). Évalué à 2.> Tout le monde le fait aussi avec QT ou GTK. Ca s'appelLE le modèle de programmation MVC. Rien de nouveau.
> 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 Fremy (page perso, ) le 10/01/2004 à 10:23. (lien). Évalué à 2.> 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.
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 (page perso, ) le 11/01/2004 à 14:47. (lien). Évalué à 1.> 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.
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 (page perso, ) le 12/01/2004 à 03:50. (lien). Évalué à 1.Je suis d'accord sur le fond: XUL se compare a PyQT (ne me parle pas de cette horreur de VB).
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__ () le 09/01/2004 à 13:21. (lien). Évalué à 4.Des interpréteurs XUL->GTK ou XUL->GTK, pourquoi pas, mais comme dit plus haut, les deux toolkits ont déjà la possibilité de créer leurs widgets d'après du XML.
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
-
-
[^]Re: Vivement qu'on arrete de s'enfoncer
Posté par Guillaume Laurent (page perso, ) le 09/01/2004 à 16:24. (lien). Évalué à 2.Je suis persuadé que ca va se répendre exponentiellement.
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 Ulmo () le 13/01/2004 à 09:05. (lien). Évalué à 1.Plus d'infos sur XUL et XAML ou comment Moucro$oft a bien pompé l'architecture Mozilla.
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 (Jabber id, page perso, ) le 09/01/2004 à 09:47. (lien). Évalué à 2.Tu veux dire faire du XML, puis charger dans l'application ce fichier XML afin qu'il trace tout seul les widget (gtk, qt ou autre) ?
Un peu comme fait déjà glade avec son fichier XML quoi ... ;)-
[^]Re: Vivement qu'on arrete de s'enfoncer
Posté par Infernal Quack (Jabber id, page perso, ) le 09/01/2004 à 10:15. (lien). Évalué à 1.Ou KDE/Qt avec ses fichiers .ui
-
[^]Re: Vivement qu'on arrete de s'enfoncer
Posté par Erwan (page perso, ) le 09/01/2004 à 11:27. (lien). Évalué à 2.Il me semble que les fichier .ui sont destines a generer du code automatiquement, non ? C'est donc un peu different d'un fichier XML charge a la volee.
-
[^]Re: Vivement qu'on arrete de s'enfoncer
Posté par Jérôme FIX (page perso, ) le 09/01/2004 à 12:00. (lien). Évalué à 4.Ils servent au deux.
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 () le 09/01/2004 à 17:51. (lien). Évalué à 2.C'est du bon gros pipo tout ça. Il n'y a aucune raison que XUL soit plus adapté comme standard d'interfaces graphiques que Gtk (qui est déjà multi-plateformes) ou n'importe quelle autre solution.
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 Ulmo () le 12/01/2004 à 09:18. (lien). Évalué à 1.>T'as raison, c'est pas assez lourd OpenOffice. Relançons les ventes de processeurs !
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
Est ce que faire deux thèmes GTK et QT très proches (comme le font mdk ou rh) n'est pas une approche plus simple et tout aussi satisfaisante ?
-
[^]Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par MagicNinja (page perso, ) le 09/01/2004 à 10:06. (lien). Évalué à 4.D'apres les commentaires au-dessus, ce qui est attendu (pour l'utilisateur) ce n'est pas seulement le rendu graphique mais aussi une integration/reutilisation des certaines icones et certaines boites de dialogue (ouverture, enregistrement de fichiers, etc).
-
[^]Re: GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
Posté par Romain Vinot (page perso, ) le 09/01/2004 à 11:12. (lien). Évalué à 5.C'est souvent plus simple au premier coup, mais après, ça devient une course en avant. Pour chaque modification du thème original, il faut refaire tous les thèmes dérivés...
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 () le 09/01/2004 à 12:35. (lien). Évalué à 1.Beuh ... y'a des themes pourtant dans openoffice. ...
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
A quand un port de SWT (le toolkit Java d'Eclipse) vers QT ?
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 () le 12/01/2004 à 00:27. (lien). Évalué à 1.Je ne sais pas si j'etais suffisament claire dans mon article (http://www.laurentm.com/10Goto10/archives/java/000071.html(...)) a propos de Qt et SWT.
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 ???
A force de jeter des ponts entre les deux ToolKits, y'en a bien qui vont finir par sortir une fusion des deux.
-
[^]Re: La fusion, c'est pour bientôt ???
Posté par BoB () le 09/01/2004 à 12:10. (lien). Évalué à 2.Je sais pas trop quoi en penser (j'utilise des soft kde sous gnome)
- 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 () le 09/01/2004 à 12:57. (lien). Évalué à -1.Techniquement ca n'est pas possible pour deux raisons:
- 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 () le 09/01/2004 à 12:58. (lien). Évalué à 0.Ah oui, j'ai oublié aussi : gros problème de license. Il ne faut pas oublier que QT n'est libre que sur certaines plateformes !
-
[^]Re: La fusion, c'est pour bientôt ???
Posté par tanguy_k (page perso, ) le 09/01/2004 à 14:05. (lien). Évalué à 1.> GTK utilise des widgets "natifs" (win32, motif, QT maintenant)
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 () le 09/01/2004 à 14:49. (lien). Évalué à 1.>Au moins avec Qt si tu payes ca fonctionne sur toutes les plateformes.
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 (page perso, ) le 09/01/2004 à 15:15. (lien). Évalué à 0.> tu peux pas faire un truc libre sous windows avec Qt (tout du moins un truc gpl)
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 () le 09/01/2004 à 15:18. (lien). Évalué à 2.La GPL t'interdit de linker sur une lib proprio sauf si elle fait partie intégrante de l'OS. Donc tu ne peux pas faire d'appli GPL fonctionnant uniquement sous Windows (enfin tu peux l'écrire, mais tu ne dois pas avoir le droit de la distribuer ou qqchose comme ça). Dans le cas d'un truc multiplateforme, c'est effectivement discutable.
-
[^]Re: La fusion, c'est pour bientôt ???
Posté par tanguy_k (page perso, ) le 09/01/2004 à 15:27. (lien). Évalué à 0.> La GPL t'interdit de linker sur une lib proprio sauf si elle fait partie intégrante de l'OS
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 () le 09/01/2004 à 15:30. (lien). Évalué à 4.>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.
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 (page perso, ) le 09/01/2004 à 14:07. (lien). Évalué à 1.GTK utilise des widgets "natifs" (win32, motif, QT maintenant)
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 (Jabber id, page perso, ) le 09/01/2004 à 12:58. (lien). Évalué à 1.Oui, tiens, c'est pas envisageable de faire une libgtk qui ne soit qu'un wrapper vers la lib qt ? (ou l'inverse, mais l'inverse j'ai cru comprendre que c'était plus complexe) au lieu d'utiliser le moteur de thème pour arriver à ses fins.
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....
L'intégration graphique des applications non KDE dans le bureau KDE c'est bien. L'ajout des fonctionnalités KDE aux applications non KDE, c'est encore mieux.
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
"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."
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 (page perso, ) le 09/01/2004 à 12:50. (lien). Évalué à 1.> OOo n'est pas assez lourd déjà?
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 (page perso, ) le 09/01/2004 à 12:51. (lien). Évalué à 4.OOo est lourd en partie *a cause* de la couche suplémentaire qu'il a et qui de base est assez merdique (déjà pas mal améliorée dans la 1.1). En passant par de vrais toolkits (Gtk/Qt), il y a pas mal de chance que ça s'améliore grandement.
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 () le 09/01/2004 à 16:47. (lien). Évalué à 1.Le déplacement des fenêtres est assez "baveux" sous X/linux. C'est un fait et même si Windows ne fait pas mieux, l'exemple est MacOSX/Aqua.
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 () le 09/01/2004 à 19:46. (lien). Évalué à -1.Alors, moi, j'ai pas la meme chose:
- 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
-
-
Cette page a été générée par Templeet en 0.2493s (dont 0.0241 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.