Journal Transparence et plus dans Gtk+ avec Murrine

Posté par .
Tags : aucun
1
13
déc.
2007
Salutations,

Décidément, Murrine est un moteur de rendu Gtk qui monte. Andrea Cimitan nous prouve que Gtk+ est loin, très loin d'être obsolète, en ajoutant la transparence à Murrine. Un simple moteur de thème et *toute* vos applications Gtk+ profite de la transparence native :)

À quand la réponse de Qt ? :P

Encore un superbe article de Ryan Paul (alias Segphault) sur Ars Technica : http://arstechnica.com/journals/linux.ars/2007/12/12/gnome-t(...) tiré du blog d'Andrea Cimitan : http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-(...) .

Ce qu'il manque, c'est un "kit d'animation", un gak qui fairait partie de Gtk+. Clutter et Pigment semble pas assez orienter manipulation de Widgets. À quand un fondu + déplacement à la suppression d'une ligne d'un TreeView ? À quand un fondu au changement d'onglet d'un NoteBook ? Pour cela, il faudra bien un API dédié !?

Cordialement,
Étienne.
  • # Qt ?

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

    Je sais pas si c'est bien la même chose, en tout cas google qt argb me repond tres rapidement ca: http://zrusin.blogspot.com/2006/10/argb-windows.html (j'ai regardé très rapidement le code source je crois que ca fait un peu dans le genre de ce dont tu parle)
  • # Re:

    Posté par . Évalué à -3.

    La transparence par pixel (ou widget) est un vrai plus. Jusqu'à maintenant c'était par fenêtre. En plus, ça doit probablement ne rien coûter puisque c'est la carte graphique qui doit faire le gros du boulot.

    > Ce qu'il manque, c'est un "kit d'animation"

    Dans quel cas ? Pour faire du "flash" ?

    > À quand un fondu + déplacement à la suppression d'une ligne d'un TreeView ?

    J'ai rien contre, mais je me fous de cette "fonctionnalité".

    > À quand
    > À quand

    Des gens attendent que tu le fasses.
    • [^] # Re: Re:

      Posté par . Évalué à 8.

      > Dans quel cas ? Pour faire du "flash" ?

      Pour rendre des application attractives par nombre d'utilisateurs lambda... que ce soit pour desktop simple ou pour l'utilisation de gtk sur de l'embarqué.

      Une petite recherche sur ce site te montrera par exemple ce que l'on peut faire avec les efl dans le cadre d'une application de domotique .. les clients ont droit à quelque chose de très attractif visuellement, pourquoi pas laisser les développeurs faire du semblable avec du gtk ?

      > J'ai rien contre, mais je me fous de cette "fonctionnalité".

      Ben comme tu peux le voir dans ce journal... il n'y a pas que toi sur terre, et qui plus est, d'autres pensent différement de toi...

      > Des gens attendent que tu le fasses.

      A quand des gens qui ne critiquent plus pour le plaisir ceux qui s'interrogent sur l'avenir et s'émerveillent sur l'évolution actuelle des choses ?



      Désolé, j'ai pas dans l'habitude de répondre aux trolls... mais là c'était plus fort qui moi ... la pitié de voir un ventre affamé peut être ?
      • [^] # Re: Re:

        Posté par . Évalué à 2.

        Je ne suis pas sur que ce soit ce que vous cherchiez mais MDI prévoyait de créer un widget gtk utilisant Moonlight. [1]
        http://tirania.org/blog/archive/2007/Jun-21.html

        [1] Moonlight est implémenté en C et un peu de C++, et est utilisable en dehors du runtime Mono.
    • [^] # Re:

      Posté par . Évalué à 10.

      Salutations,

      Les animations améliore la perception de l'interface. L'idée est toujours de raccrocher à la réalité. Si j'ouvre un tiroir, je le glisse vers moi ; etc. Les interface graphique utilise déjà énormément d'allgorie et de comportement directement issue du réel (ex: la corbeille, le glisser-déposer, etc.), les animations ne doivent être utilisé que pour renforcer la compréhension de ce qui se passe.

      Étienne.
  • # Réponse de Qt ?

    Posté par . Évalué à 10.

    Pourquoi Qt devrait répondre ?
    C'est juste une histoire de thème, et c'est déjà techniquement réalisable. Par exemple le panel de KDE4 a des zones semi-transparentes... Puis Qt 4.4 pourra mieux vu que chaque widget pourra subir des transformations barbares...

    Sinon pour ton histoire d'animations... c'est faisable avec Qt. À l'époque où le thème oxygen était une bidouille immonde, y'avait une animation sympa lors des changements d'onglets. Lors de la réécriture du thème ils l'ont enlevé par contre.
    • [^] # Re: Réponse de Qt ?

      Posté par . Évalué à -4.

      ok qt peux peut etre le faire par contre s'il te plait ne parle pas de la bouse infame qu'est le panel de KDE4. Dire que c'est une rc2 le dernier truc que j'ai teste, qu'il n'y a toujours aucun moyen de configurer les elements plasma, que la mise en plein ecran d'un programme comme krita atterissent derriere le panel c'est hyper pratique surtout que ce dernier n'est pas enlevable, pas bougeable, pas configurable, enorme et inhestetique. Ils vont mettre un truc critique comme la configuration du desktop/panel sans l'avoir teste dans la version finale? Ca me fait legerement peur pour kde4.0 ...

      Enfin si quelqu'un sait ou cela se configure dans les fichiers je suis preneur aussi.
      • [^] # Re: Réponse de Qt ?

        Posté par . Évalué à 8.

        Je n'utilise pas KDE et le peu que j'ai testé ne m'a pas plu.
        M'enfin, il faut un peu réflechir en pensant aux développeurs.
        Alors d'accord KDE 4.0 sera peut-être une "bouse". Mais c'est la première version d'un version .0. Linux 2.6.0 n'était pas génial non plus. Mais d'un point de vu gestion de projet, il est compréhensible de sortir KDE 4.0 même s'il "sucks" ici et là. Par contre, évidement, il doit être stable (et très stable pour l'API).

        > Ca me fait legerement peur pour kde4.0 ...

        Attend la version 4.0.1 et mieux la branche 4.1 qui est déjà dans les têtes des développeurs.
        • [^] # Re: Réponse de Qt ?

          Posté par . Évalué à -1.

          j'ai pas dit que KDE4 etait une bouse, j'ai dit que le panel de KDE4 etait une bouse tant qu'il est impossible de le configurer.

          Apres personnellement je suis pas du tout certains que ce soit une bonne idee de sortir un kde4 sans avoir la possibilite de configurer un minimum les elements plasma. Enfin ca c'est mon opinion, j'ai teste j'ai pas pu m'en servir, j'ai fait les bugs reports mais bon si cela change pas ca va etre la meme chose pour la version final et je suis a peu pres persuade de ne pas etre le seul dans ce cas (loin de la, la critique sur le panel elle est a peu pres general). Ce qui reviendra au meme d'un point de vue de developpement si les utilisateurs ne font pas remonter plus que les bugs/problemes les plus visibles.
          • [^] # Re: Réponse de Qt ?

            Posté par . Évalué à 10.

            Ben sortir un logiciel le plus complet possible et avec le moins de bug possible, naïvement c'est mieux.

            Mais d'un point de vu gestion de projet, c'est plus discutable. Et gestion de projet, c'est aussi gestion des développeurs (rester en freeze/rc longtemps va mettre des développeurs au "chomage"). De plus, il y a aussi le modèle du libre : sortir tôt et souvent.
            Maintenant que KDE 4.0 est en freeze, qu'il y a une date de sortie d'annoncée qui sera grosso-modo respecté, on voit OpenSuse faire des iso pour tester, Fedora commencer le paquetage, des développeurs d'applis qui commencent le portage de leur appli vers KDE 4, etc. Reporter la sortie de KDE 4.0 car il y a deux ou trois trucs qui sucks, c'est aussi repporter tout ça.

            Si on est un "supporter" du libre, on se doit de comprendre un minimum cette problématique ou au moins en connaitre l'existance. Notamment par respect pour les développeurs.

            Il y a du compromis dans tous ça et chaque projet a sa "sensibilité". KDE a déjà annoncé que certaines fonctionnalités absentes de 4.0 seront faites en post 4.0.

            Évidemment, si tout ça n'est pas corrigé en version 4.0.2 ou 4.1, la critique de la gestion du projet aura plus de légitimité.

            Je ne fais pas un appel à la "censure". Si le panel sucks, ben on peut dire qu'il sucks, on peut évidemment aussi faire un rapport de bug. M'enfin, il semble globalement marcher et c'est une version majeur de KDE.
            Il faut mettre tout ça dans le contexte au-lieu de "critiquer" à la va vite les décisions des développeurs/mainteneurs. KDE 4 a des changements majeurs, il faudra attendre un peu pour qu'il soit à maturité. Comme on l'a vu pour Gnome/Gtk 2, etc.

            Il y a différente type de critique. Je parlais ici de la gestion de projet et non de la critique de la "philosophie" ou des orientations du projet. Globalement je préfère la philosophie de Gnome à KDE. Qu'on soit en version .0 ou non n'y change rien.



            M'enfin, je n'ai pas essayé KDE 4, et t'as peut-être raison. Une bonne gestion de projet doit aussi évidemment prendre en compte les utilisateurs. Si KDE 4.0 est une déception pour l'utilisateur, même si c'est la réussite technique que voulait les développeurs, les dommages seront long à réparer.
            • [^] # Re: Réponse de Qt ?

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

              Clair, il suffit de se souvenir de gnome 2.0...

              Mais la, ce que les gens ne comprennent pas, c'est que Kde 4.0 RC2 est une RC de la version "Technologie Preview" (comme ils disent) de Kde4. C'est pas fait pour ma grand mère quoi.

              D'ailleurs, des widgets plasma sont encore arrivés dans le dernier "commit digest".

              Mais kde 4.0 n'aura pas:
              - De configuration du panel (sauf code de dernier moment... Ce dernier est configurable via son fichier de conf...)
              - Pas de Kdepim
              - ...

              Bref, faut arreter de faire chier les devs avec des "ouin, je peux pas me servir de Kde 4.0 comme de Kde 3.5, c'est de la merde!"

              Que je sache, kde 3.5 sera encore supporté jusqu'a kde 4.1 (la premiere version finalisé de Kde4).
              • [^] # Re: Réponse de Qt ?

                Posté par . Évalué à 3.

                - De configuration du panel (sauf code de dernier moment... Ce dernier est configurable via son fichier de conf...)

                Lequel? J'ai pas reussi a trouver ou c'etait dans ~/.kde4/share/config
                • [^] # Re: Réponse de Qt ?

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

                  • [^] # Re: Réponse de Qt ?

                    Posté par . Évalué à 2.

                    super ton lien me permet de rajouter un pager au panel... Ah j'avais essaye avant de changer dans le fichier en question la taille du panel (et de toutes les applets associes au cas ou) et bon ca marchait pas trop. Au redemarrage de kde4 ca revient a la taille enorme de depart d'ou le fait que je demande dans quel fichier la config doit se trouver.

                    Enfin c'est pas trop grave comme dit plus haut un panel aussi gros et le fait que la maximisation des fenetres les places derrieres m'empechent d'utiliser kde4 et comme ce leger detail ne sera pas change avant kde4.1 je retenterai a ce moment la.
    • [^] # Re: Réponse de Qt ?

      Posté par . Évalué à 2.

      > Pourquoi Qt devrait répondre ?

      Très bonne remarque. La transparence de gtk+ n'est pas une réponse à Vista non plus (sinon ça aurait été fait beaucoup plus tôt).
      • [^] # Re: Réponse de Qt ?

        Posté par . Évalué à 1.

        Non, Gtk+ a voulu répondre à Vista, mais proprement, en sortant un truc bien conçu quand il est prêt plutôt que de se précipite à sortir la fonctionnalité ActiveX pour finalement s'interroger sur la sécurité du bidule.

        La preuve que cela fut fait en pensant à Vista ? Les captures d'écran, bien sûr ! Vous n'allez pas me dire que vous ne remarquez rien. En plus, Rian Paul met les pieds dans le plats : « bringing Vista-like translucent glass effects to the GNOME desktop. » que je traduit par apportant des effets verre transparent à la Vista au bureau de Gnome.

        Ceci, dit c'est vrai que ça a mis du temps : un an depuis la sortie de Vista. Et je ne parle même pas de la transparence de Mac OS X, disponible depuis 2001...
        • [^] # Re: Réponse de Qt ?

          Posté par . Évalué à 6.

          La transparence dans X, c'est possible depuis... pffiou, longtemps. Avant 2001, sûr et certain.
          Cf http://freedesktop.org/wiki/Software/Xserver et http://freedesktop.org/wiki/Software/TranslucentWindows
          Par contre, ce qui a pris beaucoup de temps, c'est l'intégration dans un serveur X officiel utilisé par les gens. Merci XFree86 :/
          • [^] # Re: Réponse de Qt ?

            Posté par . Évalué à 2.

            "Par contre, ce qui a pris beaucoup de temps, c'est l'intégration dans un serveur X officiel utilisé par les gens."

            Et c'est bien ce dont je parlais.
        • [^] # Re: Réponse de Qt ?

          Posté par . Évalué à 2.

          > Non, Gtk+ a voulu répondre à Vista

          Mais oui....
          D'ailleur on dit souvent que Gnome ressemble à ... Mac.

          La modiification de Gtk+ est assez mineur.
          Si Gtk était préoccupé par Vista, il y a longtemps que ça serait fait.

          > La preuve que cela fut fait en pensant à Vista ? Les captures d'écran, bien sûr !

          Oui, c'est une "repompe" de vista. Les bonnes idées il faut les prendre partout.
          Mais ce n'est pas une réponse à vista. Ce n'est pas "mon Dieu, Vista a un truc cool, vite vite il faut faire la même chose sinon on va passer pour des cons".

          KDE 4 supporte SVG, ce n'est pas une réponse à Gnome.
          • [^] # Re: Réponse de Qt ?

            Posté par . Évalué à 3.

            Toi, tu te fous bien de ma gueule en jouant sur les mots :
            Oui, c'est une "repompe" de vista. Les bonnes idées il faut les prendre partout.
            Mais ce n'est pas une réponse à vista. Ce n'est pas "mon Dieu, Vista a un truc cool, vite vite il faut faire la même chose sinon on va passer pour des cons".

            Alors que j'avais écrit :
            Non, Gtk+ a voulu répondre à Vista, mais proprement, en sortant un truc bien conçu quand il est prêt plutôt que de se précipite à sortir la fonctionnalité ActiveX pour finalement s'interroger sur la sécurité du bidule.

            L'emphase est de moi. Ton repompe est plus que voisin de mon répond...

            Alors oui, le développement de Gtk+ n'est pas un enfantillage, une réponse puérile comme je ne l'avais pas décrit, mais une attention portée à l'évolution technologique en général. Simplement, Windows étant ultra-majoritaire, il est souvent pris comme étalon. La preuve par les captures d'écran, et par le fait que Mac OS X dans les parages, ça a beaucoup moins fait bouger les choses que Vista dans les parages (souviens-toi du type de XGL qui jetait l'éponge, de l'apparition de Compiz, du support de Novell, de Mark Shuttleworth annonçant sans arrêt la 3D pour la prochaine version d'Ubuntu, etc. Te souviens-tu d'un tel raffut pour virer Xfree86 et vite le remplacer par le plus évolutif X.org en 2001-2002 ?).
    • [^] # Re: Réponse de Qt ?

      Posté par . Évalué à 1.

      Salut,

      Justement, il faut une nouvelle version de Qt ! Techniquement, on peut compiler murrine pour quasiment toute les version de Gtk+ 2. On devrait même être capable de le porter sur Gtk 1.

      De plus, gtk-engine-murrine apporte cette fonctionnalité de manière totalement transparente ? Qu'en est-il pour Qt ?

      Étienne.
      • [^] # Re: Réponse de Qt ?

        Posté par . Évalué à 2.

        Dans Gtk ça m'étonnerait que tu puisses faire ce que tu veux sur chaque widget (rotations, transformations 3D...)
        Pour Qt, c'est juste un thème à écrire actuellement (qui sera compatible avec tout Qt 4, et faut un deuxième code pour Qt 3 par contre), et avec Qt 4.4 les applis auront encore plus de libertés avec les widgets. C'est tout.
      • [^] # Re: Réponse de Qt ?

        Posté par . Évalué à 1.

        Je viens de me rendre compte que tu n'as pas lu les liens que tu donnes. Ou plutôt tu as lu et retenu ce que tu voulais y lire et y retenir.
        Actuellement, ça ne marche pas sans une modification du côté de l'appli !
        The application must set an rgba colormap (for example for the main window).
        This will take 2 lines of code per widget (depending on the programming language).


        http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-(...)

        Ça devient immédiatement moins intéressant et moins transparent non ?
        Dans Qt, l'ARGB est pas activé par défaut non plus. Y'avait un patch dans le qt-copy qui l'activait, mais vu les merdes que ça causait (coucou pilote nvidia notamment), il ne l'est plus. Peut être que bientôt ça sera par défaut dans Qt, vu que les devs de nVidia sont au courant du problème et l'ont réglé ou vont le régler dans la prochaine version du pilote...


        Bref, merci pour le troll.
  • # Canular ?

    Posté par . Évalué à 2.

    Ça s'apparente un peu à de la rumeur, cette histoire : un truc garanti hyper-simple, très peu de ligne de code, etc... Et rien de publié si ce n'est des captures d'écran.

    J'ai loupé un épisode ou c'est un canular ?

    http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-(...)
    • [^] # Re: Canular ?

      Posté par . Évalué à 7.

      ben voyant la qualité du boulot sur murrine, sachant que le moteur de thème a été entièrement reconstruit sur cairo, pour m'a part j'y crois, ce type bosse vraiment très bien, et je suis prêt a tout. Par contre, je me demande comment il fait pour ne pas s'étouffer dans son égo :) (enfin je sais pas ce qu'il en est aujourd'hui mais il était très méprisant sur les forum qui discutaient de murrine, vers l'époque de sa sortie).
  • # C'est beau

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

    Mais je ne sais pas pour vous mais moi, la transparence partout, cela me fatigue les yeux... C'est bien pour les pub et les affiches mais de la à en mettre plein mon bureau.

    D'ailleurs, je travaille sous wmii comme cela mes fenêtres sont minimalistes et pas du tout eyes-candy mais tout cela s'avère dans le boulot très efficasse.
  • # Do it with Style !

    Posté par . Évalué à 0.

    Un petit article sympa ou on nous montre des démos de widgets gtk animés avec de l'openGL :

    http://macslow.thepimp.net/?p=150
  • # .

    Posté par . Évalué à 10.

    "À quand un fondu + déplacement à la suppression d'une ligne d'un TreeView ?"
    Tu veux dire, comme ce que fait Kopete lorsqu'un contact se (dé)connecte ?

    Ce n'est pas pour dire "Qt c'est mieux parce qu'il le fait déjà" mais pour être sûr de bien comprendre ce dont tu parles...
    • [^] # Re: .

      Posté par . Évalué à 3.

      Voilà, sauf que ça doit être totalement générique voir à la charge du thème/moteur de rendu. Je vais pas m'amuser à animer tout les treeview de mon appli !

      Cordialement,
      • [^] # Re: .

        Posté par . Évalué à 2.

        Bien sûr que non, il est hors de question de coder soi-même l'anim'...
        D'ailleurs, qu'en est-il de cette anim' dans Kopete ? Car je ne l'ai jamais vue dans un autre soft KDE.

        Je ne dis pas qu'il faut la placer de partout... Je me demandais juste si les dévs. de Kopete l'ont codé eux-même ou s'ils se servent d'une fonction proposée par Qt, mais que personne d'autre n'a daigné utiliser ?
        • [^] # Re: .

          Posté par . Évalué à 2.

          Je suppose qu'ils ont mimé le comportement d'AdiumX :) ils ont dû le faire eux-même.

Suivre le flux des commentaires

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