rahalala

• [^]Re: rahalala

  Posté par Pinaraf (Jabber id, ) le 06/12/2006 à 19:35. (lien). Évalué à 2.

  Malheureusement compiz n'en avait, aux dernières nouvelles, guère plus (de vision à long terme, je précise).
  Est-ce-qu'une API et si possible une ABI des plugins est stabilisée ? Non.
  Donc sur le long terme ça risque de devenir difficile, sauf si ils font comme le noyau linux, c'est à dire maintenir tous les plugins avec compiz, ce qui peut être très difficile.

  • [^]Re: rahalala

    Posté par gnumdk (page perso, ) le 06/12/2006 à 21:50. (lien). Évalué à 1.

    >Est-ce-qu'une API et si possible une ABI des plugins est stabilisée ?
    
    >Donc sur le long terme ça risque de devenir difficile, sauf si ils font comme
    >le noyau linux, c'est à dire maintenir tous les plugins avec compiz, ce qui
    >peut être très difficile.
    
    Ben, pour le moment, c'est comme ca que ca se passe...
    David s'occupe des plugins de base.
    Et le gens qui traine sur go-compiz.org du reste.
    
    Quand je parlais de vision à long terme, je parlais de qualité du code et de l'architecture, cette vision la David l'a, quitte à devoir casser l'API si il se rend compte qu'on peu mieux faire.
    
    Chez Beryl, ils cassent tout mais pour faire pire...

    --
    Agogo

    • [^]Re: rahalala

      Posté par iXce () le 07/12/2006 à 16:46. (lien). Évalué à 5.

      Ta vision des choses est peut être faussée aussi. Ou peut-être n'as tu pas suivi l'évolution jour par jour depuis février de compiz/compiz-quinn/beryl.
      Montre moi un bout de code de beryl qui soit aussi sale que tu le dis, ou un composant cassé? Je comprends toutefois que tu n'aimes pas du tout les gens de Beryl et que ce serait leur faire trop de bien que de pointer ces fameuses portions de code à retravailler si souvent invoquées.
      
      Et pour les gens de go-compiz.org (dont tu fais partie) qui, comme tu l'as dit il y a peu de temps, "récupèrent les bonnes idées de Beryl" (lire : portent les plugins en s'en attribuant les crédits par omission du nom de l'auteur effectif, codent la même chose mais en différent), je ne sais si leur vision des choses est bien meilleure que celle des membres de Beryl. Prenons par exemple le choix de se séparer du plugin gconf, et d'utiliser à la place une interface commune (un seul plugin au niveau de beryl), pour pouvoir développer des applications de configuration ne dépendant pas de l'environnement et se moquant de savoir si en réalité gconf kconfig ou un malheureux ini est derrière pour sauvegarder : est-ce réellement un si mauvais choix? Inclure une méthode de rendu alternative, moins performante (mais utilisée par le projet Looking Glass), afin de supporter une plus vaste gamme de cartes et de puces que celles fournissant l'extension texture_from_pixmap, est-ce vraiment si ridicule?
      
      S'il faut admettre que les temps de compiz-quinn ont été fort "sales" au niveau de la manière de faire les choses (gestion de l'intégration des patchs, directions du développement), l'officialisation de la branche (le renommage de compiz-quinn en beryl, branche qui résultait d'un fork innoficiel ayant eu lieu en avril ou mai) avait pour but d'améliorer l'état des choses et de mieux organiser le tout. Au final, les devs bénévoles de Beryl ont eu le droit à une levée de bouclier de personnes qui plébicitaient depuis des mois compiz-quinn, déclanchant une avalanche de critiques gratuites et erronées, sur un code et des solutions soit-disant mauvaises (par exemple, l'intégration de Xinerama dans beryl semblerait avoir été très sale, même si elle a rendu service à beaucoup de monde pendant des mois avant qu'une solution similaire (en terme de code pour la gestion du Xinerama - je concède que la solution finale est meilleure, permettant de ne redessiner qu'une partie des périphériques) n'arrive sur compiz).
      
      Juste, un dernier truc, Quinn est une femme, et le fork a été déclanché par une équipe, pas par elle seule. Et le fork a permis en grande partie de réveiller le Dieu David, qui semblait avoit quelque peu oublié son bébé, le rendant ouvert aux patchs et actif sur la mailing list (dont beryl n'a jamais été viré, non, les gens de Novell étaient trop occupés par SLED comme il a été précisé à l'époque du fork).
      
      Au plaisir.

      • [^]Re: rahalala

        Posté par gnumdk (page perso, ) le 07/12/2006 à 18:30. (lien). Évalué à 2.

        Je comprends toutefois que tu n'aimes pas du tout les gens de Beryl et que ce serait leur faire trop de bien que de pointer ces fameuses portions de code à retravailler si souvent invoquées.

        
        
        Pour le plugin snow? Il a été dit qu'il y'avait des trucs à revoir et d'ailleur l'auteur vient de demander un conseil sur la ml compiz. J'ai envoyé des patchs au début pour beryl afin de corriger des incohérences dans le code.
        
        

        Prenons par exemple le choix de se séparer du plugin gconf, et d'utiliser à la place une interface commune (un seul plugin au niveau de beryl), pour pouvoir développer des applications de configuration ne dépendant pas de l'environnement et se moquant de savoir si en réalité gconf kconfig ou un malheureux ini est derrière pour sauvegarder : est-ce réellement un si mauvais choix?

        
        
        Le mauvais choix n'est pas d'avoir viré gconf, franchement, je suis pas un grand fan de gconf, loin de la!!! :) Et j'étais vraiment pas contre quand quinn a lancé l'idée d'un gestionnaire de conf alternatif.
        
        Seul probleme, faire ca proprement. En clair, faire un plugin beryl (qui accessoirement aurait aussi pu servir à compiz). Au lieu de ca, Quinn a cassé le principe de fonctionnement de beryl/compiz en intégrant directement la conf dans beryl. Resultat, aujourd'hui IL recode un backend gconf pour libberylsettings... Si tu trouves ca logique et propre, pas moi...
        
        

        portent les plugins en s'en attribuant les crédits par omission du nom de l'auteur effectif, codent la même chose mais en différent

        
        
        Faux et archi faux... Petit exemple avec le plugin state:
        /*
        * state plugin for beryl
        *
        * Copyright (C) 2006 John Wall <wall_john@sohu.com> (http://wall_john.blogeden.cn)
        
        Les plugins extra de compiz viennent tous de beryl (sauf 1 fait par mikedee). Par contre, on ne parlera pas des fonctionnalités inclu dernierement dans beryl et qui viennent tout droit des modifs de David ;) Je n'ai rien vu au sujet de compiz dans les annonces ;)
        
        Après pour le Xinerama, izoom & co, c'est un choix des devs, mais rien de génant.
        
        >Juste, un dernier truc, Quinn est une femme
        http://www.lulu.tv/?p=4346
        
        Je sais pas d'ou sort cette légende comme quoi Quinn est une femme, elle est bien barbu ta femme :p
        
        Mais ne te trompe pas, je pense que les gens qui bossent sur compiz n'ont absolument rien contre les devs de beryl. Des gens comme onestone font vraiment du bon boulot et proprement, le decorateur kde en est un bon exemple.
        
        Il y'a juste chiant de voir le coeur de beryl devenir de plus en plus incompatible avec compiz pour des raisons somme toute non valables.

        --
        Agogo

        • [^]Re: rahalala

          Posté par iXce () le 07/12/2006 à 19:01. (lien). Évalué à 3.

          Le développeur du plugin snow ne fait absolument pas partie de l'équipe de Beryl, a commencé à s'y intéresser il y a quelques jours, et ne fait que tatonner (il l'avoue lui même). Il a posté sur la mailing list de Compiz comme on lui a dit de le faire en Mauvais exemple donc.
          Si tes patchs n'ont pas été intégrés, je me ferai un plaisir de les examiner.
          
          Ils codent _des_ backends gconf et kconfig (cf. les commits de onestone de ces deux derniers jours pour ce dernier), pour être intégrés à chacun des Desktop Environment, pour utiliser les utilitaires déjà existants dans Gnome ou KDE. La solution permet de ne pas avoir à agir au niveau de beryl (un seul plugin settings qui interagit avec la librairie, qui elle s'occupe du choix du backend/de la réplication des options lors d'un changement de backend...) et pour simplifier la maintenance du plugin settings. Le tout en ne gardant comme dépendance gnome-related que la glib.
          
          Pour les plugins portés, dans les sujets sur go-compiz, le nom de l'auteur originel n'est absolument pas précisé, et je voudrai bien savoir combien d'utilisateurs ouvrent jamais un fichier source. Pour les commits du côté de Beryl, (David Reveman) est précisé à la fin de chaque message de commit concerné. Ce que les gens font sur le blog (je suppose que tu parles du Drag&Drop sur le dernier billet, moi aussi j'ai bondi au plafond quand j'ai lu ça, je ferais rectifier dans les meilleurs délais...) et autre n'a rien à voir.
          
          Quinn est une transexuelle sans le sous, donc physiquement masculine. Ma légende, je la sors d'elle-même (si je puis dire), demande-le à n'importe quel observateur de compiz-quinn/beryl pour vérifier.
          
          Ce serait dur de critiquer onestone et/ou cornelius, en effet, ça ferait très mauvais genre. Les gens qui bossent sur go-compiz font preuve d'une certaine animosité envers les gens de beryl, c'est net (pourquoi avoir été publier le lien et le mot de passe pour une interview de l'équipe de beryl, puis y rajouter son grain de sel, pourquoi sans cesse débattre de pourquoi-beryl-saymal? - je ne vois rien de tel sur le forum Beryl en tout cas)
          
          Les deux projets sont désormais distincts. Compiz !== Beryl, tous les fans de Compiz s'évertuent à le démontrer au quotidien. Dans ce sens, pourquoi se plaindre que les cores deviennent incompatibles? Si ce n'est pour le plaisir de critiquer?

          • [^]Re: rahalala

            Posté par gnumdk (page perso, ) le 07/12/2006 à 19:40. (lien). Évalué à 2.

            >Ils codent _des_ backends gconf et kconfig
            
            Oui, mais des backends pour libberylsettings alors qu'il devrait juste à avoir à coder un plugin kconfig si il avait suivit la logique de l'architecture de compiz (vu qu'ils auraient deja un plugin berylsettings fonctionnel et le plugins compiz pour gconf).
            
            En clair, tant que je verais pas un plugins(au sens compiz) gconf, kconfig, berylsettings, tu ne me feras pas croire que c'est propre...
            
            Dernierement, mikedee (le monsieur qui en veut beaucoup aux devs beryl) avait pour idée d'ajouter une gestion de filtrage suivant le type de fenetre dans le coeur de compiz. Apres reflexion, je pense que c'est une connerie, au meme titre que de mettre un gestionnaire de configuration dans le coeur de beryl ;) Compiz doit rester un "gestionnaire de composition", rien d'autre!
            
            >Pour les plugins portés, dans les sujets sur go-compiz, le nom de l'auteur
            >originel n'est absolument pas précisé
            
            Effectivement, mikedee n'en fait pas mention, je le fera désormais pour mes modifications ;)
            
            >Les deux projets sont désormais distincts. Compiz !== Beryl, tous les fans
            >de Compiz s'évertuent à le démontrer au quotidien. Dans ce sens, pourquoi
            >se plaindre que les cores deviennent incompatibles? Si ce n'est pour le
            >plaisir de critiquer?
            
            Juste pour te rappeler que les gens à l'origine de la division compiz/beryl l'on fait à une époque ou Compiz != Beryl était deja une vérité, malheureusement.
            
            Une autre modif dans beryl qui me semble bizarre, c'est les histoires de groupes dans le code des plugins, j'ai peut etre rien compris, mais à premiere vu il s'agit de créer des groupes de clef de configuration pour chaque plugin. Chose effectivement manquante actuellement dans compiz, mais pourquoi gerer ca au niveau du code source? Pourquoi ne pas utiliser un fichier de description des options à la kde (kcfg) ? J'ai bien ma petite idée car il me semble que beryl-settings-dumps créé un fichier de config en lisant le code source d'un plugin, donc si on veut qu'il gere des groupes, il faut rajouter ca dans le code source... Bref, je trouve ca naze mais j'ai peut etre rien compris ;)

            --
            Agogo

            • [^]Re: rahalala

              Posté par iXce () le 07/12/2006 à 20:21. (lien). Évalué à 2.

              Comme je l'ai dit, les backends au niveau de la lib, c'est pour avoir une interface commune et stable qui marchera toujours pour accéder aux settings de beryl, et n'avoir qu'un seul plugin settings à maintenir au fil des changements du code.
              Beryl est 100% indépendant du backend de settings qu'il a derrière, ce qui permet entre autres de pouvoir deviner la liste des plugins ordonnée & compagnie sans se préoccuper de ce qu'il y a derrière. Les avantages sont donc au final : un seul plugin à maintenir, la certitude de pouvoir parler à la lbbs quel que soit le backend pour accéder aux settings, l'accès en live aux différentes options proposées par les plugins et le core sans passer par des fichiers statiques annexes, les possibilités de réplication d'options... Avoir différents backends dans des plugins beryl empécherait cette réplication (conflits entre les plugins), rendrait difficile la création de configurateurs multi-desktop environment,
              
              Oui, moi aussi je pense que le plugin state doit rester tel qu'il est, pas besoin de surcharger le core avec du code dans ce genre qui n'a rien à voir.
              Il n'y a pas de gestionnaire de configuration dans le core de beryl :/ La libbs est bien un élément externe (je ne sais plus pourquoi elle est compilée en même temps que le core, sans doute pour des raisons purement utilitaires).
              
              Malheureusement oui, tu ne peux pas savoir à quel point j'aurais préféré ne pas voir ce fork. Quoi qu'il se soit passé pour en arriver au fork, quelle qu'ait été l'attitude des acteurs des deux applications, aussi reprochables les uns que les autres, il faut, à mon sens, cesser de regarder vers le passé et au contraire essayer d'établir une meilleure colaboration entre les deux projets, collaboration composée de discussions sur les solutions techniques des problèmes majeurs (je pense en particulier aux problèmes de gestion de la stack interne des fenêtres, qui se désynchronise parfois avec la stack du serveur X).
              
              En effet, les groupes et sous groupes sont là pour ordonner les options dans beryl-settings. beryl-settings-dump a été droppé depuis pas mal de temps pour ne plus avoir à produire ce genre de fichiers, tout est lu directement en live à partir des libs des plugins en elles même, de manière à ne pas créer de problèmes qui seraient liés à des fichiers dépassés, et pour plus de souplesse.

              • [^]Re: rahalala

                Posté par gnumdk (page perso, ) le 07/12/2006 à 20:58. (lien). Évalué à 2.

                Bon, pour commencer, merci au anti-berylistes d'arreter de moinsser le monsieur...
                
                

                
                Beryl est 100% indépendant du backend de settings qu'il a derrière, ce qui permet entre autres de pouvoir deviner la liste des plugins ordonnée & compagnie sans se préoccuper de ce qu'il y a derrière. Les avantages sont donc au final : un seul plugin à maintenir, la certitude de pouvoir parler à la lbbs quel que soit le backend pour accéder aux settings, l'accès en live aux différentes options proposées par les plugins et le core sans passer par des fichiers statiques annexes, les possibilités de réplication d'options..
                

                
                
                J'ai commencé il y'a quelques semaines un plugins kconfig pour compiz (loin d'etre fini, faut que je m'y remette) et tout ce que tu dis est déjà vrai avec l'architecture de compiz.
                
                Il n'y a que si on rajoute un nouveau type d'option (Value, ListValue, ActionValue pour le moment) qu'il faudra modifier le code des plugins de configuration, pour le moment, je ne vois pas ce qu'on pourrait bien rajouter...
                
                Pour la synchronisation multi environnement, un plugin spécialisé chargeant le bon plugin de configuration et synchronizant les différent plugins de configuration ne me semble pas insurmontable à écrire. Et je ne vois pas quel genre de conflit il pourrait y avoir, vu qu'un plugin de conf initialise CompOption et que chaque plugin comprend CompOption, je ne vois pas bien le probleme.
                
                

                Oui, moi aussi je pense que le plugin state doit rester tel qu'il est, pas besoin de surcharger le core avec du code dans ce genre qui n'a rien à voir.

                
                
                Pour l'instant, on pense à différentes bibliotheques (une pour le wm, une pour les effets, ...) ou chaque plugins viendrait se "linker" suivant les besoins. Reste à voir ce qu'en pense David.

                --
                Agogo

                • [^]Re: rahalala

                  Posté par iXce () le 07/12/2006 à 21:04. (lien). Évalué à 1.

                  Faire un tel plugin de sélection/synchronisation des backends revient plus ou moins à faire la libberylsettings :) (le conflit se situerait au niveau des Deps/Features des différents plugins qui pourraient s'avérer bloquantes).
                  
                  Oui, ça serait pas mal, mais faut voir l'implémentation après, vu l'échec actuel de la libcm :/

            [^]Re: rahalala

            Posté par taratatatata () le 08/12/2006 à 04:04. (lien). Évalué à 1.

            Quinn est une transexuelle sans le sous, donc physiquement masculine.
            
            Dans les situations où l'on parle de "technicien de surface" ou d'un "malvoyant" ou encore "d'incivilités" et de "jeunes", j'ai un traducteur politiquement-correct/français qui vient à mon secours. Il me souffle à l'oreillette :
            "Quinn est un homme dérangé."

            • [^]Re: rahalala

              Posté par ploum (page perso, ) le 08/12/2006 à 09:33. (lien). Évalué à 5.

              Autant j'adore les infos croustillantes et les ragots, autant j'ai pas compris en quoi ça venait dans la conversation.
              
              On s'en fout non que ce soit un homme ou une femme ? Je veux dire, tant qu'on a pas envie de le/la draguer ? (et encore, même si on avait envie, on s'en fout, open mind !)
              
              Mais bon, si c'est Quinn lui-même qui expose sa vie dans un blog ou une ML, une âme charitable pour nous pointer vers les "bons morceaux", nous les amateurs de sensationnalisme et de "Entrevue-libre" ? ;-)

              • [^]Re: rahalala

                Posté par iXce () le 08/12/2006 à 12:00. (lien). Évalué à 1.

                Où se situe le problème au juste? gnumdk affirme que Quinn est un homme en s'appuyant sur une vidéo, j'explique en quoi elle est une femme et pourquoi elle n'a pas une allure féminine. Rien de plus simple.

        [^]Re: rahalala

        Posté par taratatatata () le 08/12/2006 à 03:54. (lien). Évalué à 1.

        "
        Montre moi un bout de code de beryl qui soit aussi sale que tu le dis"
        
        Un exemple sur le chaotique développement :
        
        I think that the informal attitude has got us in the state we are today,
        patches applied all over the place without formal documentation. If I
        am correct, the original xinerama changes were made with the
        understanding that they would be removed once David had finished the
        correct changes. Now the argument is that it is too hard to undo those
        changes.
        
        http://lists.freedesktop.org/archives/compiz/2006-October/00(...)
        La réponse d'un pro-beryl est croustillante, car il reconnaît le problème mais en parle comme de rien n'était :
        
        Yes the Xinerama changes are/should be temporary until the "right" way
        has been implemented and yes it probably will be a pain to strip it out
        again, but I'm sure it will get done.
        
        [...]For me, I needed compiz-quinnstorm as I predominantly work in a dual
        head evironment. I'm looking forward to when dual head is done right in
        compiz, but for now I *need* patches to get a working DE and for me a
        branch/fork is better.[...]
        
        Ou encore le plugin de Blur qui est bourré d'artefacts qui ne pourront être corrigés qu'en changeant dramatiquement l'architecture du plugin. Un quick hack qui sert à faire plaisir aux gens qui tiennent à avoir une copie de WIndows Vista.

        • [^]Re: rahalala

          Posté par iXce () le 08/12/2006 à 11:58. (lien). Évalué à 1.

          Tout à fait discutable. 98% des changements pour Xinerama qui avaient étaient faits dans compiz-quinn sont toujours là, et les 2% sont des changements mineurs. L'implémentation originale (au niveau de la gestion en elle même, pas du rendu) est très similaire à ce qui a été fait dans compiz. Les améliorations (principalement le rendu par périphérique) venant de compiz ont été intégrées à Beryl.. une fois qu'elles ont été corrigées dans Compiz (la première version était 100% buggée).
          
          Hm, quel plugin blur? Blurfx? Je ne l'utilise pas du tout, mais je veux bien voir ces artefacts, n'en ayant pas entendu parler pour l'instant.