Qt GPL pour DirectFB en version pre-alpha

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
22
juil.
2003
KDE
Qt a été porté pour DirectFB. Pour l'instant, c'est en version pré-alpha. La licence est la GNU GPL. Dans les liens il y a le site web du projet avec le code source et des captures d'ecran.

Qt est la bibliothèque graphique C++ de l'entreprise Trolltech disponible sous licence GPL notamment pour GNU/Linux et MacOS X. Qt est disponible sous une licence payante pour ceux que la licence GPL rebute.
Qt est la bibliothèque graphique à la base du projet KDE.

DirectFB est une bibliothèque bas niveau au dessus du framebuffer du noyau Linux qui permet l'accélération graphique et l'abstraction des composants matériels. GTK+ a déjà été porté sous DirectFB depuis quelques temps (http://directfb.org/gtk.xml). DirectFB a pour ambition de remplacer les implémentations X actuelles.

Aller plus loin

  • # Re: Qt GPL pour DirectFB en version pre-alpha

    Posté par  . Évalué à 1.

    Tiens tiens, un soft en version pre-alpha en premiere page ???????

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

      Posté par  . Évalué à 3.

      Tiens tiens, un vieux de la vieille en first post ?!

      Ceci dit, et sans offense, DirectFB a vraiment pour ambition de remplacer les implémentations X actuelles ? Quid d'applications comme xdvi qui n'ont pas vraiment d'équivalents avec les différents toolkits graphiques ? À ma connaissance, quelques applications utilisent un mix de toolkit et d'accès direct aux Xlibs, et celles-ci ne tournent pas sur DirectFB, à moins que j'aie loupé quelque chose.

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

      Et puis sans vouloir faire le rabat-joie, le soft est loin d'être fini : il reste pleins d'appels X11 ! merci XDirectFB..

      Mais bon je suppose qu'après la news sur dot.kde.org puis sur osnews puis sur /. y'a eu comme un manque de pas l'avoir ici ? :-))

      Sinon, ben... c'est bien, c'est une avancé positive; mais c'est pas encore vraiment fini ! accessoirement, Gtk tourne nativement (enfin, une version de Gtk hackée pour l'occasion) sous DirectFB.

      \begin{avis-cafe-du-commerce}

      Concernant DirectFB lui-même, pas mal de progrès dernièrement, dont le support du DRI ! à vous les joies de l'OpenGL accéléré sous DirectFB ! :-))

      Honnêtement, DirectFB est une solution vraiment intéressante. Je pense que ça peut devenir la gestion graphique par défaut sous linux à la place de X11. On va objecter les possibilitées réseau de X, mais bon, si on utilise des applis DirectFB qui sont en fait des applis KDE/GNOME/GNUstep normale, on peut toujours au besoin repasser dans mode "X11". Et Pour les applis non portées, on peut utiliser XDirectFB (qui réussi l'exploit d'être plus rapide/léger que XFree -- sachant que XDirectFB est basé sur XFree, on se pose des questions).

      Maintenant faudra voir aussi avec les avancées d'XFree et Keith Packard...

      \end{avis-cafe-du-commerce}

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

        > Et Pour les applis non portées, on peut utiliser XDirectFB (qui réussi l'exploit d'être plus rapide/léger que XFree -- sachant que XDirectFB est basé sur XFree, on se pose des questions).

        Le plus gros défaut de directfb, c'est les drivers, il n'y en a aucun. Tant que les devs resteront à conseiller d'avoir des cartes matrox au lieu de dévellopper des drivers, le projet restera marginal et inutile.

        Par exemple, le driver radeonfb n'a pas changé depuis septembre 2002(et encore, c'était pas vraiment une modifs, c'était pour une question de licence) et la derniere fois que je l'ai essayé, il était buggé, lent(presque tout était fait en software).

        Directfb, c'est amusant 5 min pour jouer, mais pour le moment, ça ne sert a rien.

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 5.

          Il est plus rapide/plus léger, ou bien il donne l'impression d'être plus rapide/plus léger car il garde une image de chaque fenetre en mémoire, et peut donc donner l'impression de la réafficher instantanément quand on déplace des fenetres par ex ? Je pense plutot pour la seconde solution...

          • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

            Posté par  . Évalué à 3.

            Je penche pour la deuxième solution.

            Sous NT, les gens avaient bien l'impression que l'OS allait plus vite parce que plus de ressources étaient allouées au calcul & réaffichage du déplacement de la souris (ce qui était assez agréable d'ailleurs)

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 2.

          C bizarre parce que sur la premiere niouze du site, il parle de driver Radeon accéléré....

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

          Euh plus rapide, il met 3 plombes a demarrer [*] qd meme :)
          D'autre part il est plus que base sur xfree, aux dernieres nouvelles ct juste un enorme patch...

          [*] (sur autre chose que des matrox, certes, jai pas teste avec des matrox)

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 5.

          > Directfb, c'est amusant 5 min pour jouer, mais pour le moment, ça ne sert a rien.

          Il est certain que lorsqu'on utilise un système libre pour remplacer un unix commercial en réseau et la ferraille associée, DirectFB peut sembler sans grande importance face au standard que représente le protocole X11.

          En ce qui me concerne sur ce sujet (soft/embarqué), GTK + DirectFB était la solution la plus efficace que je connaissais pour faire des zoulies interfaces pour du matériel sur lequel XFree représentait un surcoût difficilement acceptable. J'avoue ne pas voir d'un mauvais oeil l'idée de pouvoir choisir entre plusieurs toolkits.

          Il ne faut pas perdre de vue le fait que l'un des modèles économiques viables du logiciel libre est de vendre conjointement du matériel et du logiciel à des prix bas, le logiciel restant libre, bien que perdant son sens en tant que tel pour l'utilisateur final (mais certainement pas pour le developpeur).

          Quand au pre-alpha, bah... par définition, un portage se fait rarement en parfaite connaissance de cause du contexte de départ ET d'arrivée.

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

          En même temps les Radeon sous X (j'ai la 4.3.0) c'est pas mieux : je suis passé d'une Voodoo 3 2000 PCI 16Mo à une Radeon 9200 AGP 128Mo, tout ça pour découvrir que X est plus lent maintenant (par exemple lors du passage d'un bureau virtuel à un autre).

          Enfin, je me console avec Tuxracer... :-)

  • # Re: Qt GPL pour DirectFB en version pre-alpha

    Posté par  . Évalué à 10.

    cela reste toujours un jouet à coté d'un serveur X.

    Une foule de gens semblent croire que le protocole X et la transparence réseau sont inutiles mais PAS DU TOUT!! c'est l'une des principales forces d'un système unix, pour une foule de besoins (administrations, prise de controle etc)

    et surtout transparence, client/serveur, l'application ne peut pas faire de suppositions sur le serveur en dessous, et CA c'est une bonne chose.

    c'est tellement une bonne chose, que ce qui manque à osx malgré toutes les qualité de son "quartz", c'est l'affichage distant.

    Xfree doit etre amélioré, pas rejeté. et y aucune raison technique pour croire que X Free ne peut pas etre amélioré, voir www.xwin.org

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

      pour les particuliers la prise de controle a distance et l'administration servent à quoi ?

      X est trop lourd pour la plus part des utilisations (en tout cas pour toutes mes utilisations)

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

        Posté par  . Évalué à 2.

        A titre d'exemple, mais c'est loin d'être exhaustif, la prise de controle a distance et l'administration ça sert chez moi à gérer la passerelle sur laquelle il n'y a ni clavier ni écran.
        C'est vrai que je pourrai tout faire au travers d'interfaces déportées comme Webmin ou autre mais afficher sur un client un xosview, gkrellm et consorts, je sais c'est idiot, mais ça me rassure... surtout depuis que j'ai "perdu" un ventilo sur l'un des procs et que les températures explosent...

        Je crois aussi qu'à force de vouloir un nivellement par le bas des fonctionnalités, et ça ne concerne pas que X, en voulant rendre simple/abordable, on en arrive à brider notre créativité et à se fondre dans le PPCD (Plus Petit Commun Dénominateur : ça existe ça ?). Toute ressemblance avec des OS existants est purement fortuite ;o))
        Est-ce cela que nous voulons demain ?

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 4.

          C'est vrai que ce serait dommage de perdre toutes ces fonctionnalités.
          Par contre pour xosview ou gkrellm, il y a un démon gkrellmd qui te permet de te connecter dessus d'un poste client, la mmême chose existe pour kde avec ksysguard et ksysguardd. Tout ça devrait te permettre de jeter un oeil sur ta passerelle en te passant du display déporté.

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

          non mais elle peuvent être séparé, ce qui a fait le succés de linux c'est de pouvoir customisé à fond son noyau afain d'avoir quelque chose qui correspond exactement à ses besoins.

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 0.

          Donc voila, tu as besoin d'un "serveur" X11 sur ta passerelle mais pas sur ta station de travail qui a juste besoin d'un "client" X11 pour recuperer les fenetres.
          Je trouve idiot de lancer une serveur X sur sa propre machine alors que c'est pas utilisé.

          • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

            Posté par  . Évalué à 5.

            Toi tu n'a pas compris comment fonctionne X.
            Le client X, c'est le programme qui va demander au serveur de l'afficher. Donc tu dois avoir un serveur X qui fonctionne sur la machine où tu veux afficher tes programmes, mais ce n'est pas utile sur la machine sur laquelle le programme s'exécuté (il faut juste les bibliothèques X).

            Je trouve idiot de lancer une serveur X sur sa propre machine alors que c'est pas utilisé.

            Effectivement, lancer un serveur X sur une machine qui n'a aps d'écran ne sert à rien.

        • [^] # X sur un routeur

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

          me dis pas que tu fais tourner X sur ton routeur ? elle est bien bonne celle là ;c)

          • [^] # Re: X sur un routeur

            Posté par  . Évalué à 1.

            X est sur la machine qui fait l'affichage (par exemple un PC de bureau).
            Puis tu connais beaucoup de routeurs avec un écran ?

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

        Posté par  . Évalué à 2.

        > pour les particuliers la prise de controle a distance et l'administration servent à quoi ?
        J'en sais rien. Mais va voir sur des forums de Windowsiens, et tu verras que c'est le genre de question qui revient continuellement.

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

        Posté par  . Évalué à 2.

        > pour les particuliers la prise de controle a distance et l'administration
        > servent à quoi ?

        Comme toutes les fonctions, ça sert à être _là_ , magnifiquement disponible, le jour où tu en auras besoin.

        (tiens, si je montais un petit réseau avec la vieille bécane...)
        (tiens, ma copine a besoin d'un éditeur LaTeX sous windows pour taper sa thèse [ssh->cygwin->X->kile])
        (euh...tu veux relever ton mail sur ma bécane ? oui mais là je bosse... bon,
        $ xhost +tapomme
        $ su - tapomme
        $ kmail&
        t'as 2 minutes, je ferme les yeux...)

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 0.

          y a vraiement besoin de x pour faire ça ?
          alors qu'un simple client mail en mode text ferais l'affaire.
          Idem pour latex : tu peux tapez ton texte dans n'inporte quel editeur, tu le compile sous linux via ssh et c'est bon...

          Mais ça peut servir a bien d'autre chose, comme il a ete dit dans un autre post il faut voir si ça bouffe rellement pas mal de ressource ( j'en doute vu que x arrive a tourner sur des petites config....)

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 1.

          $ xhost +tapomme
          $ telnet tapomme
          $ su - tapomme

          $ DISPLAY=hoste-cible:0;export DISPLAY

          $ kmail&
          (j'ai plus besoin de fermer les yeux...!)

          REM: à partir du moment où tu as plusieurs machines chez toi, le déport réseau d'appli graphiques est très cool.

          A+

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

        pour les particuliers la prise de controle a distance et l'administration servent à quoi ?

        Moi j'utilise beaucoup les possibilités réseau de XFree d'une manière "normale". Grâce à x2x, je fais une sorte de dual-screen entre mon PC et le portable. Certes, on ne peut pas déplacer une fenêtre d'un X à l'autre, mais je peux utiliser le clavier et la souris de mon PC, qui sont bien plus agréables.
        Voir http://allergy.alrj.org/gruik/index.xhtml(...) pour plus d'infos, surtout la dernière partie.

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

        Posté par  . Évalué à 1.

        A gérer ca petite famille.
        Et pourquoi pas avoir un seul PC et que tout le reste ne soit que les tele soient des terminaux qui executent des applis du PC.

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

      Sauf que comme je le dis plus haut, ce serait un mal (potentiel) si on utilisait "directement" DirectFB... mais si on passe par des librairies qui ont une version X11, l'impact négatif est limité. De plus, l'affichage déporté, même si c'est très sympa, est quand même peu utilisé, en particulier dans un usage personnel/familial. En entreprise, oui, c'est plus intéressant, mais même là, on ne fait pas si souvent que ça du X. Entre autre parceque sur une faible BP c'est pas vraiment ça ... DirectFB permet simplement d'avoir un modèle graphique plus au gout du jour et d'être plus léger/réactif que XFree. Les applis X11 actuelles sont de toute façon à un niveau d'abstraction bien au dessus du protocole X, donc ce n'est absolument pas gênant de voir X ou DirectFB comme simplement des "cibles" possibles pour lancer une application..

      Maintenant, il faut voir aussi qu'effectivement, X s'améliore en parallèle pour une optique client (mais bon il aura du mal à faire moins lourd que DirectFB) et a pour lui le fait d'avoir plus de drivers. Et puis certains mécanismes (pasteboard) sont relativement spécifiques.

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

        Posté par  . Évalué à 2.

        > mais si on passe par des librairies qui ont une version X11, l'impact négatif est limité. De plus, l'affichage déporté, même si c'est très sympa, est quand même peu utilisé, en particulier dans un usage personnel/familial.

        J'aimerai savoir si quelqu'un peut me renseigner sur le coût en mémoire/performance d'avoir une abstraction réseau ?

        Si ça coûte 1 Mo, surtout on ne touche à rien !
        Si c'est 32 Mo (à reporté au 256 Mo en moyenne sur les bécanes) supprimer cette couche peut-être intéressant. Mais qui croit que ça coûte 32 Mo ?

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

      Posté par  . Évalué à 0.

      Il y a toujours VNC. On peut imaginer un VNC pour DirectFB, il y en bien un pour Windows 98 qui n'est pourtant pas du tout fait pour l'affichage distance. D'ailleurs avec X c'est plus rapide de passer par VNC que de l'utiliser directement.

      • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

        Surtout que XFree prend du retard sur Terminal Service/Remote Desktop dispo sous Windows, pour une utilisation "bas débit" (ADSL, 16ko/s). X-Windows (de base) sur ADSL c'est injouable, Tight VNC ça rame dur (avec un bureau simple) et c'est super laid (avec une compression max pour avoir une vitesse maximale).
        Faudra que j'essaye DXPC...

        • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

          Posté par  . Évalué à 3.

          Le truc de NoMachine marche très bien, et il y a des bibliothèques en GPL. Je me demande si quelqu'un a commencé un projet pour créer un client et un serveur libres à partir des sources fournies.

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

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

      Je suis entièrement d'accord sur le fait que X doit être gardé. C'est un projet monumental et très avancé contrairement à toutes les alternatives potentielles. Il serait vraiment mal (tm) de jeter le bébé avec l'eau du bain sous pretexte que X-c'est-nul-ça-rame et ça-fait-plein-de-trucs-qui-servent-à-rien-sauf-alourdir-tout-le-système.

      Cependant, je me demande si la mentalité de la core-team de Xfree86 changera un jour. Et puis j'espérais vraiment beaucoup du coup de gueule de Keithp et de son départ (heu, virage ?). Mais www.xwin.org ne semble pas avoir fait beaucoup changer les choses. Et il semble être un peu plus abandonné chaque jour... Bon, j'ai tout à fait conscience que Keith P. à certainement beaucoup lieux à faire que d'écrire sur ce site. C'est même certaienment mieux s'il emploie se temps pour faire avancer le shmilblik. Et il restorira peut-être quelque chose de l'OLS.

  • # Fresco

    Posté par  . Évalué à 6.

    Il existe aussi Fresco ( http://www.fresco.org/(...) )

    Le projet a l'air interessant, il promet plein de bonnes choses mais avance tout doucement. :(

    • [^] # Re: Fresco

      Posté par  . Évalué à 6.

      Fresco, ça me rappelle le Hurd: un projet très prometteur, mais qui avance à un rythme désespérant. Et je dis ça sans méchanceté, je suis un fervent défenseur des principes de GNU/Hurd.

      Allez, d'ici 10 ans on sera tous sous Hurd avec un Fresco sur nos tamagoshi.

  • # Re: Qt GPL pour DirectFB en version pre-alpha

    Posté par  . Évalué à 3.

    Pour faire une console de jeux, c'est sur qu'il vaut mieux avoir quelque chose de plus légé qu'un serveur X !

    On peut citer aussi les consoles multimedia, à brancher sur la télé...

    • [^] # Re: Qt GPL pour DirectFB en version pre-alpha

      Posté par  . Évalué à 4.

      > Pour faire une console de jeux

      X11 est très rapide pour les jeux. Ça marche même nickel pour regarder un DVD. Si t'as une carte supporté par xvid, tu peux visualiser un DVD en 1600x1200 sur une petite config. Et si le besoin se fait sentir, tu peux aussi le faire à distance.

      Que du bonheur...

  • # Re: Qt GPL pour DirectFB en version pre-alpha

    Posté par  . Évalué à 2.

    dites moi si je me trompe, mais:
    * DirectFB permet d'avoir un affichage utilisant une surcouche du frameBuffer, c ca?
    * il existe pour Qt une version Embedded -justicieusement nommé Qt/Embdedded- qui est fait pour tourné sur le frame buffer directement (exemple d'utilisation: QTopia l'interface graphique des Sharps sou Linux).
    * Au sein de Qt, il existe deux classes (QGfxDriverPlugin et QGfxDriverFactory) pour rajouter des drivers graphiques.

    D'où ne serait il pas mieux qu'il fassent des plugins de drivers pour QT/Embedded,permettant ainsi de gérer les diférents cartes graphiques existante plutot que refaire Qt...

Suivre le flux des commentaires

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