Journal KDE 4 et le rendu vectoriel

Posté par .
Tags : aucun
0
2
jan.
2007
Bonjour !

Comme vous le savez tous (ou presque), KDE 4 est en plein développement et un tas de choses excitantes sont en vue. Une des nouveautés sera le rendu de certaines interfaces directement en vectoriel via SVG. Pour ceux que ça intéresse de voir à quoi ça ressemble, il y a pas mal de captures d'écran et d'explications dans cet article : http://dot.kde.org/1167723426/ .

Certaines améliorations sont impressionnantes, en particulier pour kmahjongg. Une fois tout ça bien en place les artistes vont pouvoir faire quelque chose de beau et propre (ce qui n'est pas forcément le cas actuellement, certains exemples un peu chargés n'étant là que pour montrer les possibilités).
  • # svg et lien

    Posté par . Évalué à 3.

    peut-être un peu hors sujet, je m'en excuse, mais parlant de svg, j'ai fait une page d'acceuil en svg avec inkscape avec des liens sur certains éléments en utilisant la balise <a xlink:href=lelien>[...].
    je l'ai inclus dans une page xhtml avec .
    Sur firefox, les liens fonctionnent sans problèmes.
    Sur konqueror, la page s'affiche très bien, mais les liens ne sont pas actifs. Par contre, si j'ouvre directement le fichier svg dans konqueror, les liens marchent.
    Ceci est-il normal ? konqueror ne gère pas assez de chose ou firefox en gère trop (est-ce que ceci est censé être géré par les navigateurs ?).
    Voilà, désolé pour la polution, mais je suis tombé sur ce problème aujourd'hui et ce journal m'a l'air un peu lié.
    • [^] # Re: svg et lien

      Posté par . Évalué à 3.

      en parlant de lien, est-ce que tu pourrais mettre cela sur internet et nous en donner le lien que l'on puisse tester ?
      Désolé, je ne m'y connais pas plus, mais c'est une fonction intéressante.

      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: svg et lien

        Posté par . Évalué à 3.

        au temps pour moi, ça fonctionne aussi avec konqueror apparement.
        j'ai mis de liens en ligne pour illustrer :

        http://seginus2.free.fr/svglink/

        voilà, chez moi :

        -- sous firefox : le fond est bien transparent (c'est voulu) et les liens s'ouvre dans la zone du embed (ce n'est pas voulu)

        -- sous konqueror : c'est le contraire
        • [^] # Re: svg et lien

          Posté par . Évalué à 2.

          ok merci, je comprends comment cela fonctionne maintenant, mais je ne vois pas pourquoi il y a cette différence entre les 2 navigateurs, à priori aucun des 2 n'a un comportement qui semble attendu.
          Opera semble réagir comme firefox.

          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: svg et lien

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

          Je lisais ce journal avec la wii et sache que ça marche très bien sur le navigateur de la Wii.

          Comment ça on s'en fout?

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Encore un effort

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

    En effet c'est pas mal du tout. Encore un effort et on aura atteint le niveau de Gnome 1.2.
    • [^] # Gnome 1.2

      Posté par . Évalué à -5.

      Gnome 1.2 ? Beau, simple et surtout léger, ça me va !
  • # C'est le genre...

    Posté par . Évalué à 2.

    De boîte de dialogue "d'invité d'execution" que je kiff réellement, un truc discret qui se fond avec le bureau. ça à l'air con, mais c'est réelement
    http://static.kdenews.org/dannya/vol1_devel_run.png

    en fait, on n'a même pas de SVG pour ce genre de truc, un affichage style OSD aurait très bien fait la pair.

    D'ailleurs, n'y aurait-il pas déjà ce genre d'addon quelques part?
  • # foutaises

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

    Certaines améliorations sont impressionnantes, en particulier pour kmahjongg. Une fois tout ça bien en place les artistes vont pouvoir faire quelque chose de beau et propre


    faire un dessin pourri, qu'il soit en bitmap ou en SVG, ça restera un dessin pourri.

    Ces screenshots ne montrent absolument pas la superiorité de SVG : juste que des designers sont enfin passés par là pour faire des interfaces plus jolies.

    Que ce soit la nouvelle version de katomic ou du mahjong, elles auraient pu très bien être fait en bitmap, le rendu aurait été identique.

    bref, argument à deux balles que tu nous dis là (et que dis la news kde aussi)

    L'avantage de SVG, c'est pas la beauté, mais les spécificités techniques qu'il y a derrière pour le développeur. tout est facilité : faire un zoom, modifier, transformer le dessin en live programmatiquement (via le DOM), taille réduite des fichiers (en général) etc...
    • [^] # Re: foutaises

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

      Je pense qu'un autre avantage du SVG c'est la possibilité de le modifier. Quand on travaille sur des graphismes, en bitmap, on a généralement une haute résolution pour le travail (parfois avec les différents calques au sens Gimp/Photoshop) et on exporte une résolution plus petite et applati... et il est très difficile de travailler avec cette résolution par la suite.
      Alors qu'en travaillant en SVG et en DIFFUSANT ce format, un autre designer peut également retravailler dessus sans avoir à tout refaire à partir de zéro...

      ça me semble plus en adéquation avec l'esprit du libre... ça sert à rien de réinventer la roue...

      Axel
      • [^] # Re: foutaises

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

        J'y vois aussi un gros avantage au SVG ...

        la possibilté de jouer en plein écran avec une résolution dépassant le 800x600, car faut avouer que certains jeux ( karbon par exemple ) sont limité à la taille de leurs images bitmap !
    • [^] # Re: foutaises

      Posté par . Évalué à 6.

      sniff, le svg, c'est la mort du pixel art sur le bureau :(

      http://fr.wikipedia.org/wiki/Pixel_art

      http://toastytech.com/guis/macos9.html
      http://toastytech.com/guis/macos9folders.png

      http://asisaid.com/images/kde22beta1.png
      http://people.kde.org/kristof.html

      Merci Kristof Borrey pour ces icônes que j'utilise encore !

      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: foutaises

      Posté par . Évalué à 10.

      faire un dessin pourri, qu'il soit en bitmap ou en SVG, ça restera un dessin pourri.


      Certes, mais un dessin pourri automatiquement à la bonne échelle et anti-crénelé c'est mieux qu'un dessin pourri tout pixellisé parce qu'on l'affiche trop grand. :)

      Ces screenshots ne montrent absolument pas la superiorité de SVG.


      C'est exact, une petite vidéo avec un redimensionnement en tems réel aurait été plus parlant.

      Que ce soit la nouvelle version de katomic ou du mahjong, elles auraient pu très bien être fait en bitmap, le rendu aurait été identique.


      Et tu vas t'amuser à fournir toutes les tuiles possibles de toutes les tailles possibles afin que leur taille soit adaptée lorsque tu changes la taille de la fenêtre ? En théorie c'est possible mais en pratique c'est ingérable.

      L'avantage de SVG, c'est pas la beauté, mais les spécificités techniques qu'il y a derrière pour le développeur. tout est facilité : faire un zoom, modifier, transformer le dessin en live programmatiquement (via le DOM), taille réduite des fichiers (en général) etc...


      Spécificités qui permettent aux artistes de pouvoir faire plein de trucs beaux et propres sans se prendre la tête.

      Tant qu'on y est, ceux qui veulent jeter un ½il au futur jeu d'icônes (vectorielles) de KDE 4, c'est par ici : http://www.oxygen-icons.org/ .
      • [^] # Re: foutaises

        Posté par . Évalué à 2.

        En passant, je trouve dommage que les icones soient en CC-NC-ND.
        • [^] # Re: foutaises

          Posté par . Évalué à 7.

          Ce sont juste les icônes de démonstration qui sont en CC-NC-ND. Le jeu diffusé avec KDE 4 sera sans doute en LGPL si j'en crois la mention : « Oxygen icon theme, will be released under a GNU License, probably LGPL but we hope to have an official GNU License for icons/images for that time. »
          • [^] # Re: foutaises

            Posté par . Évalué à 1.

            ah oui effectivement, j'avais pas tout lu
            • [^] # Re: foutaises

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

              Les icones n'ont pas de licence actuellement, donc personne a le droit de les utiliser, autre que pour les besoins de la création (pour nous aider donc).

              Les trucs artistiques se périment assez vite, et on a pas envie que lorsque KDE4 sorte, il paraisse déja périmé parce que quelqu'un aura diffusé le tar.gz sur kde-look.org depuis un an. A la release de KDE4, ca sera une licence libre, LGPL si pas mieux.
    • [^] # Re: foutaises

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

      Il y a quelque chose qui joue indirectement sur la beauté, c'est que l'inclusion du SVG telle qu'on le fait dans KDE4 améliore aussi le processus de dev.

      - Il y a 1 SVG par programme, donc avec Inkscape, je peux facilement modifier le style, sauver le fichier, et tester. Pas besoin de passer par une phase de découpage d'un bitmap, nommage... Je gagne du temps.
      - L'edition d'un graphisme en SVG est tres rapide, et en plus facilite le recyclage. Le theme du jeu knetwalk m'a pris qu'une soirée (en encore, assez cool, a chatter sur IRC en meme temps...). Je gagne encore du temps.
      - Notre theme d'icone Oxygen est réalisé en SVG. Utiliser un engine SVG pour les jeux, moniteur (et autre...) nous aide grandement a garder un style cohérent (déja parce que du coup ce sont les meme graphiste utilisant les meme techno...)
      - ça se scale nickel, on peut agrandir la fenetre... ca reste propre. Sachant que KDE4 aura une durée de vie de l'ordre de 5 ans, pas de soucis avec les futurs moniteurs en résolution 5120*3200...
      - C'est agréable a utiliser
      - Tout cela fait que je peux dessiner agreablement, et etre productif (et prendre mon pied). A coté, recemment ici, des gens critiquait les éléments graphiques (datagrammes, ....) de openoffice aupres d'un des dev. J'étais pres a y contribuer, mais j'ai été vite refroidi quand j'ai vu qu'il faudrait que je code tout en C++...

      En résumé, j'y prend du plaisir, donc je contribue, en plus c'est rapide a faire, agréable, et je gagne bcp de temps... voilà pourquoi le SVG joue finalement sur la beauté..

      PS: Ca sera + jolie que ça, les screenshoots actuels sont composés de trucs fait tres vite fait pour permettre aux devs de tester leur code:
      - ksysguard: SVG temporataire (le nouveau est quasi pret) et couleurs qui vont changer
      - KMahjongg: y'aura un background, et je risque de changer la gueule des pieces (mais pas des dessins)
      - quant au "Run Command", c'est vraiment un exemple type du trucs pour permettre aux devs de tester leur code
      PS2: Ca a rien a voir avec le SVG, mais les devs avec qui je bosse sont super cool, ca aide aussi :D
  • # perfs et précalcul

    Posté par . Évalué à 3.

    De temps en temps on lit ici des commentaires de gens outrés qu'il faille changer de machine tout les 6 mois pour pouvoir utiliser les nouvelles versions de logiciels qui sortent. Dans le meme temps, on a :

    - un processus de démarrage qui est très fortement interprété ( les scripts bash c'est sympa pour debugguer mais pour l'utilisateur final, le seul avantage c'est qu'il a le temps de bien se reveiller pendant le boot ). Comme ça, à chaque démarrage, l'ordi refait la meme chose. Comme si à chaque fois que vous cuisiniez, vous ressortiez la meme recette en elfique et que vous passiez la moitié de votre temps total à la re-traduire sans jamais conserver la traduction dans un coin.

    - des dessins en vectoriel : en théorie c'est magnifique, en pratique on va se taper 10 fois plus de calcul pour afficher un bouton qu'avec un bitmap.

    - des fichiers de config en texte et/ou xml pour tout ( mon exemple preféré est la liste des menus/mimetype et autres fichiers xdg/desktop : si on avait une mini-base de données avec une api d'ajout/modification/suppression, le total des données sur le disque serait divisé par 10. J'ajoute que comme un petit fichier sur le disque occupe toujours plus de place que sa taille, la quantité d'octets lue au démarrage pour ces fichiers ramenée à la quantité d'infos utiles est tout simplement une offense aux ingés electroniciens qui concoivent le hardware en l'optimisant ).

    Bref j'ai hate d'avoir un desktop full svg. Ca me rappelle d'ailleurs que les types de chez Microsoft essayent en ce moment de fourguer leur techno WPF qui permet de faire du vectoriel à tout va ( et par la meme occasion, ca aide beaucoup intel à vendre du core 2 duo et nvidia de la geforce compatible dx 10 ).
    • [^] # Re: perfs et précalcul

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

      D'ailleurs, les premières captures d'écrans sur lesquelles on tombe illustre bien tes propos (celles du KDE System Guard) : on voit une charge du processeur à 100% et une grande occupation de la mémoire physique...

      Ils cherchent à concurrencer Gnome?
      • [^] # Re: perfs et précalcul

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

        C'est pas significatif, il devait avoir un truc de lancé sur la machine. Le meme ksysguard prend 2 à 5% max chez moi et encore...

        Je rajouterai que le dev, John Tapsell , est un acharné de l'optimisation CPU et mémoire, je suis loin d'etre inquiet pour ce soft...
    • [^] # Re: perfs et précalcul

      Posté par . Évalué à 9.

      - des dessins en vectoriel : en théorie c'est magnifique, en pratique on va se taper 10 fois plus de calcul pour afficher un bouton qu'avec un bitmap.


      Sauf que d'après les développeurs de KDE, le rendu en SVG est quasiment aussi rapide que le rendu bitmap (je n'arrive pas à retrouver la source où j'ai lu ça cependant, si quelqu'un l'a sous la main ...). Il faut aussi rappeler que si tu redimensionnes ta fenêtre avec des dessins bitmap dedans, tu es obligé de lire les nouveaux bitmaps à la bonne taille sur le disque (ben oui, il faut bien changer la taille des éléments, sinon de toute façon tu ne les recalcules pas, SVG ou pas) et les afficher.

      De manière générale, pour ce qui est du graphisme et de Qt, je conseille la lecture du blog de Zack Rusin qui contient plein de choses intéressantes http://zrusin.blogspot.com/ . Il y a même quelques petits tests comparatifs comme http://zrusin.blogspot.com/2006/10/benchmarks.html .
    • [^] # Re: perfs et précalcul

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

      - des fichiers de config en texte et/ou xml pour tout ( mon exemple preféré est la liste des menus/mimetype et autres fichiers xdg/desktop : si on avait une mini-base de données avec une api d'ajout/modification/suppression, [...]


      C'est pourquoi KDE garde en cache tout ça dans une base de donnée binaire
      (c'est KSycoca qui fait tout ça (KDE SYstem COnfiguration CAche) )
  • # Next

    Posté par . Évalué à 5.

    Les next, avec leur affichage ecran en poscript, ils avaient combien d'avance ? 10 ans, 15 ans ?
    • [^] # Re: Next

      Posté par . Évalué à 3.

      Et BeOS avec ses coordonnées de pixels en virgule flottante ? http://www.beunited.org/bebook/The%20Interface%20Kit/Point.h(...)

      L'informatique, c'était mieux à vent :(

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Next

        Posté par . Évalué à 1.

        Oui enfin cela n'a jamais servis. Et d'ailleurs je ne vois pas comment cela aurait pu servir, vu que le pixel est l'unité de base.
    • [^] # Re: Next

      Posté par . Évalué à 3.

      On va arrivé à 15 bientot... Les gpu ne sont pas encore utilisé comme le DPS des next l'était pour gérer l'affichage vectoriel.

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

  • # Gnome saitmieux

    Posté par . Évalué à -3.

    Bah oui, gnome saitmieux, gmahjongg utilise déjà SVG ;-)

    Encore une preuve s'il en fallait de la superiorité technique incompressible de Gnome.
    • [^] # Re: Gnome saitmieux

      Posté par . Évalué à 3.

      on sait bien que c'est de l'humour, que t'as mis un smiley et tout, mais le comique de répétition c'est lourd !
      • [^] # Re: Gnome saitmieux

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

        Non. C'est Gnome qui est lourd.




        Bon, je le mets, ce smiley, ou bien ?
      • [^] # Re: Gnome saitmieux

        Posté par . Évalué à 0.

        Bof, peut-être qu'a force de taper au marteau avec la subtilité d'un nain berserk des montagnes kamikazes chevaucheur de taupes du Chaos, ça rentreras.

        Ou pas.*

        En fait, sûrement pas du tout. Snif.*

        N'empêche qu'on s'extasie sur Kmahjongg qui gère enfin le SVG dans son dernier CVS (oh...! Ah...! *bave qui coule des lèvres*) alors que Gnome mahjongg le fait, d'puis longtemps qui plus est.
        (Pour comparer, les indispensables scrineshottes : http://live.gnome.org/Mahjongg et http://games.kde.org/kmahjongg/ )

        (*)Message Subliminal Lent : Gnome, c'est bien !
        • [^] # Re: Gnome saitmieux

          Posté par . Évalué à 6.

          C'est plus dans CVS, KDE.
        • [^] # Re: Gnome saitmieux

          Posté par . Évalué à 2.

          > on s'extasie sur Kmahjongg qui gère enfin le SVG
          ben non, on dit que plusieurs applis kde vont utiliser le svg, même des trucs comme ksysguard

          > alors que Gnome mahjongg le fait
          super ... same-gnome n'utilise pas le svg (hin hin j'ai vérifié) alors que ksame va utiliser le svg, on peut donc en déduire que kde est mieux que gnome hein ? (et encore j'ai été gentil, j'aurais pu insulter ton enlightenment chéri :) )
          • [^] # Re: Gnome saitmieux

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

            > same-gnome n'utilise pas le svg (hin hin j'ai vérifié)

            Pour être plus juste, certain theme de same-gnome n'utilise pas le svg, d'autre oui (par exemple le theme "rotate").

Suivre le flux des commentaires

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