Discussion: API Qt Jambi

  1. #1
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut API Qt Jambi

    Salut,

    Quelqu'un a-t-il déjà utilisé l'api QT Jambi pour java (QT c'est l'API graphique utilisée par KDE)?

    Juste pour avoir quelques retours d'expérience...

    Merci d'avance.

  2. #2
    Modérateur
    Avatar de sinok
    Profil pro
    Inscrit en
    août 2004
    Messages
    8 765
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : août 2004
    Messages : 8 765
    Points : 12 898
    Points
    12 898

    Par défaut

    C'est du stable et bien foutu (QT inside oblige).

    Ensuite je n'ai que peu joué avec QT et jamais avec Jambi, mais je ne pense pas qu'il y ait de peur à avoit, les Trolls font du très beau boulot (quand tu vois ce qui est en train de se préparer pour KDE4)...

    Bref il n'y a pas de peur à avoir.
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  3. #3
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    OK, je ne connais pas du tout au niveau de la programmation. Comparé à Swing, quels sont les avantages / inconvénient?

  4. #4
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Pas de grosse différence. Le système des événements et un peu différent et je me souviens que QT était plus chiant à customiser que Swing mais sinon... Je ne sais pas pour Jambi, mais la version C++ obligeait aussi à utiliser les classes URL, String, etc. de QT. C'était pratique en C++ mais si en Java il faut faire pareil ça peut être agaçant.
    Romain Guy
    Android - Mon livre - Mon blog

  5. #5
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Arf, j'ai trouvé ceci dans leurs exemples:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    textEdit.document().contentsChanged.connect(this, "documentWasModified()");
    Gros problème de conception (on ne fait pas de l'introspection pour ça, on utilise le pattern command)

  6. #6
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    En quoi c'est un problème de conception ? C'est chiant pour le refactoring mais à part ça... le système de slots et signaux de QT est assez sympa globalement, et moins lourd à gérer que des pelletés de listeners.
    Romain Guy
    Android - Mon livre - Mon blog

  7. #7
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Citation Envoyé par Gfx
    En quoi c'est un problème de conception ? C'est chiant pour le refactoring mais à part ça... le système de slots et signaux de QT est assez sympa globalement, et moins lourd à gérer que des pelletés de listeners.
    Bah oui, le refactoring, le non "compile-checked". Et c'est beaucoup plus lent au runtime (ça ce n'est qu'un détail).

    En Java, les pointeurs de fonctions se font par le design pattern "commande" (si c'est bien le nom "commande" si je ne me trompe pas, mais bon je sais que tu vois de quoi je parle ^^).

  8. #8
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Non, ce n'est pas beaucoup plus lent au runtime. Toutes les animations que j'écris utilisent le TimingFramework et donc la reflection et l'introspection et on obtient quelque chose d'extrêmement fluide à 60 fps sans aucun problème. Cela fait très longtemps que les performances de reflection sont excellentes.

    Et tes arguments n'expliquent pas en quoi c'est une mauvaise conception. Le compile-time checking par exemple est certes très utile, mais pour un cas comme celui-ci, en rien vital.
    Romain Guy
    Android - Mon livre - Mon blog

  9. #9
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Citation Envoyé par Gfx
    Non, ce n'est pas beaucoup plus lent au runtime. Toutes les animations que j'écris utilisent le TimingFramework et donc la reflection et l'introspection et on obtient quelque chose d'extrêmement fluide à 60 fps sans aucun problème. Cela fait très longtemps que les performances de reflection sont excellentes.
    Arf, j'avais pas envie d'écrire le test, mais bon tant pis...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    package reflex;
     
    interface MonInterface {
    	void method();
    }
     
    public class TestReflex implements MonInterface {
     
    	public void call(String method) throws Exception {
    		getClass().getMethod(method).invoke(this);
    	}
     
    	public void method() {}
     
    	public static void main(String... args) throws Exception {
    		TestReflex reflex = new TestReflex();
     
    		long t = System.nanoTime();
     
    		for(int i = 0; i < 100000; i++) {
    			reflex.call("method");
    		}
     
    		long t1 = System.nanoTime() - t;
    		System.out.println(t1);
     
    		MonInterface interf = reflex;
    		t = System.nanoTime();
     
    		for(int i = 0; i < 100000; i++) {
    			interf.method();
    		}
     
    		long t2 = System.nanoTime() - t;
    		System.out.println(t2);
     
    		System.out.println((double)t1/t2);
    	}
     
    }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    299386919
    3469155
    86.29966634526275
    Sur un simple test, l'appel par le design pattern command est 85x plus rapide que par réflexivité... Sans compter que la pour la reflexivité je ne parse pas la String pour récupérer les types des arguments etc.

    Mais bon, peu importe, la vitesse d'exécution n'était qu'un argument secondaire.

    Citation Envoyé par Gfx
    Et tes arguments n'expliquent pas en quoi c'est une mauvaise conception. Le compile-time checking par exemple est certes très utile, mais pour un cas comme celui-ci, en rien vital.
    Je ne suis pas d'accord. Si on va dans ce sens, on n'a qu'à écrire tout le code de la fonction dans une String, et on la passe en argument...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    machin.connect(this, "monTextField.setEnabled(false); System.out.println(\"bonjour\");");
    C'est pour moi une simple erreur de "mapping" direct entre C++ et Java...

    En C++ quand on fait un pointeur de fonction, on a réellement un pointeur de fonction, pas une String indiquant comment le récupérer...
    Pour faire la même chose en Java et avoir directement le pointeur, il faut utiliser une interface...

    Donc ce qui est utilisé ici est un "mapping" de syntaxe (pour que la syntaxe java ressemble à la syntaxe C++), mais en rien un "mapping" de ce qui se passe à l'exécution, ni de concepts...

  10. #10
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Oui la reflection c'est plus lent, forcément. Mais 80x plus lent ne signifie pas grand chose sans la mesure d'un appel à une interface. La seule chose importante est que même 80x plus lent, c'est assez rapide pour faire des animations complexes et fluides. Si cela ne suffit pas pour gérer un clic sur un bouton...

    En modifiant ton test on peut voir qu'invoquer une méthode par reflection prend environ 300 nanosecondes. Loin certes des 4 nanosecondes pour un appel à une méthode d'interface mais amplement suffisant. C'est typiquement une optimisation inutile dans la plupart des cas.

    Je ne suis pas d'accord. Si on va dans ce sens, on n'a qu'à écrire tout le code de la fonction dans une String, et on la passe en argument...
    Ce n'est pas ce que j'ai dit. J'ai dit que pour connecter un signal à son slot, une String n'était pas gênante. Je n'ai jamais prétendu qu'écrire le corps du handler dans la String serait une bonne idée. Ce n'est pas un argument que de modifer le mien.

    Pour moi l'équivalent du pointeur sur fonction C/C++ est justement un objet Method obtenu par reflection. Ce n'est certes pas ainsi que l'on programme en Java mais QT est une API C++ et le mécanisme des slots/signals fonctionne de cette manière. Introduire des interfaces comme en Swing aurait un impact immense sur l'API QT pour un gain qui n'est pas du tout évident DANS LE CADRE de QT.

    Note également que les slots/signaux sont bien plus flexibles que des interfaces. Grâce à eux tu peux connecter un signal generate(QRect, QImage) à une méthode addImage(QRect, QImage). Rien n'impose le nombre et le type d'arguments que tu peux utiliser.
    Romain Guy
    Android - Mon livre - Mon blog

  11. #11
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Citation Envoyé par Gfx
    Ton test est complètement foireux car tu ne mets pas en cache l'objet Method sur lequel tu fais un invoke().
    Ah, ça j'étais sûr que tu allais répondre ça (que le test était foireux)...
    C'est justement parce que je ne le mets pas en cache qu'il n'est pas foireux...

    Le but était de comparer la vitesse d'exécution de 2 bouts de codes, appelés 1 fois chacun... Pour qu'on puisse observer des différences, bien sûr l'appeler 1 seule fois ne sert à rien, on ne voit rien. Donc je l'ai appelé 100000 fois... Il faut bien sûr que les 100000 appels soit indépendants...
    Si tu introduis des optimisations en ne faisant un des traitement qu'une seule fois pour les 100000 appels, là ton test est foireux

    EDIT: tu viens de modifier ton post...
    Citation Envoyé par Gfx
    Par défaut
    Oui la reflection c'est plus lent, forcément. Mais 80x plus lent ne signifie pas grand chose sans la mesure d'un appel à une interface. La seule chose importante est que même 80x plus lent, c'est assez rapide pour faire des animations complexes et fluides. Si cela ne suffit pas pour gérer un clic sur un bouton...

    En modifiant ton test on peut voir qu'invoquer une méthode par reflection prend environ 300 nanosecondes. Loin certes des 4 nanosecondes pour un appel à une méthode d'interface mais amplement suffisant. C'est typiquement une optimisation inutile dans la plupart des cas.
    On accepte de perdre du temps (aussi important soit-il) sur l'appel d'une méthode lorsque cela apporte un avantage par ailleurs. Ici je ne vois que des inconvénients... Le seul avantage que l'on peut voir est d'avoir une syntaxe proche de celle de C++... Moi personnellement ça ne me suffit pas...
    FIN EDIT

    Citation Envoyé par Gfx
    Pour moi l'équivalent du pointeur sur fonction C/C++ est justement un objet Method obtenu par reflection.
    C'est par ce que tu te limites à la syntaxe... Car c'est bien différent...

    Citation Envoyé par Gfx
    Ce n'est certes pas ainsi que l'on programme en Java mais QT est une API C++ et le mécanisme des slots/signals fonctionne de cette manière. Introduire des interfaces comme en Swing aurait un impact immense sur l'API QT pour un gain qui n'est pas du tout évident DANS LE CADRE de QT.
    C'est ce que je dis... c'est simplement pour syntaxiquement faire "comme C++".

    Citation Envoyé par Gfx
    Note également que les slots/signaux sont bien plus flexibles que des interfaces. Grâce à eux tu peux connecter un signal generate(QRect, QImage) à une méthode addImage(QRect, QImage). Rien n'impose le nombre et le type d'arguments que tu peux utiliser.
    Évidemment, tout ce qui n'est pas vérifié est plus flexible... Mais n'est-ce pas là la force des langages "fortement" typés (où le fortement reste à définir) de ne pas être flexible là où il ne faut pas l'être?

  12. #12
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Le but était de comparer la vitesse d'exécution de 2 bouts de codes, appelés 1 fois chacun... Pour qu'on puisse observer des différences, bien sûr l'appeler 1 seule fois ne sert à rien, on ne voit rien. Donc je l'ai appelé 100000 fois... Il faut bien sûr que les 100000 appels soit indépendants...
    Si tu introduis des optimisations en ne faisant un des traitement qu'une seule fois pour les 100000 appels, là ton test est foireux
    Ah non ! Tu compares l'invocation d'une méthode d'une interface à l'introspection d'une méthode PLUS son invocation. Tu fais DEUX choses. Pour être totalement partial ton code devrait être le suivant :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    private Method m;
     
    public void init(String method) throws Exception {
        m = getClass().getMethod(method);
    }
     
    public void call() {
        m.invoke(this);
    }
    Là on teste bien le coût de l'invocation. Pas de la recherche ET de l'invocation.

    C'est par ce que tu te limites à la syntaxe... Car c'est bien différent...
    Bien sûr que c'est différent, mais c'est la fonctionnalité qui en est la plus proche en Java.

    Mais n'est-ce pas là la force des langages "fortement" typés (où le fortement reste à définir) de ne pas être flexible là où il ne faut pas l'être?
    Ça, c'est un vieux débat... va donc en parler aux admirateurs de Ruby ) Plus sérieusement, c'est une fonctionnalité, pas une force. Pas dans tous les cas. Cela dépend de tes besoins. Pour une simple gestion d'événements il est loin d'être évident que cette contrainte soit un véritable bénéfice. (Et tu veux sans doute parler de typage statique plutôt que de typage fort dans ce cas.)
    Romain Guy
    Android - Mon livre - Mon blog

  13. #13
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Citation Envoyé par Gfx
    Ah non ! Tu compares l'invocation d'une méthode d'une interface à l'introspection d'une méthode PLUS son invocation. Tu fais DEUX choses.
    Tout à fait. En fait je voulais comparer "l'ajout" (par la méthode connect) + "l'appel" lors d'un évènement.
    Mais pour cela il faut mettre le interf = reflex dans la boucle également (qui correspond au passage de paramètre de l'objet).

    Ce qui donne:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    305388379
    3660380
    83.43078560149493
    83 fois plus rapide...

    Mais bon après tu peux comparer séparément l'ajout et l'appel, tu obtiendras sans doute pour l'ajout un résultat bien plus rapide pour le design pattern Command (simple affectation) pour le passage de paramètre, et un peu moins rapide (que 80x plus rapide) pour l'invocation...

    Mais bon, on ne va pas continuer les benchmark, ni savoir si gagner 80x en rapidité est important, la vitesse n'était pas un argument essentiel... le reste est d'après moi plus grave encore ;-)

  14. #14
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Tout à fait. En fait je voulais comparer "l'ajout" (par la méthode connect) + "l'appel" lors d'un évènement.
    Mais pour cela il faut mettre le interf = reflex dans la boucle également (qui correspond au passage de paramètre de l'objet).
    Mais QT ne va pas faire la recherche de la méthode à chaque fois qu'un événement est généré, seulement lors du connect(). C'est cela qui rend ton test complètement caduc. Et puis je n'avais même pas vu, mais tu fausses encore plus le test en passant d'abord dans la méthode call(). Tu ajoutes donc à l'invocation de Method le coût d'appel à call() (même si selon la JVM ce code pourra être inliné ou pas). Bref.

    ... le reste est d'après moi plus grave encore ;-)
    Tu n'as toujours pas d'exemple concret qui montrerait en quoi cette API est dangereuse/mal conçue/ce que tu veux.

    Essaye d'utiliser QT sans vouloir le faire à la sauce Swing et tu découvriras une excellente API.
    Romain Guy
    Android - Mon livre - Mon blog

  15. #15
    Membre expert
    Avatar de ®om
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    2 815
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 2 815
    Points : 3 167
    Points
    3 167

    Par défaut

    Citation Envoyé par Gfx
    Tu n'as toujours pas d'exemple concret qui montrerait en quoi cette API est dangereuse/mal conçue/ce que tu veux.
    Au niveau "pratique" déjà, le refactoring, qu'on peut quasiment totalement oublier si on développe un programme en utilisant QT Jambi. Au niveau temps de développement, je pense que les erreurs de runtime demandent un plus long débuggage que les erreurs de compilation.
    (et un problème qui n'est pas lié à la reflexivité, mais c'est dommage de ne pouvoir ajouter qu'un seul listener -si c'est le cas, je n'ai pas fouillé l'api-)

    Essaye d'utiliser QT sans vouloir le faire à la sauce Swing et tu découvriras une excellente API.
    Je pense qu'en C++ c'est très bien, en Java j'ai des doutes au vu des exemples...

    Mais tu as raison, je n'ai pas testé (encore?).
    En tout cas j'aime bien le rendu sur certains screenshots (peut-être parce que c'est le même que sur mon bureau, qui est en KDE).

  16. #16
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 176
    Points
    8 176

    Par défaut

    Disons que QT est très intéressant en C++ pour ses classes "annexes" comme les strings, etc. Il y a quelques années le rendu sous Windows était encore trop différent des applications natives mais les dernières versions sont excellentes. Leur API de dessin est également super sympa.

    Pour les erreurs de compilation... certes. Mais tu fais si souvent des fautes de frappe dans le nom des méthodes pour que cela soit un vrai gain **dans ce cas très particulier et très limité** ? D'autant plus qu'il y a la completion pour ça (et oui même dans une String).
    Romain Guy
    Android - Mon livre - Mon blog

  17. #17
    Membre habitué
    Homme Profil pro
    SAQ
    Inscrit en
    novembre 2005
    Messages
    167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : SAQ
    Secteur : Service public

    Informations forums :
    Inscription : novembre 2005
    Messages : 167
    Points : 194
    Points
    194

    Par défaut

    Hello!
    Ouais, j'ai été très surpris de voir qu'il existait une version JAVA de QT
    ça me semble bien jusqu'à date
    Mais c'est vrai que si on nous force a utiliser les types de base à la sauce QT, c'est moins sympa oui comme disait.. je sais plus qui tout à coup
    Si derrière tout homme il y a une femme, devant ce même homme il y a l'ordinateur que cette femme a bousillé
    ---------

    Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. (Dick Brandon)

Discussions similaires

  1. Documentation gratuite sur l'API Windows, COM, DCOM, OLE, etc.
    Par Community Management dans le forum Windows
    Réponses: 1
    Dernier message: 16/11/2006, 15h28
  2. JEG : jAPI : Une API pour C++Builder
    Par JEG dans le forum C++Builder
    Réponses: 4
    Dernier message: 15/11/2003, 13h50
  3. FOnction api specifiant la position de la souris
    Par florent dans le forum C++Builder
    Réponses: 4
    Dernier message: 15/05/2002, 20h07
  4. faire un selection dans une image aves les APIs
    Par merahyazid dans le forum C++Builder
    Réponses: 3
    Dernier message: 30/04/2002, 10h44
  5. Une petite aide pour les API ?
    Par Yop dans le forum Windows
    Réponses: 2
    Dernier message: 04/04/2002, 21h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo