Fresco, aka "The GUI formerly known as Berlin"

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
21
nov.
2002
Serveurs d’affichage
Berlin, l'interface utilisateur graphique, vient d'atteindre sa borne kilométrique M1. Elle s'appelle désormais Fresco. Berlin est l'une des alternatives (futures) à XWindow. Elle est développée par un très petit nombre de personne, ce qui explique un peu le coté "pas mort mais presque" que le projet a affiché cette année. Fresco revendique une gestion innée de la transparence et des transformations géométriques, ainsi qu'une charge moins lourde pour le réseau.
PS: Je sais, j'ai mis "X" pour thème, mais je espère que les puristes ne m'en voudront pas trop ;)

Aller plus loin

  • # Re: Fresco, aka

    Posté par  (site web personnel) . Évalué à 10.

    Le problème (et l'intérêt...) de Berlin, c'est qu'il a son propre toolkit graphique. C'est bien dans un sens (plus grande homogénéité de la GUI...), de l'autre ce n'est pas ça qui va faciliter les portages KDE/Gnome/GNUstep dessus ... (enfin, on peut y aller "bourrin", mais un portage "propre" qui utiliserait les widgets natifs ne serait pas évident.)

    Je crains un peu l'utilisation de Corba tout azimut, mais bon là c'est ptet moi qui suis trop méfiant :)

    Sinon le projet est intéressant, même s'il avance tout doucement.

    • [^] # Re: Fresco, aka

      Posté par  (site web personnel) . Évalué à 0.

      Je crains un peu l'utilisation de Corba tout azimut, mais bon là c'est ptet moi qui suis trop méfiant :)
      Bin le résultat, c'est quand même que ça bouffe plus de BP que X, au lieu d'en économiser.

      • [^] # Re: Fresco, aka

        Posté par  . Évalué à 1.

        Corba ce n'est peut être que en local, les ordres transmient sur le réseau
        doivent être plus courts.

        • [^] # Re: Fresco, aka

          Posté par  (site web personnel) . Évalué à 4.

          Mouaif enfin si on utilise pas la transparence réseau de Corba, l'intérêt est de plus en plus mince ....

          • [^] # Re: Fresco, aka

            Posté par  . Évalué à 2.

            J'ai peut être mal compris mais CORBA c'est pour permettre à n'importe qu'elle
            langage de piloter l'interface, sur le réseau CORBA permet de faire transiter des
            'objets'. Fresko n'enverra sur le réseau que des ordres du type : "dessine un
            rectangle en (X,Y,W,H)." ?

            • [^] # Re: Fresco, aka

              Posté par  (site web personnel) . Évalué à 7.

              ??

              Non Corba ça te permet d'avoir des objets distribués. C'est à dire que tu as des objets qui peuvent être sur le réseau (une autre machine par exemple), que tu appelle de façon transparente (tu n'as même pas à indiquer le nom de la machine sur laquelle tu va chercher l'objet, Corba se démerde avec le nom de l'objet). Du coup, quand tu envoie des messages à ces objets, ces messages transitent par le réseau (dans le cas ou l'objet est sur une autre machine, ici un affichage déporté par exemple).

              Le problème d'X11 c'est que les ordres de dessins sont plutôt bas niveau, alors qu'à priori Fresco est plus haut niveau et fonctionne au niveau des widgets.

              Si c'est le cas, on imagine que la charge réseau peut effectivement être (de beaucoup) plus réduite. Exemple : Terminal Server de microsoft (ou rdesktop) marche plutôt pas mal en réseau, entre autre parce que les commandes envoyées sur le réseau sont plus haut niveau, donc moins nombreuses. Alors que X11 sur un modem, c'est pas évident, on va dire :)

              • [^] # Re: Fresco, aka

                Posté par  (site web personnel) . Évalué à 8.

                Précisions :

                Corba te permet de créer des objets (au sens de la POO), à partir d'à peu près n'importe quel langage, de pouvoir les faire intéragir ensemble¹, d'utiliser des architectures matérielles différentes (petit-boutiens et grand-boutiens). Ces objets sont disponibles sur un "bus objet", et un client peut demander un objet sans savoir ou s'exécute réellement cet objet.

                Bref, du bel ouvrage... bien documenté, normalisé, avec pas mal d'implémentations existantes.
                Mais une vraie usine à gaz également. D'autant qu'il est rare que l'on ait besoin de tous les avantages/fonctionnalitées de Corba. Personnellement, j'ai une (grosse) préférence pour les objets distribuées GNUstep² . Mais à chaque problème son outil hein.

                Concernant Fresco, ils disent qu'ils utilisent toutes les fonctions de Corba et que donc c'est pas du bloat. Si la charge réseau est moins importante que pour X (ce qui est tout à fait possible), c'est surtout grâce à une conception plus haut niveau que X11, plutôt que grâce à Corba...


                ¹ genre, je crée un objet en Ada, je le dérive dans une sous-classe qui elle est en C, pour finir par une sous-sous classe en C++.

                ² on va encore dire que je suis partial... mais jettez un oeil sur ce tutorial : http://www.gnustep.it/nicola/Tutorials/DistributedObjects/index.htm(...)
                obtenir un objet distribué simplement en modifiant son initialisation, ben... c'est quand même cool :)

                • [^] # Re: Fresco, aka

                  Posté par  . Évalué à 3.

                  À ce propos, je me demande depuis longtemps s'il ne serait pas possible de (seulement) développer des extensions au protocole X permettant de diminuer la BP de cette manière.

                  Par exemple, une extension XGTK qui permettrait de n'envoyer que les ordres de création d'un bouton, puis seulement les ordres d'appui et relâchement de bouton. Les libgtk côté client (côté application quoi) ne feraient qu'envoyer des requêtes XGTK (comme libX11) alors que tout le code qui se trouve actuellement dans les libgtk se retrouverait dans le serveur X (ou plus exactement dans son extension XGTK).

                  De plus, pour une utilisation distribuée (avec un serveur d'applications X et des terminaux X un peu partout), je pense que ça serait plus performant : pour l'instant, le serveur d'applis X est très chargé et le terminal X ne fait que des choses toutes cons (dessiner un point, une ligne, etc), alors que les terminaux X ont aujourd'hui de plus en plus de puissance de calcul.

                  Après tout, c'est cette méthode qui est utilisée pour la 3D avec le DRI, non ?

                  Quelqu'un sait-il s'il existe des discussions, des bouts d'essais de code ou autre chose sur ce sujet, car c'est un projet qui me tiendrait vraiment à coeur.

                  Pour ceux qui préfèrent : sed s/GTK/Qt/g

                  • [^] # Re: Fresco, aka

                    Posté par  . Évalué à 1.

                    J'ai aussi eu la même idée, sans jamais avoir eu le courage/temps d'implémenter quoi que ce soit.
                    L'avantage de la méthode sur la méthode type Berlin, c'est qu'elle minimise les changements, et a plus de chances d'être utilisée.
                    Au fait, pourquoi intégrer le "serveur gtk" au serveur X ? Ca pourrait bien être deux applications différentes. Ca permettrait même d'imaginer différents serveur gtk tournant au dessus de différents serveur graphiques (X, framebuffer, win32...).

                    • [^] # Re: Fresco, aka

                      Posté par  . Évalué à 1.

                      J'ai aussi eu la même idée, sans jamais avoir eu le courage/temps d'implémenter quoi que ce soit.

                      On doit être un paquet à l'avoir eue :)

                      Plus sérieusement, j'avais d'autres idées débiles impliquant la libglade (Un logiciel client "interprete" ma description d'interface, en faisant "redirigant" les appels de fonctions/méthodes à un serveur.)

                      Heureusement que j'ai pas eu le courage tiens ;)

                  • [^] # Re: Fresco, aka

                    Posté par  (site web personnel) . Évalué à 1.

                    Ca s'appellerait pas QtFB ton truc? Comme sous Zaurus?

                • [^] # Re: Fresco, aka

                  Posté par  (site web personnel) . Évalué à 3.

                  Juste une petite précision : les objets de corba ne sont pas directement comparable aux objets de la POO. En fait, un objet corba est décrit par une interface en IDL qui est très proche d'une interface Java ou d'une classe virtuelle pure C++. Par contre, du point de vue conceptuel, cette interface décrit un service qui peut être implanté n'importe comment (par exemple en C). La différence a des conséquences assez subtile. Par exemple quand on lit la norme, on voit apparaître des objets persistants. Or, ce ne sont pas des objets persistants au sens classique : il s'agit seulement d'un service persistant. En gros quand tu récupères une référence vers l'objet en question, corba te garantit que tu peux toujours accéder au service. Par contre, il peut être réalisé à un moment par un objet C++ puis à un autre par un autre objet C++. Bref, on est assez loin du modèle RMI par exemple. Pub : mon cours sur corba http://apiacoa.org/teaching/distributed/

              • [^] # Re: Fresco, aka

                Posté par  . Évalué à -1.

                Ok, donc Fresco semblerait très bien, en tout cas mieux que X.

      • [^] # Fresco vs X

        Posté par  . Évalué à 9.

        Apparemment, non.

        http://wiki.fresco.org/index.cgi/FrescoVsX(...)

        Extrait :

        "Like the X Window System, Fresco provides network transparency. The difference is that Fresco uses CORBA for network transparency while X Window System uses the X Protocol which is much lower level. So where Fresco transmits the creation request for a button and click events on that button, X transmits the look of the button each time it gets moved/redisplayed after being obscured by another window plus all events that happen inside the window the button is displayed in.

        [...]

        So while IIOP may have more overhead, the overlying Fresco communications will be much terser than corresponding communications under the X Protocol."

        • [^] # Re: Fresco vs X

          Posté par  . Évalué à 1.

          Il sera donc utilisé en local et réseau :)
          Mais d'après l'explication on peut penser que les ordres envoyés sont de
          moindres importances que X.

        • [^] # Re: Fresco vs X

          Posté par  . Évalué à 2.

          Donc ca bouffe moins de réseau à condition que le bidule sache comment dessiner les composants coté client. Uniquement pour les objets du toolkit fournit avec Fresco si je comprends bien.
          La page dessinée par Mozilla par exemple devra toujours transiter tel quellle...

          • [^] # Re: Fresco vs X

            Posté par  (site web personnel) . Évalué à 1.

            Oui, sauf si tu considère que ta page de mozilla n'est pas un bête bimap généré par le navigateur, mais au contraire un ensemble d'objets instanciés permettant l'affichage... dans ce cas, le client pourra aussi savoir comment redessiner le bidule.

            • [^] # Re: Fresco vs X

              Posté par  . Évalué à 3.

              Sauf que la page de mozilla est un bête pixmap généré par le navigateur.

              Beaucoup d'applis fonctionnent sur ce principe, malheureusement... (et ça aide pas le protocole X à passer pour efficace)

              • [^] # Re: Fresco vs X

                Posté par  (site web personnel) . Évalué à 1.

                Oui c'est sûr ... je parlais en tant qu'hypothèse hein :-P pour un éventuel et fort hypothétique futur navigateur natif Fresco.
                Pour X, c'est clairement un des problèmes.

                • [^] # Re: Fresco vs X

                  Posté par  (site web personnel) . Évalué à 0.

                  Vu qu'il n'existe pas de navigateur correct qui tire profit de X autrement qu'en allouant un gros pixmap (histoire qu'on puisse dire que c'est la faute de X si ça rame), on peut l'attendre longtemps, le navigateur Frisco à la menthe.

      • [^] # Re: Fresco, aka

        Posté par  . Évalué à 0.


        Bin le résultat, c'est quand même que ça bouffe plus de BP que X, au lieu d'en économiser.

        Pourquoi ce bouffrait plus de BP que X, tu tiens ces infos d'ou ? Enfin Corba ca me parait plus moderne comme techno.

        • [^] # Re: Fresco, aka

          Posté par  (site web personnel) . Évalué à -1.

          C'est marqué quelque part sur leur site, flemme de chercher.

          • [^] # Re: Fresco, aka

            Posté par  . Évalué à 3.

            Je ne pense pas que ce soit formulé ainsi. Il est *nécessaire* sur ce sujet d'avoir bien lu et assimilé http://wiki.fresco.org/index.cgi/FrescoVsX(...) . Je suis sûr que les gens de #fresco (@freenode) seront absolument ravis de recevoir un petit Np237 pour discuter avec toi et répondre à tes questions.

            Je pense vraiment que c'est un argument n'en est pas un vrai. S'il est vrai qu'on peut préférer d'autres choix de design, le rejeter au nom de la BP purement et simplement est bête, et pas fondé. On ne peut pas reprocher au projet Fresco de ne pas avoir pensé à tous ces problèmes, de faire dans le vide, sans réfléchir. Il y'a un réel design dans le projet, des réels choix faits, qui se justifient et sont fondés en raison. Fresco est vraiment très intéressant à étudier, et si je ne me prononce pas quant à lui maintenant, c'est simplement parce que même en suivant le projet depuis longtemps, je ne pense pas avoir les connaissances nécessaires pour savoir s'il pourrait s'adapter et développer un un WS plus komjeve[tm], décrit sur http://linuxfr.org/comments/150869.html(...)

            J'espère qu'en gars intelligent, tu essayeras aussi de te renseigner en profondeur.

            • [^] # Re: Fresco, aka

              Posté par  (site web personnel) . Évalué à 3.

              Je me suis déjà renseigné sur Berlin, et en l'état, ça ne me convainc pas du tout.

              En particulier, je trouve que le tout vectoriel, c'est stupide. Les écrans ont des pas de masque de 0,25 mm, pas de 10 µ. Le jour où ils auront la résolution des imprimantes, ça voudra peut-être le coup. En plus, redimensionner des bitmaps, s'ils ne sont pas de très bonne qualité derrière, c'est très moche.

              Ensuite, il y a de bonnes idées dans leur modèle client-serveur, mais au final ça risque d'être moins souple que X, avec comme seul gain potentiel une BP réduite. En voyant les premiers tests qui montraient que la consommation en BP était plus grande que celle de X, ils auraient du arrêter tout de suite.

              À côté de ça, XFree commence à développer les extensions qui lui manquent pour faire du vectoriel (à commencer par RandR), et si ça continue sur le bon chemin, XFree aura toutes ces fonctionnalités bien avant que Fresco ne soit fini, et sans être pénalisé au niveau des bitmaps.

              • [^] # Re: Fresco, aka

                Posté par  . Évalué à 1.

                Pour ce qui est de la résolution: un écran LCD de 22.2" vendu par Viewsonic a une resolution de 200 dpi: resolution 3840x2400.

                Evidemment il coute $8,000, mais 200 dpi, ce n'est pas tres eloigné de la résolution des imprimantes.

                L'idée derriere le vectoriel, c'est surtout que ce qui apparaisse a l'écran soit indépendant de la résolution, ce qui me parait plutot une bonne idée..

                • [^] # Re: Fresco, aka

                  Posté par  . Évalué à 1.

                  Evidemment il coute $8,000, mais 200 dpi, ce n'est pas tres eloigné de la résolution des imprimantes. Une imprimante bas de gamme, c'est minimum 600 ou 1200dpi. L'idée derriere le vectoriel, c'est surtout que ce qui apparaisse a l'écran soit indépendant de la résolution, ce qui me parait plutot une bonne idée.. Oui mais le problème c'est la qualité du rendu. Voir tous les problèmes avec le rendu des fontes (kerning, anti-aliasing, etc.). D'ailleurs sur les screenshots Fresco, les textes sont affreux.

              • [^] # BP seulement pourquoi ?

                Posté par  . Évalué à 1.

                Bon j'ai pas compris cette histoire de BP, pourquoi Fresco bouffrait plus de BP que X ? A la limite un peu plus de latence pour traverser Corba je concois, mais plus de BP je vois pas pourquoi.

                Ca me parait aussi un peu bete de tout ramener a la BP. Merci de m'eclairer.

                • [^] # Re: BP seulement pourquoi ?

                  Posté par  . Évalué à 1.

                  Bah, je pense qu'il a lu XvsBerlin en diagonale et n'a pas compris.

                  Et pour ce qui est de la latence, au contraire elle est censé être amméliorée pour certaines partie: quand tu clique sur un menu, pas besoin d'appeller le client, c'est le serveur qui se débrouille tout seul pour faire apparaitre le menu, pareil pour déplacer des fenetres,etc..

              • [^] # Re: Fresco, aka

                Posté par  (site web personnel) . Évalué à 0.

                Si tu fais une analogie avec une imprimante, il faut aller jusqu'au boût. Actuellement, une imprimante utilise 6 encres au maximum, avec des tailles de gouttes variables. A la louche, il doit y avoir quelque chose comme 50 couleurs de gouttes possibles, disons 64 pour simplifier les calculs. Pour simuler 16 millions de couleurs avec ça, tu dois tramer et donc utiliser pas mal de gouttes. Comme les meilleurs humains reconnaissent quelque chose comme 15000 couleurs (disons 2^14 pour simplifier), tu dois utiliser environ 2^8 gouttes pour simuler tout ça, c'est-à-dire un petit carré de 16x16. Donc, le dpi réel des imprimantes est de l'ordre de 100 c'est-à-dire comparable à celui des écrans...

                • [^] # Re: Fresco, aka

                  Posté par  . Évalué à 1.

                  Hum, ton raisonnement ne tient pas en noir & blanc, où les "dpi" de l'imprimante se ressentent à fond.

  • # Re: Fresco, heu c'était pas déjà Fresco avant ?

    Posté par  . Évalué à 1.

    J'ai un doute mais il me semble que le projet s'appelait Fresco à l'origine, non ?
    Fresco -> Berlin -> Freco
    Un coup de pub ?

    • [^] # Re: Fresco, heu c'était pas déjà Fresco avant ?

      Posté par  (site web personnel) . Évalué à 1.

      Aucune idée ... en tout cas ça fait super longtemps que ça s'appelle Berlin (5 ans ? 6 ans ?), du moins autant que je m'en souvienne.

    • [^] # Re: Fresco, heu c'était pas déjà Fresco avant ?

      Posté par  . Évalué à 1.

      Oui, il y a un peu de ça, mais le sens de la dépêche n'est pas de souligner le changement de nom, mais le fait que il y a du vrai nouveau avec la "Milestone 1".
      Berlin était le nom d'une partie du projet. Il y avait aussi Varsaw (Varsovie) et une troisième ville (Moscou?) comme autres projets.

    • [^] # Re: Fresco, heu c'était pas déjà Fresco avant ?

      Posté par  . Évalué à 1.

      Frezco n'est pas tout à fait l'ancien nom de Berlin. C'est un autre projet, mort depuis il me semble, une sorte d'avant projet qui a donné naissance à Berlin.

    • [^] # Re: Fresco, heu c'était pas déjà Fresco avant ?

      Posté par  . Évalué à 10.

      Une tentative d'explication simple: as-tu essayé de trainer sur #berlin (OpenProjects à l'époque) une journée ou deux ? Le nombre de personnes confondant avec la ville de Berlin, demandant le rapport avec Berlin, critiquant le nom pour l'ambiguïté qu'il apporte était assez hallucinant, alors même que chaque utilisateur se faisait informer par ChanServ que ce channel était à propos du projet Berlin, et non de la ville de Berlin. Et à ma connaissance, les développeurs de Berlin en avaient _vraiment_ _vraiment_ marre, et on les comprend :-) Et puis, Fresco était un nom sympa.

      Mais Fresco n'était pas l'ancien nom de Berlin. Fresco était un système dont a hérité Berlin.

      Bon, pour ma part, si je trouve Berlin assez intéressant, il ne représente pas un idéal concernant le système de fenêtrage: je suis pour un nouveau WS tirant réellement partie d'une transparence réseau et d'IPC fournie par le système, ainsi qu'au niveau des drivers, une possibilité de gérer plus efficacement et de façon plus propre, quitte à sacrifier la portabilité - je souhaite avant tout avoir quelque chose fait correctement, de façon optimale, où la portabilité ne représente pas une contrainte limitant la qualité de la production, mais un plus si possible. De nombreuses recherches ont été faites là-dessus (on pense notamment à Nemesis[1], ou à Halo[2] et le système Angel[3], qui sont tous deux des systèmes très intéressants, bien que SAS), ou bien sûr au système de fenêtrage de QNX, qui reste cependant très primitif, et dont on ne sait que très peu de choses :-(

      [1]: http://nemesis.sourceforge.net(...)
      [2]: http://citeseer.nj.nec.com/81555.html(...)
      [3]: http://citeseer.nj.nec.com/wilkinson92angel.html(...)

  • # Re: Fresco, aka

    Posté par  (site web personnel) . Évalué à 10.

    Apparemment un (*) de leur but c'est "d'uniformiser" le look des applis. Bien bien. Certes ce but est louable - d'un certain point de vue - mais je doute que le problème soit d'ordre technique. D'un point de vue théorique, tout le monde aurait pu se limiter à motif (ou lesstif pour rester libre) pour développer des applis sous X. Dans la pratique, chacun veut "le petit truc en plus qui va bien" et du coup les toolkits et APIs explosent, et la diversité des interfaces graphique suit logiquement le mouvement.

    Imposer l'uniformisation par un moyen technique me paraît plus que douteux. C'est la technique Apple ou Microsoft -> "notre API permet ceci, contentez-en vous". X a justement une approche inverse où on te laisse choisir ton window manager pour ta session, et chaque appli choisit son toolkit. Evidemment, la diversité ça fait désordre. N'empêche que ça a des avantages. Je ne vois pas pourquoi on gèrerait une appli comme Gimp ou un éditeur comme Emacs de la même manière. D'ailleurs, les 2 ont leur mode de fonctionnement "à eux" qui est optimisé pour leurs besoins respectifs.

    Je doute qu'on trouve un jour "l'interface ultime" qui permet de tout gérer de manière optimale. En tous cas je suis convaincu que le modèle "fenêtrage + clavier + souris" utilisé dans Windows / MacOS / Gnome / KDE / WMaker / etc. n'est pas la panacée. Et en lisant la description de Berlin/Fresco j'ai l'impression qu'il est vraiment trop restrictif. Typiquement, le window manager est intégré au système, du coup exit les folies expérimentales de geek qui sont possibles avec X11.

    Et pour parler d'uniformisation des interfaces, avez-vous remarqué à quel point les interfaces des sites webs sont diverses et variées? Au début, tout était simple, les liens cliquables en bleu souligné (pour les navigateurs graphiques type Netscape), les titres en plus gros que le texte, les formulaires utilisant les widgets du navigateur et puis basta.

    Aujourd'hui le grand jeu semble de tout "déguiser". Les liens ne sont plus soulignés mais clignotent quand on passe dessus. Les éléments de formulaire sont customisés via des css pour "faire plus joli", n'empêche qu'ils sont plus difficilement reconnaissables... Et d'une manière générale on voit fleurir des pseudos-innovations du genre "je fais péter le menu déroulant en DHTML" qui sont certes très rigolotes mais ne correspondent pas à une charte graphique "standard".

    Paradoxalement, il faudrait qu'un site ouaibe soit le plus original possible pour interpeler l'utilisateur, et par contre une appli devrait se faire la plus discrète possible et se conformer à un vrai-faux standard (CTRL-C <=> copier/coller n'est pas une norme que je sache) pour être utilisable? Bizarre...

    Et en fin de compte, ces mêmes gens qui pourraient pester contre le fait que KDE et Gnome n'ont pas le même look ne se formalisent pas parce que le site de la fnac ou celui de darty n'ont pas la même interface. On est en somme beaucoup plus indulgents avec les sites webs qu'avec les applis "natives". Et pourquoi? J'ai pas de réponse 8-)

    Ceci y'a de bonnes idées dans le projet Fresco. A suivre.

    (*) il y a bien sûr d'autres aspects dans ce projet, et c'est tant mieux!

    • [^] # Re: Fresco, aka

      Posté par  . Évalué à 7.

      Y a pas qu'une question de look, y a une question de poids. Si je lance emacs, kde, galeon et gimp 1.3, je me retrouve avec 4 toolkits différents en mémoire. Super ! (sans compter les bonobos, ORBits, kdebidules, et autres...)

      • [^] # Re: Fresco, aka

        Posté par  . Évalué à 1.

        Ce que tu dis est globalement censé mais comptons 3, plutot que 4.

        GTK 2.0 et GTK 1.2, ce n'est pas censé durer..

        • [^] # Re: Fresco, aka

          Posté par  (site web personnel) . Évalué à -1.

          Et puis il y a une version Gnome d'xemacs...

          • [^] # Re: Fresco, aka

            Posté par  . Évalué à 3.

            Oui mais y a-t-il une version emacs de Gnome ?

          • [^] # Re: Fresco, aka

            Posté par  . Évalué à 2.

            Oui, mais il faut dire ce qu'il est: XEmacs sucks. Et de plus en plus.

            • [^] # Re: Fresco, aka

              Posté par  . Évalué à 1.

              Mignon la tentative de troll :+)

              Ceci dit, XEmacs a peut-etre(je dirais meme, surement) des defauts, mais perso je continue a considerer que c'est le meilleur editeur de code sous Linux, c'est celui qui me convient le mieux.

              Alors bon, il sux peut-etre, mais de mon point de vue il sux moins que les autres.

              • [^] # Re: Fresco, aka

                Posté par  . Évalué à 1.

                Moi, UltraEdit me manque sous Linux. Kate est pas mal bien que moins ergonomique, et bien sûr il a beaucoup moins de features. Surtout, je n'ai rien trouvé d'aussi agréable qu'une Courier New de taille 9 sous Windows.

              • [^] # Re: Fresco, aka

                Posté par  . Évalué à 0.

                Ah non, désolé, mais Xemacs sux0r GNU emacs is the way to go : ) [je peux me mettre -1 en votant [-] pour moi?]

      • [^] # Re: Fresco, aka

        Posté par  (site web personnel) . Évalué à 2.

        Et avec Fresco pendant un temps non négligeable - voire de manière permanente - tu vas te ballader avec Fresco + une couche d'émulation X11 pour faire tourner les inévitables applis X11 qui ne seront "pas encore portées" pour le niveau système + tous les toolkits GTK/Qt/Tk/Xaw/GNUStep/etc. qui existent déjà. J'ai du mal à comprendre comment en créant un nouveau toolkit on peut réduire le nombre de toolkits chargés en mémoire. A part évidemment en s'imposant de n'utiliser *que* ce toolkit. Mais ça on pourrait le faire dès aujourd'hui en se disant "je n'utilise que des applis GTK". Alors évidemment Fresco va plus loin en proposant un toolkit puissant complètement intégré, mais ça ne veut pas dire que personne n'en utilisera d'autre, dans le cadre d'une émulation X11 par exemple. Cette couche d'émulation est d'ailleurs AMHA relativement nécessaire, au moins pour la phase de migration.

    • [^] # Re: Fresco, aka

      Posté par  . Évalué à 4.

      Je crois pas non plus que l'uniformite du look soit le point fort du projet, par contre il y a des trucs originaux et bien sympas.

      L'independance avec l'ecran (comme pour les displays postscript), la taille d'une fenetre ne varie pas avec la resolution. La gestion de la transparence et les operations affines, et puis le point fort de X aussi (la transparence reseau).

      • [^] # Re: Fresco, aka

        Posté par  (site web personnel) . Évalué à 2.

        > la taille d'une fenetre ne varie pas avec la resolution. La gestion de la transparence et les operations affines
        Effectivement, tout cela est bien alléchant, mais typiquement, moi qui suis un utilisateur acharné de http://modeemi.cs.tut.fi/~tuomov/ion/(...) je suis pas trop sûr que ce genre de "look and feel" soit vraiment facile à mettre en place avec Fresco, vu que le WM est _inclus_ dans le projet.

        Remarque vu que c'est un projet libre, il reste toujours la possibilité de coder soi-même une extension folklorique si on la veut, donc d'un certain point de vue ma critique tombe à l'eau.

        En fait j'aime le créneau fonctionnel où se place X11. Il en fait pas trop côté interface. C'est pratique. M'enfin bon, encore une fois, c'est un avis très personnel, et je suis pas contre l'idée d'utiliser autre chose.

    • [^] # Re: Fresco, aka

      Posté par  . Évalué à 6.

      Aujourd'hui le grand jeu semble de tout "déguiser". Les liens ne sont plus soulignés mais clignotent quand on passe dessus. Les éléments de formulaire sont customisés via des css pour "faire plus joli", n'empêche qu'ils sont plus difficilement reconnaissables...


      genre les boutons Vérifier ou Envoyer un commentaire de linuxfr?
      c'est clair que je les ai cherchés au début...
      mais désolé, j'ai fini par les trouver!

    • [^] # Re: Fresco, aka

      Posté par  . Évalué à 3.

      1)Ton premier chapitre: j'ai l'impression que Motif/lesstiff ne se sont pas imposé pour diverses raisons: Motif est commercial et trop cher, lesstiff a mis longtemps a se finaliser et l'utilisation du toolkit Motif a des problemes par exemple la gestion du pavé numérique, et Motif etait moche et on ne pouvait pas facilement changer son look.

      L'uniformité n'était pas un probleme, je pense qu'avec les nouvelles approches toolkit dans le serveur on pourra customiser facilement le serveur tout en gardant un look coherent pour tout les applications: le pied pour ceux qui veulent des interfaces facon "sapin de Noel".

      Uniforme ne signifie pas que tout doit ressembler a Motif(beurk) pour autant..

      2) Meme Apple ou Microsoft n'arrive pas vraiment a garder un look coeherent: il y a plein de toolkit different pour les deux, je doute que Berlin y arrive mieux, ne serait-ce que a cause de la compatibité nécéssaire avec les applications X..

      3) Quand au fait que les interfaces actuelles soient trop limitative et qu'il y a vraiment mieux.. Bof! Ca fait des années que je lits cela et je ne vois toujours rien venir

      4) Euh personellement les sites web qui ressemblent a des sapins de Noel, j'en connais peu et ceux que je connais je les ai toujours trouvés mal fichus.
      Memes les rares site web "joli" et bien fait te retire partiellement le controle de tes actions: attendez pour pouvoir cliquer que je vous montre ma joliee animation..
      Moi une application qui me fait ce coup la, elle ne tient pas deux secondes sur mon disque dur!
      Si tu connais une exception, je suis curieux de voir cela.

      • [^] # Re: Fresco, aka

        Posté par  (site web personnel) . Évalué à 2.

        > je doute que Berlin y arrive mieux, ne serait-ce que a cause de la compatibité nécéssaire avec les applications X
        100% d'accord. En fait je trouverais ça dommage que les gens attendent trop de Fresco question "uniformisation du bureau" car c'est plus ou moins voué à l'échec. Mieux vaut placer ses espoirs dans d'autres aspects de ce projet, et il y en a.

        > les sites web qui ressemblent a des sapins de Noel
        Bah comme quelqu'un le faisait remarquer plus haut, LinuxFR fait partie de ces sites qui "se déguisent". Par exemple les boutons Vérifier et Envoyer n'ont pas le look par défaut. Ils ont un look qui est propre à LinuxFR. Ca ne les rend pas vraiment moins utilisable. De même que je pense qu'un bouton Motif, un bouton GTK, ou un bouton Gnome, ça reste un bouton, même si ils n'ont pas le même look. Tant pis pour ceux qui veulent "uniformiser" leur bureau. Le bouton est fonctionnel, cliquable, pas la peine de faire un fromage sur le look.

    • [^] # Re: Fresco, aka

      Posté par  (site web personnel) . Évalué à 1.

      Je doute qu'on trouve un jour "l'interface ultime" qui permet de tout gérer de manière optimale. En tous cas je suis convaincu que le modèle "fenêtrage + clavier + souris" utilisé dans Windows / MacOS / Gnome / KDE / WMaker / etc. n'est pas la panacée.

      C'est sur, mais en dehors de l'automatisation pure et dure grâce à des scripts, je pense que l'on va quand même bcp plus rapidement avec une GUI pour travailler.

      Le problème de X, c'est que c'est surtout une interface pour lancer pleins de Xterm, donc en fait, c'est surtout utilisé pour avoir pleins de consoles à l'écran.

      Je m'explique dans win/mac/amiga/be, tu ouvres ton répertoire en gui, tu selectionne plusieurs fichiers, tu les "drag'n'drop" dans une appli ou un autre répertoire.

      Même si ton appli s'appelle photoshop, winamp, word, "ce que tu veux" et même Xemacs avec des look délirant, le "drag'n'drop" marche.

      Je prend l'exemple du "drag'n'drop" parce que je trouve que c'est le point qui fait que pour moi une interface est plus "productive", ça pourrait être en mode texte que ça ne me dérangerais pas plus que ça.

      Dans un répértoire de 200 photos, va sélectionner 5 photos en ligne de commande pour les transferer d' un répertoire avec des espaces vers un autre répertoire utilisant des noms exotiqes. Le plus rapide, c'est par file manager.

      Maintenant filtrer toutes tes photos par plusieurs critères de manières automatique, pas d'hésitation => ligne de commande.

      95% du temps, tu es plus rapide avec la souris qu'à la console, sauf si c'est un poste ou tu fais toujours les même tâche récurrentes et que tu laisses allumer 24h/24 (comme un éditeur de compilation au boulot, même pas besoin de toucher à la souris, "code . code . code . compilation. code. code . code...."

      Ce qui me dérange avec X, mais c'est normal il n'a pas été prévu pour ça, c'est qu'il n'y a pas d'uniformité de COMPORTEMENT.

      X est juste un toolkit "d'AFFICHAGE graphique" (avec le copier coller quand même).

      L'uniformité du look, je m'en fous, mais ça me fait chier quand pour un programme, je suis obligé de passer par fichier/ouvrir, un autre je peux drag'n'drop, et le troisième, ben vaux mieux passer par la ligne de commande.

      Alors on va me répondre Gnome et KDE, oui mais les vielles applis X11 n'utilisent pas les caractèristique du bureau, et la communication entre applis gnome et kde n'est pas toujours évidente.

      Alors RedHat a fait un effort d'uniformisation de look, mais c'est pas ça qui compte, ce qui compte c'est que les applis utilisent la même API de communication entre elle, le reste on s'en fout.

      Et en lisant la description de Berlin/Fresco j'ai l'impression qu'il est vraiment trop restrictif. Typiquement, le window manager est intégré au système, du coup exit les folies expérimentales de geek qui sont possibles avec X11.

      C'est clair qu'ils ne répondent pas au soucis de l'utilisateur, on s'en fout d'un look homogéne, mais on veut un comportement homogéne.

      J'aimerais bien qu'une des folie expérimentales de geek soit à terme la définition d'un standard d'intercommunication d'application qui sera utilisable par tous les bureaux.

      En gros au lieu de faire un desktop, faire un X11+ qui intégre les nouveaux désirs des utilisateurs, et ne pas laisser les desktops faire ça dans leur coin.

      • [^] # Re: Fresco, aka

        Posté par  . Évalué à 1.

        Je m'explique dans win/mac/amiga/be, tu ouvres ton répertoire en gui, tu selectionne plusieurs fichiers, tu les "drag'n'drop" dans une appli ou un autre répertoire. Même si ton appli s'appelle photoshop, winamp, word, "ce que tu veux" et même Xemacs avec des look délirant, le "drag'n'drop" marche. Je prend l'exemple du "drag'n'drop" parce que je trouve que c'est le point qui fait que pour moi une interface est plus "productive", ça pourrait être en mode texte que ça ne me dérangerais pas plus que ça.


        L'equivalent du drag n drop en ligne de commande c'est le pipe. Et pour info le drag n drop ne marche que si l'application le gere derriere enfin c'est normal quoi. Pour l'exemple des images, comment tu fais si c'est des films, de la musique ?

        95% du temps, tu es plus rapide avec la souris qu'à la console, sauf si c'est un poste ou tu fais toujours les même tâche récurrentes

        Pour moi, c'est pas le cas, j'aime pas les mulots et j'ai pas l'impression d'etre plus lent a la console (je fais pas toujours la meme chose). Ce qui m'est penible avec la souris c'est que ca prend une main en et comme je tappe avec les deux mains, c'est tres lent (passer son temps a gaspiller de l'energie pour bouger le bras).

      • [^] # Re: Fresco, aka

        Posté par  . Évalué à 2.

        <I>J'aimerais bien qu'une des folie expérimentales de geek soit à terme la définition d'un standard d'intercommunication d'application qui sera utilisable par tous les bureaux. </I> Pour avoir programmer des applis sous X (bon y a un bail), je peux t'assurer que X presente une couche de communication inter process. Je conviens aussi que la programmation en Xlib est probablement un peu, disons, lourde si on la compare à la programmation via GTK/QT/AUTRES_LIB_AU_CHOIX. Voila c'etait juste pour dire, et pour poster mon premier commentaire.

      • [^] # Re: Fresco, aka

        Posté par  (site web personnel) . Évalué à 1.

        Dans un répértoire de 200 photos, va sélectionner 5 photos en ligne de commande pour les transferer d' un répertoire avec des espaces vers un autre répertoire utilisant des noms exotiqes. Le plus rapide, c'est par file manager.

        justement dans 200 photos tu va bien plus vite en ligne de commande si tu connais un bout des noms ! Scrolller des heures à chercher un fichier, ce n'est pas trop mon truc !

        "La première sécurité est la liberté"

        • [^] # Re: Fresco, aka

          Posté par  (site web personnel) . Évalué à 1.

          si tu connais le début des noms tu cliques sur la colonne "nom" pour un classement alphabétique. Si c'est une partie des noms tu met un filtre adapté pour sélectionné.

          Bref, sans pour autant dire "le graphique c'est bien la ligne de commande c'est nul" ton argument est tout à fait inadapté

  • # Re: Fresco, aka

    Posté par  . Évalué à 2.

    J'ai suivi le projet depuis un certain temps (j'ai meme donné un tout petit coup de main pour traduire une doc en Francais), mais il y a une chose qui me décoit beaucoup dans Berlin/Fresco, c'est la consommation mémoire de l'ensemble: je me souviens d'un portage fait par un des développeurs du projet sur IPaQ il avait bouffé toute la mémoire du portable, alors que TiniX plus un toolkit léger prend beaucoup moins de mémoire..

    Je sais bien que de toute maniere Fresco ne sera pas vraiment disponible avant que la moindre machine bas de gamme n'ai 1 Go de RAM, mais franchement cela me gene..

    PicoGUI est un autre systeme qui etait prevu au depart pour les PDA et a une architecture semblable (toolkit dans le serveur) a Berlin, cependant la derniere fois que j'ai regardé l'affichage ne pouvait pas etre accéléré par le matériel, génant..

    Enfin les deux ont une conception que je trouve nettement meilleure que X, la page Fresco vs X resume bien la chose.

  • # De toute façon X est un complot maléfique

    Posté par  (site web personnel) . Évalué à 5.

    http://lcamtuf.coredump.cx/evilfinder/ef.cgi?said=X+Window+System(...)

  • # Dans le même style

    Posté par  . Évalué à 2.

    Allez voir une autre idee de linux sans X :
    http://www.directfb.org/(...)

    Encore un truc d'allemand ;)

Suivre le flux des commentaires

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