Lazarus 0.9.28

Posté par  . Modéré par Florent Zara.
Étiquettes :
17
16
oct.
2009
Technologie
Lazarus est un EDI complet pour développer en FreePascal, libre (GPL + LGPL). Il permet de développer simplement et rapidement avec autre chose que du C. Ce n'est pas une simple implémentation de Delphi en libre. Certes, il est fourni avec moins d'outils et la version 1.0 sera comparable à Delphi 7.0, mais Lazarus s'appuie sur le slogan de FreePascal : « Write once, compile everywhere ».

Grâce à Lazarus, vos applications graphiques pourront être exécutées nativement sous Windows/Linux/MacOS... Pour les systèmes de type Unix, il s'appuie sur la bibliothèque GTK+ ou Qt. L'avantage de Lazarus, c'est qu'il embarque de très nombreux composants en natif et que sa réputation est telle que de gros projets comme Zeos ou Synapse fonctionnent grâce à lui. Le développement est simple et rapide.

Lazarus vient de sortir en version 0.9.28. Les changements principaux sont :
  • utilisation de GTK+ par défaut sous Linux,
  • implémentation de TCalendar, TFloatSpinEdit, TOpenDialog et TSaveDialog sous Windows CE,
  • ajout de TFrame, TShellTreeView, TShellListView, TFilterComboBox,
  • quelques modifications pour être plus compatible avec Delphi,
  • amélioration de l'EDI,
  • utilisation de FreePascal 2.2.4
Pour un rapport complet, voir les release notes de cette version.

Alors, si vous ne connaissez pas le Pascal, Lazarus est un bon moyen de le découvrir et de l'adopter.

Aller plus loin

  • # Aucun rapport

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

    Lazarus, c'est aussi un addon firefox qui sauve les textes des formulaires.
    Très pratique quand ça plante et qu'on doit tout retaper !
    Ce Lazar (ou ce lascar), il ressuscite les formulaires morts !
    (Incidemment, il ne marche pas sur dlfp…)

    Bon, et le Lazarus de Pascal, pourquoi ce nom ?
    • [^] # Re: Aucun rapport

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

      Je pense que cela vient de Kylix ressuscité.
      Kylix étant la version Delphi de Borland mais pour Linux (avec comme base une vielle version de Qt).
      Je pense que ce qui n'a fait le succès de Kylix, c'est qu'il ne marchait que sous Redhat.
      J'avais essayé de l'installé sous Debian, j'avais quelque problème d'unicode, de compilation, l'application était plus moche que sur Redhat.
      Et la version de Redhat qu'il fallait était assez dépassé (à mes souvenirs)
      • [^] # Re: Aucun rapport

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

        >Je pense que cela vient de Kylix ressuscité

        Lazarus n'a historiquement rien à voir avec Kylix. Le projet à commencé en 1999 comme un ré-implémentation du pascal objet et du RAD de Borland. Kylix date de 2001.


        C'est un projet qui a ses adeptes :
        http://wiki.lazarus.freepascal.org/Lazarus_Application_Galle(...)
        http://wiki.lazarus.freepascal.org/Projects_using_Lazarus
      • [^] # Re: Aucun rapport

        Posté par  . Évalué à 1.

        Il marchait aussi sous mandrake. Mais même soucis : moche et nécessitait une antique version. Alors que dans le même temps Lazarus était fonctionnel, et plus jolie. Il était juste pas suffisament compatible avec delphi pour mes tout petits projets delphi.
      • [^] # Toujours aucun rapport…

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

        Et la version de Redhat qu'il fallait était assez dépassée

        Ça, c’est le problème classique du propriétaire sous Linux. Pour avoir acheté une carte-mère VIA, j’en sais quelque chose (compatibilité des drivers fermés).

        Tant que le monde propriétaire n’aura pas compris que Linux évolue plus vite que Windows (niveau API), ils seront en échec. NVidia a compris, et pour eux ça marche plutôt bien.

        Yves.
        • [^] # Re: Toujours aucun rapport…

          Posté par  . Évalué à 8.

          > NVidia a compris, et pour eux ça marche plutôt bien.
          C'est une blague ?

          Ça marche tellement bien, que les mises à jours du noyau ou de X cassent régulièrement leurs pilotes propriétaires de merde, qu'ils maintiennent leur propre GL, GLX, ils n'utilisent pas DRI.
          Certes, ils sont plutôt réactifs pour des éditeurs propriétaires mais ça reste merdique, tu remercieras les distributeurs qui doivent faire gaffe lors des mises à jours, les empaqueteurs qui font un boulot énorme d'intégration.
          Le pilote nVidia (et les autres) qui écrase les libs systèmes, c'est certain, ils ont tout compris et ça marchera très bien jusqu'au jour où tu voudras changer de carte graphique.

          Des trois principaux fournisseurs de GPU, nVidia est le moins compatible avec le libre.
          ATI joue le jeu, ils ont libérés la documentation, les pilotes Radeon/RadeonHD avancent bien. Intel fournit des pilotes libres pour ses GPU depuis quelques années, ils sont trés actifs dans X, en revanche pas de documentation, le GMA500 (un GPU acheté à PowerVR, une boite d'enflures avec un support Linux et autres systèmes libres de haut vol)

          La seule utilité des pilotes propriétaires, c'est de dépanner ceux qui ont la malchance d'avoir du matériel non supporté. Vu la situation, il faut privilégier l'achat de GPU ATI ou Intel (sauf la crotte GMA500) et envoyer chier nVidia.
          • [^] # Re: Toujours aucun rapport…

            Posté par  . Évalué à 0.

            Le problème des cartes ATI est que pour les drivers c'est encore trop la roulette russe. Le driver FGLRX est nécessaire pour les Radeon 4xxx et est assez buggé, et pour le reste le driver Radeon ne permet pas toujours de profiter du bureau 3D car trop buggé : ex, pas de 3D possible sous Kubuntu Jaunty avec le driver Radeon car ça cause des freeze pas possible.

            Si les drivers étaient mieux je prendrais sans hésiter du KDE, mais c'est vrai que sous Linux les drivers NVidia restent les meilleurs pour la 3D, bien qu'ils aient une mentalité pourrie vis-à-vis du libre.
            • [^] # Re: Toujours aucun rapport…

              Posté par  . Évalué à 7.

              En même temps, en continuant de recommander les cartes nVidia, faut se poser la question de quel message on envoit à nVidia mais également ATI et Intel ?
              Avant d'acheter une nVidia, faut bien se poser la question de savoir si une ATI ou un chipset Intel ne conviendrait pas avant. Soit on est libriste, soit on est con-sommateur, mais pas seulement encourager les fabricants qui fournissent la documentation, des pilotes libres, il faut leur donner la préférence. On donne un signal fort à ceux qui ne le font pas, à ceux qui sont tentés de le faire également.

              Si tu veux juste utiliser un bureau composite, un stupide GMA 950 suffit. Tu veux faire du Blender, c'est compréhensible que tu t'orienterais vers une nVidia haut de gamme. Le but de la manoeuvre ce n'est pas d'être sectaire, mais de faire avancer le logiciel libre.
              • [^] # Re: Toujours aucun rapport…

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

                Comme tu le dis, dans le milieu professionnel (recherche publique), je ne prends que des nvidia. Ce sont les seules cartes 3D qui marchent. ATI, j'en achète une tous les deux ans et je suis obligé de racheter ensuite chez ldlc une nvidia car ca plante régulièrement.

                Il est clair que d'un point de vue du libre, c'est nul. Je ne demande pas à ATI d'avoir des perf de folie mais tout simplement de ne pas planter. J'ai un taux de plantage bien trop grand pour basculer mon parc de machine sous ATI dans le futur.
                • [^] # Re: Toujours aucun rapport…

                  Posté par  . Évalué à 1.

                  Je plussoie fortement.
                  • [^] # Re: Toujours aucun rapport…

                    Posté par  . Évalué à 1.

                    D'ailleurs, aucun driver n'est dispo aux dernières nouvelles pour faire tourner l'accélération 3D des cartes ATI « récentes ». Le driver proprio ne tourne que pour les noyaux antérieurs au 2.6.28, les drivers libres ne sont pas assez actifs pour gérer ça.
                    • [^] # Re: Toujours aucun rapport…

                      Posté par  . Évalué à 1.

                      je te rassure, y'a également que dalle pour les cartes jugées « vieilles », lire avant le rachat de ATI par AMD, par exemple
                • [^] # Re: Toujours aucun rapport…

                  Posté par  . Évalué à 3.

                  À noter que tu parles du driver proprio, je suppose. Du ATI avec driver libre ça marche très bien (j'en ai eu deux depuis des années) et ça ne plante pas, si on sait se passer de la 3D.
    • [^] # Re: Aucun rapport

      Posté par  . Évalué à 3.

      "Ce Lazar (ou ce lascar), il ressuscite les formulaires morts !"
      Ben apparemment, Lazare ne ressuscite pas les banquiers morts[1]...



      1 http://www.challenges.fr/actualites/finance_et_marches/20091(...)
  • # Write once, compile everywhere

    Posté par  . Évalué à 2.

    <mode="grognon">Il y a encore des gens pour croire à ce genre de choses ??!?</mode>

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Write once, compile everywhere

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

      Avec Qt, on converge vers ça de plus en plus.
      Personnellement, à part pour l'écriture de mes .pro ou mes CMakeLists.txt, j'ai rarement du code natif à une platforme à écrire...
      • [^] # Re: Write once, compile everywhere

        Posté par  . Évalué à 4.

        C'est vrai que Qt se débrouille plutot bien.

        Mais une application multiplateforme se repère toujours, même en faisant des efforts d'intégration spécifiques à chaque plateforme cible. C'est structurel puisqu'il faut s'aligner sur le plus petit dénominateur commun entre les différentes plateformes; ça empêche d'exploiter leurs fonctionnalités avancées respectives.

        Sauf à faire un coeur multi-plateforme et des adaptations (pas forcément légères) spécifiques à chaque plateforme.

        Exemples : l'intégration au carnet d'adresse, le look&feel (ne serait-ce qu'au niveau des icones embarquées dans une application graphique), etc.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Write once, compile everywhere

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


          Mais une application multiplateforme se repère toujours, même en faisant des efforts d'intégration spécifiques à chaque plateforme cible. C'est structurel puisqu'il faut s'aligner sur le plus petit dénominateur commun entre les différentes plateformes; ça empêche d'exploiter leurs fonctionnalités avancées respectives.


          Au fil des versions de Qt, l'équipe de développement essaye de factoriser les concepts, même commun à 2 ou 3 platformes maximum. Je pense au QSystemTrayIcon qui est arrivé en Qt4.2 et qui n'a pas de sens sous Mac par exemple (il suffit de tester QSystemTrayIcon::isSystemTrayAvailable () pour s'assurer que si un jour la TrayIcon est dispo sur une platforme, on aura rien à changer (en théorie) pour que ça fonctionne).
          Bon effectivement, au niveau des concepts et des couches de plus haut niveau comme le carnet d'adresse, là effectivement pas de miracle...
        • [^] # Re: Write once, compile everywhere

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

          Je trouve qu'il y a eu beaucoup d'amélioration du ce point dans différents projets.

          Je n'utilise pas Qt, car je n'ai jamais aimé, et passer par le moc me rebute (c'est vraiment subjectif, je n'ai pas de grief contre les Qtistes). Par contre, je suis l'évolution de certains projets, même de loin, et si tu regardes un peu le code d'Ultimate++ (http://ultimatepp.org), tu verras que non seulement on arrive à du code utilisateur indépendant de la plateforme, mais la conception même du framework facilite la mise à disposition de parties spécifiques rendue indépendantes elles-aussi.

          Par exemple, le support de Gtk+ a été introduit après coup. Et si le toolkit utilise son propre moteur de widgets, il s'intègre au look des applications Gtk+ (il lit les infos du thème), et cela, sans que le développeur d'appli n'ait quoi que ce soit à coder.

          Bien-sûr, ce n'est pas 100% parfait, mais comparé à il y a 10 ans, voire même 5 ans, on arrive à des outils qui facilitent vraiment le Write once, compile everywhere, avec un langage puissant (C++) et très utilisé.
      • [^] # Re: Write once, compile everywhere

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

        Ah, Qt...

        Oui, ça améliore grandement le "compile everywhere", je m'y suis mis, et c'est pas mal pour ne pas avoir à se taper 36 solutions de GUI.
        Reste que du coup, on voit quand même que c'est du Qt et pas une interface native, genre :
        http://qt.nokia.com/doc/4.5/images/windowsxp-menu.png
        (si rien ne vous choque, regardez la version linux http://qt.nokia.com/doc/4.5/images/plastique-menu.png )
        donc il y a quand meme un #ifdef WIN32 (ne pas utiliser le bouton radio dans un menu même si c'est classique car c'est peu compréhensible par le client comme affiché par Qt, on doit se démerder autrement. Ah vérifier quand même que c'est sous WinXP, parce que sous Vista c'est bon, va comprendre)

        Bon, j'avoue, pour le moment c'est le seul truc qui m'embête côté intégration dans l'OS, mais ils font fort pour le petit hic (surtout que les images viennent du site de Qt, donc ils l'assument bien...)

        Bon, quand même : Qt c'est bon, mangez-en!
        • [^] # apparence ...

          Posté par  . Évalué à 2.

          Est-ce que l'utilisateur final, genre l'utilisateur basique, il y a prête tellement attention où il fait comme d'habitude : il se débrouille ?
          • [^] # Re: apparence ...

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

            Nous n'avons certainement pas la même vision : pour moi, l'expérience utilisateur est primordiale (même si pour le moment, je laisse un peu à désirer de ce côté, c'est un but).
            "Il se débrouille" n'est pas le plus acceptable.

            Si j'avais le choix, je ferai un GUI natif par OS, maintenant je fais avec les ressources que j'ai. Mais en aucun cas, j'estime que c'est "normal", ça reste un bug/problème (parmi plein d'autres)
            • [^] # Re: apparence ...

              Posté par  . Évalué à -1.

              Après pour faire des GUI natifs (presque) partout sans trop te casser la tête, tu as toujours la solution Java/Swing. Si, je suis sérieux, avec deux lignes de code dans le main() du programme on y arrive très vite, et le résultat est plutôt sympa quand même même si ce n'est pas l'idéal.
              • [^] # Re: apparence ...

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

                J'aimerais bien savoir en quoi Java prend mieux en compte les problématiques natives de haut niveau de chaque plateforme que Qt, raconte-moi, ça m'intéresse.
        • [^] # Re: Write once, compile everywhere

          Posté par  . Évalué à 0.

          fais remonter, puisque c'est un bug.
  • # Zeos, synapse ?...pfff...

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

    le vrai logiciel qui utilise ça... c'est.......................

    skychart, cartes du ciel :)
    http://www.ap-i.net/skychart

    l'atlas virtuel de la Lune !!!!!!!!!!!!
    http://www.ap-i.net/avl/fr/start

    bref !!! Bravo Patrick !!!!!!! (a migré ces deux logiciels depuis au moins 4 ans de delphi à Lazarus )

Suivre le flux des commentaires

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