Journal QML: le futur des interfaces graphiques

Posté par (page perso) .
32
13
mai
2010
Vous connaissez sans doute Qt ? Mais si... cette bibliothèque libre en C++ qui permet de faire des applications graphiques, utilisé par KDE. Vous aurez remarqué que les interfaces "classique" sont encore faites avec des widgets rectangulaires sans aucune imagination. Ce sont des interface des années 90-00.

Avec la future version de Qt (4.7), vient un nouveau langage permettant de faire des interface graphiques digne des années 10: QML

L'idée c'est de pouvoir faire des interfaces graphiques animées et de manière déclarative très facilement. Suffisamment facilement que pour que un designer, qui n'a aucune idée de la programmation puisse réaliser de super interface qui en mettent plein la vue.

On peux voir quelques vidéos d'interface en QML sur youtube (beurk youtube!)
http://www.youtube.com/watch?v=xoo_Ows1ExU http://www.youtube.com/watch?v=WQkXdzMyGns
(ou recherchez Qt QML sur youtube)

QML veux dire originalement Qt Markup Language. Car au début c'était du XML. Mais XML c'était le buzz des années 00, et maintenant c'est dépassé. Les développeurs ont vu que XML c'est moche et pas pratique, alors ils ont inventé une super syntaxe innovatrice.
En gros, la syntaxe ressemble à du CSS, avec du Javascript dedans.

Le principe consiste a déclarer des éléments et à leur donner des propriétés. Il est aussi possible de déclarer des états, et des transitions entre ces différents états. Ce qui rends les interfaces dynamique. Il est possible de rajouter la logique grâce a du javascript. Et quand on arrive aux limite de ce que le
javascript peut faire, le reste de la logique peut être écrite en C++.

Exemple basique : http://doc.qt.nokia.com/4.7-snapshot/qml-tutorial3.html
Doc: http://doc.qt.nokia.com/4.7-snapshot/declarativeui.html

Le tout est pour le moment vraiment orienté pour l'embarqué (Nokia oblige). Et est conçu pour être super rapide.

Dans le milieux professionnel, les interfaces graphiques sont souvent désignées par des designers, sans compétences en programmation. Ils utilisent des technologie comme Flash pour faire des mockups qui sont alors fourni au programmeur qui doit refaire tout le travail pour implémenter le tout. Et souvent ce que le designer a produit n'est pas réellement possible en pratique ou est trop lent. Avec QML, le designer travail directement sur le résultat final de l'interface et voit directement ce qui est possible ou pas.

Qt QUICK (pour Qt User Interface Creation Kit) et le nom de code de l'intégration dans l'IDE Qt_Creator, qui, fourni un éditeur pour créé des interface à partir de la version 2.0.

Le tout est pour le moment disponible en version Beta:
http://qt.nokia.com/developer/qt-qtcreator-prerelease
http://labs.trolltech.com/blogs/2010/05/06/qt-470-beta1/

Vous pouvez donc essayer, et reporter des bugs. Ou tout simplement troller dans les commentaires.


[1] http://blog.qt.nokia.com/2010/03/25/developers-are-from-mars(...)
  • # Une vraie question

    Posté par . Évalué à  8 .

    [...]pouvoir faire des interfaces graphiques animées [...] suffisamment facilement que pour que un designer, qui n'a aucune idée de la programmation puisse réaliser de super interface qui en mettent plein la vue.

    Ce n'est pas pour troller mais... quelle est la différence entre l'exemple basique indiqué, et du "vrai" code ? Il y a autant de choses à apprendre, il y a autant de lignes à écrire.

    Au final, celui capable de pondre le même exemple est capable de coder. Et je ne pense pas qu'il puisse en être autrement, sinon on aurait déjà trouvé :-)
    • [^] # Re: Une vraie question

      Posté par (page perso) . Évalué à  8 .

      Le code est plus déclaratif. Il n'y a pas besoin de de s'y connaitre en algorithmes, pas besoin de penser a la gestion de la mémoire, ...
      On décrit juste ce que l'on veux.
      C'est un peu comme du HTML, ce n'est pas de la programmation.

      De plus, l'objectif est de pouvoir éditer ces documents avec un outils graphique (voir le screenshot de http://labs.trolltech.com/blogs/2010/05/06/qt-creator-and-be(...) )
      • [^] # Re: Une vraie question

        Posté par (page perso) . Évalué à  10 .

        Et c'est bien connu, les designer ils pondent souvent du html génial !
        • [^] # Re: Une vraie question

          Posté par . Évalué à  3 .

          Comparaison n'est pas raison.

          Pour avoir bidouiller un peu le truc, je trouve que le code généré par Quick est plutôt propre. Et puis par expérience, le Designer de Qt (celui qui fait des interfaces des années 90-00) génère du beau code (comprendre du code lisible par un Homo Sapiens). Que ce soit du C++ ou du XML.

          Personnellement, je ne pense pas utiliser QML prochainement, mais je trouve que la façon "flashesque" de faire des interfaces qui en jêtent sans pourrir le code C++ derrière, ça peut être un plus dans certains cas d'utilisation. Et quand on regarde l'interface des smartphones aujourd'hui, je vois tout de suite au moins un de ces cas.
      • [^] # Re: Une vraie question

        Posté par . Évalué à  3 .

        pas besoin de de s'y connaitre en algorithmes, pas besoin de penser a la gestion de la mémoire
        Une API correctement faite permet d'écrire exactement la même chose que l'exemple donné. Donc sans s'occuper d'algo, ni de mémoire, ni de pointeurs, etc. C'est probablement moins lisible pour des choses complexes, encore que.


        En fait, là où je me pose vraiment la question, c'est qu'avec un "vrai" programme, on n'est pas limité. Alors qu'avec ce genre de langage, il n'est pas possible de sortir des limites pré-imposées. Si je souhaite faire quelque chose non prévue au départ... ben je ne peux pas. Alors qu'avec un programme, libre à moi d'apprendre à aller un peu plus loin.


        Ceci dit, ça a l'air rudement pratique !
        • [^] # Re: Une vraie question

          Posté par (page perso) . Évalué à  8 .

          Justement, quand on touche les limites du langage, on continue en C++ (Avec Qt, qui - corrige moi si j'ai tord - est « une API correctement faite »).

          Et c'est là la force par rapport des technologies comme Flash, où dès que l'on atteint les limites de ce que l'actionscript peut faire, on est bloqué.
          • [^] # Re: Une vraie question

            Posté par . Évalué à  -5 .

            Justement, quand on touche les limites du langage, on continue en C++

            Pourquoi ne pas tout faire en Python plutôt ?
            • [^] # Re: Une vraie question

              Posté par (page perso) . Évalué à  10 .

              Parce que Qt est une librairie C++.

              Puis le C++, c'est vraiment beaucoup mieux que le python.

              Envoyé depuis mon lapin.

              • [^] # Re: Une vraie question

                Posté par . Évalué à  3 .

                Puis le C++, c'est vraiment beaucoup mieux que le python.

                Ouhaou le troll mais en fait non c'est trop gros ca peut pas passer.
                • [^] # Re: Une vraie question

                  Posté par (page perso) . Évalué à  5 .

                  Bon, j'ai rien de mieux à faire, même si il fait beau. En plus, je viens de me mettre au python pour des raisons professionnelles, donc je peux parler à partir de ce que je connais, et pas de ce que j'ai lu (même si je n'ai pas encore énormément d'expérience avec le python). Certains reproches sont aussi des avantages du python, mais j'ai le droit de ne pas aimer.

                  Voici donc pourquoi je trouve le C++ beaucoup mieux que le python:

                  * Le python n'est pas un langage compilé, j'aime bien les langages compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une concaténation entre un string et un nombre).
                  * Le python ne permet pas de gérer manuellement la mémoire. Le ramasse miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire en C++.
                  * Pas de typage explicite des variables. C'est super pénible de ne pas savoir quelle est le type de la variable que l'on a à gérer.
                  * Le self comme argument dans les méthodes de classes, c'est vraiment très très moche comme hack, et les messages d'erreurs sont faussés (quand il manque des arguments, le nombre d'arguments comprend le self, alors que l'on ne doit pas le préciser avec la syntaxe classique).
                  * On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de faire une copie.
                  * Les exceptions pour les jeux de caractères, ça me gonfle.
                  * L'impression générale d'être limité à une utilisation en haut niveau.
                  * Puis l'indentation obligatoire, c'est super pénible. Surtout quand on reprends le code d'une autre personne, ou que l'on a juste commenté une condition.

                  Par contre, j'aime bien la facilité de la création de modules, les arguments nommés, toutes les librairies inclues de base (piles fournies©), et le cotés dynamique assez sympathique.

                  Envoyé depuis mon lapin.

                  • [^] # Re: Une vraie question

                    Posté par (page perso) . Évalué à  5 .

                    > j'aime bien les langages compilés [...] on a pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une concaténation entre un string et un nombre).

                    Tu confonds compilation et typage statique. L'un n'implique pas l'autre.
                    • [^] # Re: Une vraie question

                      Posté par (page perso) . Évalué à  2 .

                      Effectivement, mon exemple est plus au niveau du typage statique réalisé lors de la compilation.

                      Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation automatique du code (en python, on perd la documentation quand on veut optimiser). Gcc va vraiment plus optimiser, et même en fonction de l'architecture de la machine.

                      Avec un langage interprété, effectuer les mêmes optimisations serait possible, mais ce serait aussi bien trop lent à exécuter.

                      Envoyé depuis mon lapin.

                  • [^] # Re: Une vraie question

                    Posté par (page perso) . Évalué à  7 .

                    Allez, hop, j'arrive après la guerre et je répond, parce que je suis un vil
                    pythoneux qui ne supporte pas que l'on dise du mal du meilleur langage du
                    monde (Lisez tout de même la suite avant de moincer, j'ai essayé de mettre des
                    arguments)

                    * Le python n'est pas un langage compilé, j'aime bien les langages
                    compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a
                    pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une
                    concaténation entre un string et un nombre).


                    Pour les minis pauses, je suis tellement d'accord. Sauf qu'ici au boulot c'est
                    des pauses de 30 minutes chaque fois que l'on change un commentaire dans le
                    fichier .h qui contient le template de base du système...

                    Sinon, pour le coté erreurs en pleins milieu, les autres l'on déjà dis, tu
                    confond la compilation et le tapage statique. Java est aussi un langage
                    interprété et pourtant tu as des erreurs au milieu du programme.

                    Mais en pratique en C++ tu as aussi des erreurs en milieu du programme que la
                    *compilation* ne réglera jamais. Par contre l'interpréteur peut être plus
                    malin que ton CPU en te renvoyant une erreur plus précise (genre unbound acces
                    en lieu et place de segfault). Mais j'avoue qu'avec une utilisation correcte
                    de la STL, tu n'as plus de segfault (enfin presque). Mais cette utilisation
                    correcte de la STL revient à rendre C++ aussi lent (enfin presque) que
                    Python...


                    * Le python ne permet pas de gérer manuellement la mémoire. Le ramasse
                    miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture
                    du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire
                    en C++.


                    Chacun ses goûts. Je suis en grande partie d'accord avec toi quand je fais de
                    la programmation qui se doit d'être *vraiment* (cf plus loin) le plus rapide
                    possible.

                    Mais dans 99.9% des cas (chiffre au pif), quel est le besoin de gérer
                    l'allocation mémoire ? Tout le monde ici programme des fusées (Et encore, je
                    ne métrais pas de C++ dans les fusées), Tout le monde ici fait de la synthèse
                    d'image temps réel ? (Et encore, on peut en faire en python). Bon, donc sauf
                    si j'ai raté la dernière révolution, la plupart des code développés n'ont PAS
                    besoin de performances dingues, et n'ont PAS besoin de gestion fine de la
                    mémoire. Dans le cas particulier de l'article que l'on commente, l'on parle de
                    conception d'interfaces graphiques. Ici, 99.9% (chiffre au pif, certainement
                    surévalué) du temps CPU se passe dans le code du toolkit graphique et celui-ci
                    doit certainement faire une bonne partie des allocations mémoires (voirs peut
                    être 99.9% de celles-ci). Je connais mal Qt mais du peu que j'en ai fais en
                    C++, je ne me rappel pas avoir passé la moitié de la journée à faire des
                    malloc.

                    Et puis, tu dis aimer gérer toi même la mémoire, mais combien de personnes
                    utilisent une malloc alternative, combien de personnes surchargent le
                    paramètre alloc des templates de la STL ? Combien de personnes surchargent
                    l'opérateur new de la STL ? Si tu ne fais pas cela, alors tu ne peux pas
                    prétendre aimer gérer la mémoire.

                    De son coté, le GC de python, son job est de faire un malloc (si nécessaire)
                    quand tu crée un objet et nettoyer la mémoire (si il juge cela pertinent)
                    quand tu n'as plus besoin de cet objet. Alors oui, l'on ne maîtrise rien, mais
                    maitrise-t-on moins qu'avant ? Que faut-t-il craindre du GC de python ? Il
                    fait un travail fastidieux à notre place, en faisant moins d'erreur et
                    potentiellement plus rapide (du fait du pool de mémoire qui est réutilisé). Il
                    faut juste savoir l'utiliser correctement (ne rien faire) et si l'on veut une
                    utilisation avancé, il est aussi possible de l'utiliser de façon avancé (en
                    désactivant le GC de recherche de références cyclique et en ne laissant que le
                    compteur de référence qui ne consomme virtuellement rien)


                    * Pas de typage explicite des variables. C'est super pénible de ne pas savoir
                    quelle est le type de la variable que l'on a à gérer.


                    Goût et couleurs... Personnellement je ne m'intéresse pas à la variable ni à
                    son type, mais à ses capacités. Note que rien ne t'empêches en python de faire
                    du typage static.

                    Tu peux par exemple "décorer" tes arguments de fonctions:

                    def tortue(a:int, b:float)->float

                    Ensuite libre à qui veut de faire ce qu'il veut avec cela (je m'en sert pour
                    documenter les valeurs). Mais avec cela, tu n'as aucun problème pour faire de
                    la vérification de type au run-time, ou, un peu plus dur, écrire un
                    vérificateur de type statique. J'avoue, dans certains cas cela sera un peu
                    sioux ;)

                    Mais le problème ici, c'est que l'on s'en fout car l'on vois les types
                    de façon différente, plus comme une interface implicite :

                    Prenons un exemple. Tu est le gérant d'un bar. Un blanc entre dans le bar, tu
                    as prévu d'ouvrir le bar aux blancs, donc tu lui verses sa bière.
                    Un black (Il faut dire black pour être non raciste aujourd'hui) entre dans le
                    bar. Tu avais prévu que les blancs, mince. Comme t'es pas raciste, tu changes
                    ta porte d'entrée pour laisser passer les "buveurs", et tu demandes à tes
                    clients de se faire référencer comme buveur. Tu peux donc tout Homme se
                    présentant comme un buveur.

                    Un alien entre dans ton bar, et te demande à boire. Il n'a pas l'interface
                    buveur (son vaisseau vient de s'écraser devant ton bar, personne sur terre ne
                    connais l'existence de cette race d'arien, donc personne n'a pensé à le
                    rajouter dans le fichier des espèces qui boivent... Mais il a soif et te
                    montre de façon insistance avec sa tentacule la bouteille de bière. Pas
                    d'interface buveur, il ne bois pas. C'est ainsi que commencera la première
                    guerre universel (A lire, universal war one, très bonne BD sur ce sujet, enfin
                    presque).

                    Alors oui, on pourrait dire que c'est préférable de l'empêcher de boire si
                    l'on ne sait pas si il peut boire (imagine, il se trompe et cela le tue...).
                    C'est deux façon de voir les choses et je préfère rendre responsable les
                    développeurs que de rendre responsable le code. Le résultat étant le même à la
                    fin, soit c'est bon et cela passe, soit cela te pète à la gueule (au runtime
                    ou à la vérification statique). D'un coté tu t'es embêté à écrire du code
                    complexe, de l'autre t'as mis en place une procédure pour que cela pète au
                    runtime chez toi et pas chez le client (des tests par exemple). Comprendra qui
                    veut (Personnellement je préfère ne pas m'embêter en codant et écrire des
                    tests, parce que les tests, j'aurais honte de fournir du code au client qui
                    n'est pas testé... Donc entre écrire des tests et m'embêter en codant, ou juste
                    écrire des tests (et en plus sans m'embêter à les écrire...), le choix est
                    vite fait)

                    Le problème ici c'est que python ne manque pas d'une fonctionnalité de typage,
                    c'est juste une façon différente de voir les choses.


                    * Le self comme argument dans les méthodes de classes, c'est vraiment très
                    très moche comme hack, et les messages d'erreurs sont faussés (quand il
                    manque des arguments, le nombre d'arguments comprend le self, alors que l'on
                    ne doit pas le préciser avec la syntaxe classique).


                    Problème de goût et erreur de compréhension. Personnellement je trouve que le
                    this implicite en C++ c'est très moche comme hack (mon dieu, il vient d'où ?).

                    Après pour l'histoire du self, il n'y a pas de message d'erreur faussés, juste
                    une habitude que tu as pris d'ignorer dans le compte des arguments l'instance
                    concerné

                    toto.doit(5)

                    pour moi c'est une fonction (C.doit) qui prend deux arguments, toto et 5. C
                    sera dynamiquement déduit du type de toto (en l'occurrence, toto.doit(5) est
                    juste un raccourci syntaxique pour:

                    toto.__class__.doit(toto, 5)

                    avec toto.__class__ = C

                    Et là ou le système de type est intéressant, c'est que la classe C est finalement
                    juste un gros namespace de fonction travaillant sur des objets equivalents,
                    mais rien ne t'empeches de faire:

                    titi = B() # b n'a RIEN a voir avec C dans l'arbre d'héritage

                    C.doit(titi, 5)

                    En C++, on appelle cela les templates... En python on appelle cela le
                    dynamisme, mais en pratique les deux langages font la même chose...

                    Personnellement, je n'ai jamais compris pourquoi les autres langage ne
                    faisaient pas comme cela (pour le self/this). Et même avant que je connaisse
                    python, je ne comprenais pas. Quand j'ai découvert python, j'ai bondi de joie
                    au plafond en hurlant "Mon dieu, enfin des gens logiques qui pensent comme
                    moi"... Donc loin d'un hack immonde, c'est encore une fois un problème de
                    façon de voir les choses (même si le hack immonde, il faut être fou pour ne
                    pas se rendre compte qu'il est dans le langage C++ ;)

                    D'ailleurs, on va pousser un peu. Supposons une classe A et une
                    classe fille B ayant tout les deux une méthode "blork", Dans B.blork tu veux
                    appeler le A.blork sur l'instance courante...

                    En java tu utiliseras "inherited", bon, ok, java n'as pas d'héritage multiple
                    (en bien ou en mal), donc cela fonctionne très bien (je trouve cela juste
                    dommage d'introduire un nouveau mot clé dans le langage pour cela...)

                    En C++, tu utilises l'opérateur de portée de classe:

                    void B::blork()
                    {
                    A::blork();
                    }

                    Donc ici de façon implicite, A::blork est appelée avec le contexte. Mais si tu
                    utilises A::blork() en dehors de la classe B, et bien cela risque de ne pas
                    fonctionner non ?

                    En python tu verras simplement A.blork(self) que tu sois DANS l'instance le
                    code de la classe B ou en dehors (sauf que en dehors tu n'écrira pas de
                    variable nommée self ;)

                    Autre exemple. Tu écris une fonction qui travaille sur un objet de classe A,
                    et qui fait un truc

                    def mafonction(something):
                    assert(is_instance(something, A))
                    #dosomething with something

                    Note qu'ici je vérifie le type, pour le sport.

                    Puis après, tu obtient le pouvoir d'intégrer ta fonction au sein de la classe
                    A. Et bien tu n'as rien à changé, le prototype reste le même (faut renommer
                    self en something partout pour que cela soit joli, mais sinon c'est la même
                    chose).

                    Je ne parle pas de simplicité pour le refactoring ou autre hein (en C++ c'est
                    presque aussi simple en C++), je parle de cohérence. En C++ ce n'est pas du
                    tout la même chose, en python c'est toujours une fonction, il n'y à rien de
                    changé. En c++ il y a des namespaces, des classe, des fonctions, des méthodes
                    statiques, des méthodes d'instance. En python l'on fait la même chose
                    simplement avec des namespaces et des méthodes.



                    * On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de
                    * faire une copie.


                    C'est un choix qui semble logique de mon coté. Une chaîne de caractère tient
                    sa valeur de son contenu, tu changes le contenu, tu changes la chaîne. Mais
                    sincèrement, on s'en cogne pas un peu ? Je crois que je n'ai jamais changé
                    un caractère dans une chaîne... A la limite plusieurs, mais cela change
                    complètement l'algo derrière, et j'avoue être plutôt heureux que python me
                    l'interdise ;)

                    Et si vraiment tu n'est pas content, libre à toi d'écrire un type
                    mutablestring basé sur les listes voir même sur les chaînes. Cela prend 5
                    minutes. Mais je n'en vois pas l'intérêt.


                    Les exceptions pour les jeux de caractères, ça me gonfle.


                    Précise ta remarque ? Les exceptions que j'ai eu en python étaient toutes liés
                    à une erreur de ma part. Une fois que tu as compris qu'il faut toujours
                    travailler en unicode (ou str dans python3), sauf pour les entrées sorties ou
                    tu converties en str (ou bytes dans python3) ou les traitements qui n'ont pas
                    de valeur de chaîne de caractère, il n'y a plus de problème.

                    On parlait tout a l'heure de vérification à la compilation, du fait que le
                    typage apportait un lot de sécurité, bla bla bla... Et bien ici python
                    t'apporte le fait que si tu fais des bêtises avec ta chaîne de caractère, il
                    te hurle dessus pour éviter que tu ne vois pas que la sortie est remplie de
                    petits '?', certes très jolis. Python est ici plus sécurisé que le C++, sans
                    être embêtant...

                    De toute façon ici l'on ne peut pas comparer avec C++, la lib standard C++ ne
                    gère pas l'un code, donc de toute façon tu n'aurais jamais eu ses erreurs en
                    C++, mais ce n'est pas forcement pour une bonne raison. C++ 0x apportera un
                    vrai support des chaînes de caractère, donc rassurez vous, cet argument en
                    faveur de python ne sera plus dans quelques années, à en juger par
                    l'implémentation du C99 sur les grands compilateurs du marché, au moins 10 ans ;)


                    L'impression générale d'être limité à une utilisation en haut niveau.


                    Précise ? Oui tu ne feras jamais un OS en python (et encore, cela pourrait
                    être marrant), mais quelles sont tes contraintes bas niveau ?

                    Personnellement je fais de l'OpenGL/Cuda/OpenCL tous les jours avec, et je
                    trouve que c'est suffisamment bas niveau...

                    Maintenant oui, j'accepte cet assertion, cependant revenons au débat sur Qt,
                    personnellement je m'en fout de toucher mes registres à la main, de faire du
                    (S/M)IMD, de gérer ma gestion de lignes de cache du CPU, de savoir comment mes
                    pages mémoires sont swapées. ON fait de la GUI là... On est en 2010, combien
                    de personnes, à part les gens qui font du système ou de l'image ont besoin
                    d'autant de bas niveau ?

                    Alors oui, quand j'ai besoin de bas niveau (mon dieu, il y a quoi dans mon
                    cache L2 !!!) Je fais du C (et du C++ quand vraiment je fais un gros truc et
                    que j'ai besoin d'une syntaxe objet plus légère que celles possibles en C),
                    mais quand je fais une gui, avec C++ j'ai "l'impression générale d'être limité
                    à une utilisation de bas niveau".


                    Puis l'indentation obligatoire, c'est super pénible. Surtout quand on
                    * reprends le code d'une autre personne, ou que l'on a juste commenté une
                    * condition.


                    C'est personnel. Moi je ne supporte plus les accolades et points virgules et
                    bien que j'ai plus d'années d'expériences en C/C++ que python, n'oublies
                    encore pleins de ;, mais je n'oublies jamais d'intenter mon code...

                    Quand j'enseigne la programmation à la fac ou en école d'ingé Je passe les 3/4
                    de mes séances C/C++/Pascal à rajouter des {};begin/end... J'ai la chance
                    d'avoir quelques groupes d'enseignement en Python, et bien je n'ai jamais* eu
                    de problème avec l'indentation et la syntaxe du langage.

                    * Une fois un élève qui à changé la configuration de son éditeur de texte pour
                    l'indentation et qui est passé soudain de 4 espaces à un tab... Un beau
                    bordel, j'avoue. Mais une fois ce détail connu pour une utilisateur averti,
                    il suffit d'un peu de rigueur (et d'un éditeur bien configuré) et ce problème
                    devient un souvenir.

                    Pour les commentaires de conditions, j'avoue, c'est peu pratique (enfin en C
                    tu est aussi forcé de supprimé les accolades ouvrantes et fermantes, sauf si
                    tu acceptes la déclaration d'un nouveau bloc, ce qui, j'avoue, à peu
                    d'implications, sauf si il reste encore le else après et là t'es eu...
                    Personnellement, j'ai une macro $EDITOR pour chercher le if le plus proche, et
                    cycler entre:

                    if condition:

                    #TODO if condition:
                    if True:

                    #TODO if condition:
                    if False:

                    Et elle est adaptée d'une macro pour le C que j'avais avant qui faisait la
                    même chose, car je n'ai pas trouvé mieux (je suis preneur).


                    Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation
                    automatique du code (en python, on perd la documentation quand on veut
                    optimiser). Gcc va vraiment plus optimiser, et même en fonction de
                    l'architecture de la machine.
                    Avec un langage interprété, effectuer les mêmes optimisations serait possible,
                    mais ce serait aussi bien trop lent à exécuter.


                    La suppression de documentation n'optimise pas plus, elle réduit seulement la
                    taille du fichier. Tu as deux flag en python, -O et -OO pour optimiser. -O ne
                    fait pas grand chose (principalement, il supprime les assert et la variable
                    __debug__) et -OO supprime la documentation. Si tu veux optimiser, python
                    n'est vraiment pas la bonne solution.

                    Et là je vais revenir sur le débat de la mémoire. ON s'en COGNE des
                    optimisations. On fait de la GUI ici hein, de la GUI ! Le truc pour lequel le
                    toolkit bouffe 99.9% de ton temps CPU pour dessiner des fenêtres à l'écran. Le
                    truc ou l'élément limitant en terme de performances et de réactivité c'est
                    l'utilisateur, la carte graphique, le serveur d'affichage et le toolkit.

                    Et puis pour la plupart on fait de la GUI qui affiche les
                    résultats qui sortent d'une BDD, le truc qui va prendre un temps de fou pour
                    revenir, parce que une BDD c'est des milliers de cycle CPU pour ramener une
                    petite donnée, c'est comme cela. Et on fait de la gui qui va lire et charger
                    des fichiers Image, qui va prendre quelques milliers de cycle CPU pour
                    décompresser le jpeg. Tout cela est déjà écrit et est lent, et sera toujours
                    plus lent que 10 appels de fonction dans python pour connecter ton évènement
                    clique de bouton sur la fonction de décompression de JPEG.

                    Alors oui, python prendra quelques cycles CPU de plus que C++ dans la boucle
                    principale, cycles qui sont négligeables à cote de ceux nécessaire au toolkit
                    pour afficher ta fenêtre. Alors OUI, je ne ferais jamais un toolkit en python,
                    ou une librairie de décompression JPEG, (et encore... faut voir ;)), mais
                    quand l'on parle d'utilisation de librairies qui existent déjà.

                    Et puis l'on parle d'optimisation et de C++, j'en rigole tous les jours. Du
                    fait des mécanismes d'héritage virtuel, les appels de fonction en C++ sont
                    lents et ne peuvent être inlinés (on parlait d'optimisation par le compilateur
                    ?).

                    Alors OUI, python n'est pas parfait, Oui il a des défauts, le plus gros étant
                    qu'il ne code pas à ma place, ainsi je suis obligé d'aller au boulot et de
                    coder (parce que sinon je coderais à la maison pour le plaisir, ou je ferais
                    de l'escalade, ou je jouerais à Ryzom). Je vous demande juste une chose, ne
                    pas critiquer python sur des goûts personnels (l'indentation, le self, ...) ou
                    sur des fausses idées (python est lent. Oui, mais lent à quel point ?), mais
                    faites le sur des vrais points techniques, je peux en citer pleins :

                    - Python sucks en multithreadé à cause du GIL (cela se discute, mais globalement c'est vrai
                    pour les calculs cpu-bound)

                    - Déployer une application écrite en python c'est plus chiant qu'un bon gros
                    binaire Qt linké en statique. Sous windows un bon gros binaire Qt linké en
                    statique marche tout seul, alors que la même application en pytoolkit doit
                    contenir plusieurs fichiers, et il faut installer python, pytoolkit, toolkit
                    et dépendances du toolkit + pydependances du toolkit (ceux qui font du pygtk
                    doivent sourire en ce moment...). Bon, ca j'avoue que c'est super lourd...

                    - Python n'est pas un langage normé ISO (bon, celle-la me fait toujours rire,
                    mais peu avoir de la valeur), ceci impliquant aussi le prochain point,

                    - Python à au moins 6 implémentations différentes (Cython, UnladenSwallow,
                    Jython, IronPython, Pypi, Stackless), ayant toutes des différences de
                    comportement et de librairies, donc python n'est pas portable entre ses
                    différentes implémentations (bon, le C/C++ c'est pareil, hormis le C(++)
                    ansi sans utiliser la STL, c'est pas portable d'un compilo à un autre. C'est
                    encore plus vrai pour les libraries qui ne fonctionnent pas de la même
                    manière d'un système à un autre (Apple, quand tu packages !!!) et c'est la
                    plaie des systèmes de build (Mais ou est donc pkg-config sous Windows ?)

                    - Python sucks pour d'interfacer avec du C++ (alors qu'avec du C c'est très
                    simple) et cela parce que C++ sucks sur le name mangling et autres bêtises.
                    (Les symboles exportées par le compilateur peuvent être différents d'un
                    compilateur à l'autre. J'avoue que je ne sais pas exactement qu'elle est le
                    statut des normes à ce sujet)


                    Bon, je vais me coucher, vous pouvez moinser... A non, faut que je relise
                    l'orthographe avant... (et merde...)
                    • [^] # TL;DR

                      Posté par . Évalué à  0 .

                      TL;DR
                      • [^] # Re: TL;DR

                        Posté par . Évalué à  1 .

                        Idem, mais c'est bien argumenté (oui je l'ai quand même lu, j'ai honte), et je ne comprends pourquoi il est 0!

                        Depending on the time of day, the French go either way.

                        • [^] # Re: TL;DR

                          Posté par . Évalué à  2 .

                          Je crois que tu n'as pas bien compris le sens de "TL;DR"...
                          • [^] # Re: TL;DR

                            Posté par . Évalué à  2 .

                            Si, si, To Long, Didn't Read, mais je me devais de lire sa prose, pour pouvoir me plaindre de la note de son commentaire. Mais moralement j'etais en mode TL;DR.

                            Depending on the time of day, the French go either way.

                            • [^] # Re: TL;DR

                              Posté par . Évalué à  -2 .

                              Un commentaire trop long, moi, j'en attends qu'il soit moinssé. Parce qu'il ne sert à rien (vu qu'on le lira pas), et qu'il force à scroller pendant un moment.
                              • [^] # Re: TL;DR

                                Posté par . Évalué à  4 .

                                Tu ne navigues pas en -42 comme tout le monde?
                                Moi, c’est plutôt les commentaires bien argumentés, mais n’allants pas dans mon sens que je préfère voir moinsés, je n’aime pas avoir a me remettre en question, mais heureusement c’est plutôt rare ici.

                                Depending on the time of day, the French go either way.

                                • [^] # Re: TL;DR

                                  Posté par . Évalué à  2 .

                                  Tu ne navigues pas en -42 comme tout le monde?
                                  Tu oublies que je ne suis pas tout le monde :)

                                  Moi, c’est plutôt les commentaires bien argumentés, mais n’allants pas dans mon sens que je préfère voir moinsés, je n’aime pas avoir a me remettre en question, mais heureusement c’est plutôt rare ici.
                                  Oui, mais il n'empêche que devoir scroller si longtemps est pénible. Un message trop long convainc tout aussi mal qu'une argumentation nulle.
                                  On va me parler de la toolbar, mais quand je lis, je ne suis pas forcément identifié au site, je n'ai pas les mains sur le clavier, et la toolbar ne permet de naviguer qu'entre les nouveaux commentaires.
                                  • [^] # Re: TL;DR

                                    Posté par . Évalué à  2 .

                                    Tu oublies que je ne suis pas tout le monde :)
                                    En fait, je n’étais même pas au courant. J’ai été absent longtemps, et je ne connais pas toutes les nouvelles têtes /o\

                                    Oui, mais il n'empêche que devoir scroller si longtemps est pénible.
                                    Je n’ai pas de problèmes de scroll, je barre d’espaceise.

                                    Depending on the time of day, the French go either way.

                              • [^] # Re: TL;DR

                                Posté par (page perso) . Évalué à  3 .

                                Génération Facebook...

                                Chippeur, arrête de chipper !

                                • [^] # Re: TL;DR

                                  Posté par . Évalué à  2 .

                                  Pire, génération 4chan.
                                  • [^] # Re: TL;DR

                                    Posté par . Évalué à  2 .

                                    DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU DESU

                                    Depending on the time of day, the French go either way.

                                • [^] # Re: TL;DR

                                  Posté par . Évalué à  0 .

                                  Je te prie à l'avenir de ne plus m'assimiler à ce "truc".
                      • [^] # Re: TL;DR

                        Posté par (page perso) . Évalué à  3 .

                        Il y a aussi la largeur de 72 caractères qui augmente l'impression de longueur. Ça fait tout drôle sur ce site où le design est extensible.

                        Envoyé depuis mon lapin.

                        • [^] # Re: TL;DR

                          Posté par . Évalué à  2 .

                          Presque 4000 mots quand même...

                          Depending on the time of day, the French go either way.

                          • [^] # Re: TL;DR

                            Posté par (page perso) . Évalué à  3 .

                            Mon dieu, et dire qu'a une époque j'avais du mal à écrire plus de 300 mots...
                    • [^] # Re: Une vraie question

                      Posté par (page perso) . Évalué à  2 .

                      Pour lier du C++ avec python, boost python est vraiment très pratique.

                      Sinon, je trouve ton commentaire très intéressant, bien que l'on ne soit pas d'accord sur tout.

                      Alors, dans l'ordre:

                      30 minutes pour compiler un projet en C++, c'est un extreme. Je vois mal un tel projet en python (ou alors, faut aimer les lancements qui durent plusieurs minutes).

                      Si l'on utilise «correctement» la STL, en utilisant at au lieu de operator[] sur un vecteur par exemple, je ne pense pas que le C++ devienne presque aussi lent que le Python.

                      Si je me suis déjà amusé cette année (études) à remplacer les algorithmes de gestion mémoire par les miens, (et que j'ai constaté que malloc faisait beaucoup mieux son travail que mes algorithmes), je ne pense pas qu'il y ait besoin de programmer une fusée pour avoir besoin de gérer la mémoire. Je reste contre l'idée d'abandonner la gestion de la mémoire. Il suffit d'avoir une architecture organisée, et de réfléchir un peu à ce sujet, c'est tout.

                      J'avais lu un article d'un développeur sur ruby on rails, qui avait optimisé une partie du framework en s'occupant de la mémoire. Avec le ramasse miettes, ils ne s'étaient jamais occupés de la mémoire. En analysant les copies d'objets, il avait remarqué qu'un objet pouvait être copié plusieurs dizaines de fois par page. En changeant certaines petites portions du code, il a supprimé les copies, et il a amélioré les performances.

                      Et pourtant, ruby on rails, c'est pour des interface. Il y a une grosse base de données derrières, la latence du réseau, et tout le reste.

                      Sinon, je ne connaissais pas la décoration des arguments de fonction, je vais m'y mettre :-)

                      Pour l'exemple du bar, et le self, c'est des principes différents. Avant de commencer mes études, j'étais plus dans l'optique du python (je faisais du ruby), car c'est plus pratique. Mais maintenant, je vois que le C++ permet beaucoup plus facilement de travailler en entreprise.

                      Pour modifier une chaîne de caractère, ça m'est déjà arrivé, je ne sais plus pourquoi, donc on va dire que c'est rare.

                      Pour les exceptions des jeux de caractères, typiquement, j'attends une chaîne en utf8, de base en python3. Sauf que l'utilisateur me passe de l'iso-42, car il comprends rien. Se taper une exception pour ça me gonfle. Alors, à la place, j'utilise la librairie de base codecs, mais ça remplace les caractères non valides. Ça serait plus simple de stocker des caractères non valides. Si l'utilisateur passe de l'iso-42, il s'attend à avoir en retour de l'iso-42, pas un truc qui lui a bouffé tout ses accents.

                      L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.

                      Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces. Puis le ; oublié, en général, le compilateur l'informe assez clairement (à part celui après une struct ou une class, qui génère un lot d'erreurs qui n'ont rien à voir impressionnant).

                      En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.

                      Envoyé depuis mon lapin.

                      • [^] # Re: Une vraie question

                        Posté par (page perso) . Évalué à  2 .

                        > 30 minutes pour compiler un projet en C++, c'est un extreme.

                        Le projet sur lequel je bosse prends bien plus de 30 minutes.
                        Heureusement, au bureau, on a une ferme de compilation, donc c'est beaucoup plus rapide.
                        Et on ne recompile pas l'entièreté du projet à chaque changement.



                        Sinon, si on n'aime pas les erreurs incomprhensible de GCC, il faut essayer clang:
                        http://fseek.me/2010/03/how-to-convince-any-c-developer-to-d(...)
                        http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re(...)
                      • [^] # Re: Une vraie question

                        Posté par (page perso) . Évalué à  0 .

                        Rapidement, parce qu'après l'on va dire que c'est trop long (mes excuses pour le 72 colonnes fixe, naïvement je pensais que la saisie "html" ferait des retours à la ligne au niveau des doubles retours à la ligne et ignorerait les simples, trop d'année sous vim et trop de rst ;)

                        Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)

                        Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.

                        Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).

                        Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.

                        Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.

                        Pour ton problème d'encodage.

                        - Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)

                        - Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.

                        L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.

                        - Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))

                        - Tu peux décharger des modules, après faut voir si cela à un sens
                        - Tu peux faire de la programmation de carte graphique en Python ;)
                        - Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)


                        Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.


                        Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)

                        En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.

                        Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"
                      • [^] # Re: Une vraie question

                        Posté par (page perso) . Évalué à  2 .

                        c´est quoi cette histoire d´utiliser at() à la place de []. Dans la stl que j´ai, ils font exactement la même chose. (je parle de std::vector)
                        • [^] # Re: Une vraie question

                          Posté par (page perso) . Évalué à  3 .

                          at() va vérifier si tu accède bien à un élément qui existe. Si ce n'est pas le cas, tu as une exception out_of_range.

                          operator[] lui, il ne vérifie rien, comme en C. Dans le meilleur des cas, tu as un signal pour une erreur de segmentation. Dans le pire des cas, t'en a pas, et ça fait foirer complètement ton programme.

                          operator[] est beaucoup plus performant, mais plus dangereux. Mais c'est sympa les erreurs de segmentation :-)

                          Envoyé depuis mon lapin.

            • [^] # Re: Une vraie question

              Posté par (page perso) . Évalué à  4 .

              > Pourquoi ne pas tout faire en Python plutôt ?

              QML utilise ECMAScript, qui est déjà intégré avec Qt depuis longtemps. Donc on a déjà un langage de script.
              Et comme c'est prévu pour l'embarqué, les limites des langages de script sont les performances, l'utilisation de la batterie, ...
              Donc associer avec un langage compilé comme le C++ c'est du bonheur.

              Mais si tu veux quand même faire du Python, pas de problème, il existe des bindings Python.
  • # Une impression de déjà vu

    Posté par . Évalué à  7 .

    Peut-on dire que QML est à C++ ce que javafx est à java?
    • [^] # Re: Une impression de déjà vu

      Posté par . Évalué à  4 .

      oui, sauf que ça semble fonctionner, et même sur des portables, et que bien que ça ait commencé à être développé après JavaFX, ça marche déjà bien semble-t-il. JavaFX ne fonctionne pas chez moi et ça à le malheur de ralentir le développement de Swingx.

      Puis il y a déjà un IDE qui à l'air de bien fonctionner, avec des vidéos sur Youtube. Donc c'est plusse top.
  • # Edje

    Posté par (page perso) . Évalué à  8 .

    Finalement ils ont réinventé Edje qui existe dans E17 depuis un moment. C'est pas que c'est mal, mais ils auraient pu le faire plus tôt.

    http://trac.enlightenment.org/e/wiki/Edje
    • [^] # Re: Edje

      Posté par . Évalué à  7 .

      Mais tu oublies de dire que cela fait quelques annees que l'on attend de voir la version officiellement stable de E17, ayant deja vu des bersions de devs c'est pas du vrai vaporware mais c'est limite.
      • [^] # Re: Edje

        Posté par (page perso) . Évalué à  3 .

        J'utilise donc un limite vaporware depuis début 2004. OK, au début, la config se faisait en ligne de commande, mais E17 est utilisable depuis plusieurs années.

        Alors peut être que l'erreur de la team E17 est de ne pas avoir voulu estampillé 4^1.0 une version qui n'était pas complète, ou tout au moins pas utilisable simplement par des utilisateurs non avertis, mais c'est un autre débat.

        Bon, ceci étant dit, je suis plutôt content que KDE reprennent les idées de E17 - après tout, si j'utilise ce dernier, c'est bien parce que j'aime bien leur approche.
        • [^] # Re: Edje

          Posté par . Évalué à  7 .

          >J'utilise donc un limite vaporware depuis début 2004. OK, au début, la config se faisait en ligne de commande, mais E17 est utilisable depuis plusieurs années.
          C'est soit que tu ignores, soit que tu écarte le fait qu'on avait essayé une version compilable en 2000 ou 2001 (il y avait eu un article spécial dans linux mag genre le windows manager du futur arrive), que ça faisait alors déjà plusieurs années qu'on attendait la relève de e16, que rasterman n'avait pas été vraiment discret sur les promesses faites à propos de son bébé, que le développement s'est ensuite stoppé après que rasterman soit parti, puis qu'il soit revenu ensuite. Bref, entre dallas et enlightenment forever. etc
          Donc super que ça marche, mais tu n'empêcheras jamais que pas mal de gens ont vécu ça, s'en souvienne et du coup n'arrive pas à percevoir e17 autrement que comme un vaporware.

          C'est comme ça que les réputations se font indépendamment des qualités ou de l'état réels du projet. C'est malheureux mais il ne faut pas aller contre, parce que c'est inutile, il faut simplement lister les qualités et l'état du projet avec acharnement en attendant patiemment que ça finisse par rentrer dans la tête de ceux qui écoutent. Parfois en vain.
        • [^] # Re: Edje

          Posté par . Évalué à  2 .

          J'utilise donc un limite vaporware depuis début 2004. OK...

          Tu l'utiliserais depuis 2004 mais il n'est toujours pas disponible officiellement, c'est qu'il y a un soucis, non?

          Qu'est-ce qu'ils les empêchent de remplacer une bonne fois pour tout le vieillissant e16?
    • [^] # Re: Edje

      Posté par . Évalué à  7 .

      on le télécharge où le Edje Designer ?

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Edje

        Posté par (page perso) . Évalué à  1 .

        Ici :

        http://trac.enlightenment.org/e/browser/trunk/editje

        Pour info QML s'appelait QEdje a ses debut...
        • [^] # Re: Edje

          Posté par . Évalué à  2 .

          Pour info QML s'appelait QEdje a ses debut...

          Je ne pense pas. QEdje est un interpréteur Edje pour Qt, et n'a aucun lien de parenté avec QML (à part le concept, partagé aussi avec Clutter du côté Gtk).
          http://code.openbossa.org/projects/qedje
        • [^] # Re: Edje

          Posté par (page perso) . Évalué à  2 .

          QML et QEdje sont donc projet complétement différents.

          Le but de QEdje était d'essayé d'intégrer Edje dans Qt. Mais c'est difficile car Edje utilise son propre canevas.

          QML est dès le départ prévu pour fonctionner avec Qt, et les éléments sont des QObject et ça utilise le méchanisme des propriété de Qt.

          Et Qt peut utiliser l'accélération OpenGL/OpenVG/... alors que le canevas de Edje est purement software il me semble.
          • [^] # Re: Edje

            Posté par . Évalué à  4 .

            D'apres ce que j'ai suivi sur QML, ceux sont les personnes qui ont essaye de realiser QEdje qui ont participe a la creation de QML. Mais maintenant la phylosophie derriere, il y a pas mal de difference entre QML et Edje.

            Edje est concu pour etre sandboxable et propose une vrai separation de la logique applicative du design de l'interface. L'objectif etant de n'avoir qu'a change le theme quand tu changes de terminal (telephone, netbook, tablet, ...).

            QML au contraire, permet de quasiment coder toute ton application dedans. Ca lui permet de faire beaucoup plus de chose avec un seul langage, mais cela a un prix. Prix en terme de modularite, de fonctionnalite et de performance.

            Sinon pour ce qui est de Edje, et de l'acceleration hardware. Edje utilise le canvas propose par Evas qui va utiliser divers backend parmis le moteur purement soft, directfb, sdl, opengl et opengl-es. Il est vrai que le backend soft est tres performant, et tiens souvent la drage haute au backend gl.

            Pour diverse raison, entre autre que le backend soft est plus intelligent en consommant moins de bande passante. OpenGL n'est pas adapte a faire des interfaces 2D, car il force a redessiner tout l'ecran et donc necessite un fillrate plus eleve. Apres lorsqu'on a besoin du CPU principal pour autre chose que l'affichage, ce qui est souvent le cas dans l'embarque, on va bien entendu utiliser les moteurs accelerer par des puces dedies. Donc OpenGL n'est pas la panace absolu qui rendra vos interfaces belles et fluides. Juste une solution qui marche pour ameliorer des fois les choses.
            • [^] # Re: Edje

              Posté par (page perso) . Évalué à  2 .

              > D'apres ce que j'ai suivi sur QML, ceux sont les personnes qui ont essaye
              > de realiser QEdje qui ont participe a la creation de QML.


              QEdje était réalisé par OpenBossa, au brésil.
              QML est principalement développé par des anciens dev de Qtopia, en Australie.

              Mais c'est vrai que on peu voir sur le blog du dev de QEdje que il fais des truc en QML maintenant [http://blog.morpheuz.cc/]
  • # sapueplus?

    Posté par . Évalué à  -8 .

    Qt est Libre? Et on va me dire que Suse saibien, et que Mandrake n'est pas qu'une RedHat maquillée comme une voiture volée!

    Depending on the time of day, the French go either way.

    • [^] # Re: sapueplus?

      Posté par (page perso) . Évalué à  8 .

      Bah c'est en LGPL, y'a un bug tracker, y'a un arbre git, on peu proposer des patchs, des fois ils sont mergés .. ça m'a l'air assez libre quand même :).

      D'ailleurs si ceux que ça intéresse une file de priorité en Qt, allez le dire sur http://qt.gitorious.org/qt/qt/merge_requests/2368 :)
    • [^] # On n'est plus en 1995

      Posté par . Évalué à  5 .

      Oui, Qt 4.x est libre et ouvert (même si les débuts de l'ouverture étaient assez chaotiques, les développeurs n'ayant pas l'habitude).
      openSuse est libre aussi [yast a été libéré, voir http://fr.opensuse.org/YaST] et, pour l'avoir testée la semaine dernière, gère pas mal
      Cela fait longtemps que Mandriva évolue indépendamment de RH (je dirai depuis les versions 7.x ou 8.x, autant dire le millénaire dernier). Si tu veux une RH maquillée, regarde du côté de CentOS.

      On est en 2010 monsieur, il faudrait se mettre à jour un peu :)
    • [^] # Re: sapueplus?

      Posté par (page perso) . Évalué à  6 .

      Sacrément mal réglé ton ipot!
      • [^] # Re: sapueplus?

        Posté par (page perso) . Évalué à  4 .

        Le problème des ipots catalytiques c'est qu'il faut une phase de préchauffage.
      • [^] # Re: sapueplus?

        Posté par . Évalué à  6 .

        Plutôt Hibernatus que ipot, je dirais.

        Depending on the time of day, the French go either way.

    • [^] # Re: sapueplus?

      Posté par . Évalué à  3 .

      Soit je me fais vieux pour comprendre ce post, soit linuxfr c'était mieux avant question humour :)

      Messieurs/dames les moinsseurs, je ne vous salue point.
      • [^] # Re: sapueplus?

        Posté par . Évalué à  2 .

        Mais j’ai la vague impression d’en oublier un ou deux de trolls d’époque.

        PS:Et tu te fais vieux :)

        Depending on the time of day, the French go either way.

  • # Salut, j'ai vraiment bien aimé cette démonstration

    Posté par . Évalué à  0 .

    Bonjour, j'ai trouvé cette démonstration sur youtube : [http://www.youtube.com/watch?v=AvFwzyCknLg]. Je trouve cela assez intéressant de voir que les performances sont très bonnes avec un petit ARM à 200Mhz. C'est très épatant. Je pense que les appareils très portables sont intéressants, et aussi que c'est bien d'avoir un environnement intégré pour ces appareils. QML c'est bien, bravo, il faut continuer.

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

  • # XML

    Posté par . Évalué à  2 .

    QML veux dire originalement Qt Markup Language. Car au début c'était du XML. Mais XML c'était le buzz des années 00, et maintenant c'est dépassé. Les développeurs ont vu que XML c'est moche et pas pratique, alors ils ont inventé une super syntaxe innovatrice.

    Ils ont peut-être compris que le XML n'a jamais été conçu à cette fin?

    À lire à ce sujet un excellent billet - encore - de JP Troll dans le LinuxMagazine de ce mois ci!
  • # Zut ! Ils ont eu la même idée que moi

    Posté par (page perso) . Évalué à  4 .

    J'avais eu cette idée depuis 6 mois, de définir des interfaces avec des automates à états..; Bon bah c'est génial, il l'ont fait et bien fait.

    Quand on regarde bien, une interface utilisateur nécessite un automate à état pour fonctionner, je dirai même un automate à état hiérarchique (ie. des états peuvent contenir des machines à états), c'est le système le plus naturel, plutôt que gérer des callback.

    Couplé aux système slots, c'est génial !

    Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

  • # Programmation d'interfaces graphiques déclaratives ?

    Posté par (page perso) . Évalué à  1 .

    J'avais testé QT Creator il y a quelques temps pour un projet professionnel qui nécessitait éventuellement un client graphique. J'avais trouvé ça pratique pour faire un "canevas" de mon application ; par contre pour le contenu vraiment dynamique (d'un point de vue contenu, pas d'un point de vue animation) ce n'était pas du tout adapté. Qu'en est-il de QML ?

    Le jour où tu veux ajouter un nouveau mode de fonctionnement de ton application qui présente un contenu complètement différent, ça évolue bien QML ? Il suffit de faire une fabrique et d'instancier le nouveau contenu au lieu de l'ancien ? Exemple : je fais un browser de fichiers musicaux, ma première version permet de naviguer dans mes fichiers MP3 et d'afficher les tags ; puis un jour je décide de gérer aussi les OGG (tout en affichant les tags spécifiques) et je veux également proposer une interface de modification des tags et un lecteur audio. Ca se fait bien ? (je parle pas d'ajouter un bouton dans la barre d'outils, hein, je parle d'instancier un "widget" mp3 ou ogg ou je sais pas quoi avec une logique potentiellement tout à fait différente).

    Je suis relativement sceptique sur les interfaces déclaratives (sauf pour des applications relativement simples). Ok on peut scripter l'interface en ECMAScript et faire le reste en C++. Mais un code dont l'intelligence est éclatée dans différents languages et différentes logiques est difficile à maintenir. Donc pour moi l'idée "on fait du ECMAScript et si ça on atteint les limites on code ça en C++" c'est une mauvaise idée. A la limite si on décide "telle intelligence en ECMA, et telle autre en C++" ça a une logique...
    • [^] # Re: Programmation d'interfaces graphiques déclaratives ?

      Posté par (page perso) . Évalué à  3 .

      Je comprends pas pourquoi dis tu que Qt n'est pas adapté pour du contenu dynamique. Il y a plein d'application Qt qui le font (regarde les appli kde, comme amarok)
      Qt est aussi pas mal utilisé dans l'industrie du cinéma.
      http://qt.nokia.com/qt-in-use/qt-in-visual-effects
      Le future Maya 2011 est fait avec Qt.
      Maintenant, ils ont peut-être tous tord, et tous choisis une technologie inadaptée.

      QML est basé sur QGraphicsView, donc pas de changement.

      En théorie, la séparation devrais se faire entre QML pour l'interface graphique, et C++ pour la logique. (Mais biensur on est libre de faire un peu de logique en javascript dans QML quand c'est adapté.)

      Sinon pour ton problème de mp3 et ogg : oui, il est facile d'instancier des composant différent.
  • # vendredi

    Posté par . Évalué à  2 .

    (même si on est en vacances, le vendredi reste un jour particulier)

    Après avoir vu les vidéos d'exemple, et tout le monde se réjouir, je ne peux qu'être perplexe : sur DLFP, on voit souvent les gens se révolter quand chaque programme utilise son propre skin, plutôt que laisser le système (+ la config de l'utilisateur) tracer l'interface. Or c'est précisément ce que montre les vidéos de QML : aucune démo ne se ressemble.
    Bientôt, ça ressemblera à ça : http://sam.zoy.org/writings/dvd/players/
    • [^] # Re: vendredi

      Posté par (page perso) . Évalué à  3 .

      Je suis entièrement d'accord avec toi.

      Mais c'est plus ciblé pour l'embarqué, dans lequel on a juste un interface plein écran. Et chaque appli a son propre style.

      Mais je regrete également l'absence de style dans QML, alors que les widgets "normaux" de Qt sont si facile à intégrer dans les différents OS/bureaux.
      Ce sera peut-être pour une prochaine version.
      • [^] # Re: vendredi

        Posté par . Évalué à  2 .

        Pour l'embarqué, c'est pas une édition dédiée de Qt ?
        • [^] # Re: vendredi

          Posté par (page perso) . Évalué à  3 .

          Qt fonctionne sur différente platformes, dont Linux/X11 et "Embedded Linux"
          La différence entre les deux est que "Embedded Linux" utilise le frame buffer, et un système de gestion des fenêtres spécifique.

          Mais beaucoup de platformes dite embaquées (comme Maemo, Meego, openmoko, ...) utilisent quand même X11 (pour la compatibilité avec Gtk), donc c'est le port X11 de Qt qui est utilisé.

          Il y avais aussi Qtopia, renommé plus tard Qt Extended, qui était une solution applicative complète pour smartphone (chinois). Mais Nokia n'a pas continué le développement de cette platforme après le rachat de Trolltech. Une partie du code est néenmoins réutilisé dans le projet Qt Mobility.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.