Journal Développement multi-plateformes

Posté par  (site web personnel) .
Étiquettes : aucune
0
20
juil.
2004
Quelles sont les possibilités de développer des applications multi-plateformes ? Si on prends comme base les systèmes Mac OS X (bsd), Linux et Windows, qu'il y-a-t-il comme moyen de développer de petites applications communes ?

Soit on parle de programmes compilés et il faut donc que la compilation s'adapte aux plate-formes, soit on parle de languages interprétés et il faut que l'interpréteur soit présent sur les-dites plate-formes.

Java
Bon candidat mais j'ai eu sous Linux et sous Windows des problèmes pour installer la machine virtuelle ; sans parler de la version spéciale Microsoft.

XPFCE, XUL
Pas mal du tout mais fonctionne-t-il sur Mac ?
Je n'ai pas vu de manière élégante d'accéder à une base de données SQL ou SQLlite. Il existe bien un paquetage pour BSD mais je suis étonné de ne pas constater plus de capacité de XPFCE à ce niveau.

PhP, Perl, Python avec QT, Gtk
Ca devient intéressant. Surtout s'il est simple d'incorporer l'interpréteur sur un support amovible.

C++
Alors, là ! Je tire ma langue au chat :-o Je vois bien comment développer sous Linux mais sous Windows et Macintosh...


L'intérêt est de "pouvoir développer une fois et exécuter partout" en incorporant les routines et bibliothèques éventuellement sur un support amovible. Ainsi une application simple pourrait être développée puis utilisée sur ces trois plate-formes :-)

Que disent vos expériences ?

  • # C++

    Posté par  . Évalué à 3.

    avec http://www.wxwidgets.com/(...) ...

    ca marche très bien.

    • [^] # Re: C++

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

      Avec GTK/Gtkmm aussi...

      • [^] # Re: C++

        Posté par  . Évalué à 2.

        Avec QT aussi...

        (fait tourner)

        • [^] # Re: C++

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

          N'oublions pas tout de même que la license QT/Windows est payante, et non redistribuable si mes souvenirs sont exacts... (sinon moinssez). C'est pas super si on veut faire du soft GPL multi-plateforme...

          • [^] # Re: C++

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

            Payante pour une utilisation commerciale il me semble.

          • [^] # Re: C++

            Posté par  . Évalué à 1.

            Il existe une version de Qt pour win32 non payante pour usage non commercial distribuée uniquement avec le livre "C++ GUI Programming with Qt 3" ;)

          • [^] # Re: C++

            Posté par  . Évalué à 1.

            Y'a des exceptions comme le cas de Psi.... http://psi.affinix.com/(...)

          • [^] # Re: C++

            Posté par  . Évalué à 2.

            et non redistribuable
            Qu'entends tu par non redistribuable ?

            A partir du moment ou tu as achete une licence Qt pour Windows tu peux ecrire toutes les applis que tu veux et les distribuer sans probleme et sans rien devoir a trolltech.

            Par contre je me demande : le code ainsi produit ne peut pas etre GPL car il est lie avec une lib commerciale ?

          • [^] # Re: C++

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

            Ce qui l'élimine d'office. Dommage car QT semble utiliser vraiment l'objet pour la gestion des événements.

            GTk utilise des rappels pas génialement beaux. Mais bon, 'suffit d'encapsuler tout cela :-)

            • [^] # Re: C++

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

              'suffit d'encapsuler tout cela

              Ca existe et ca s'apelle GTKmm. C'est super bien fait, ca utilise un mecanisme reposant sur le paradigme signal/slot, derriere c'est fait avec des templates, et donc pas besoin d'artifices a la MOC.

              Ca s'utilise comme ca :

              
class A {
              
....
              
sigc::signal <bool, X, Y, Z>sig;
              
};
              

              
class B {
              
B( &A a){
              
a.sig.connect(sigc::mem_fun(& B::on_signal_emitted))
              
}
              
on_signal_emitted(X, Y, Z){ ... }
              
};


              du coup, si a emet le signal sig, en lui passant les parametres, b._on_signal_emitted est appelle comme il faut.

              Tout cela etant, templates oblige, completement type safe.

              Personellement, je trouve que c'est trop la classe ... Et je l'utilise !

        • [^] # Re: C++

          Posté par  . Évalué à -2.

          A part que tu peux pas faire du GPL avec sous Windows....

      • [^] # Re: C++

        Posté par  . Évalué à 3.

        En même temps GTK sous OSX c'est pas encore le top...

        • [^] # Re: C++

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

          Là, ça m'intéresse.

          As-tu des anecdotes ou conseils, à la manière du site (indiqué dans l'un des commentaires) donnant des recommandations pour faire du c++ portable ?

    • [^] # Re: C++

      Posté par  . Évalué à 1.

      Tant que tu touches pas à l'Unicode, ça marche bien...

    • [^] # Re: C++

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

      Selon ce que j'ai lu sur le site, c'est utilis{é|able]} pour les langages compilés ?

      Seulement eux ?

  • # Heu

    Posté par  . Évalué à 2.

    Ben oui mais c'est pas comme ça qu'on choisit : tu choisis ce qui convient le mieux en fonction de ce que tu développes. Tout ce que tu as cité est portable...
    XPFE marche sur Mac

  • # Portabilite portablite

    Posté par  . Évalué à 4.

    Je te livre mon humble experience:
    - Java : tant que tu fais un code "simple" il n'y a pas de probleme, mais des que tu veux faire du graphique (avec SWT), car marchera mais il faudra que tu tests sur toutes les plateformes que tu vises (on sait jamais, les bugs peuvent apparaitre selon la machine virtuelle). Mais globalement pour de petits programmes la reponse est OUI je pense que tu ne devrais pas avoir de gros problemes.

    - XUL : pas d'experience

    - Perl: casiment aucun probleme de portabilite tant que tu n'appelles pas exec ou system. Il y a aussi les fichiers qui peuvent poser probleme, mais pour la plupart de mes scripts, ils tournent nickels entre Linux et Windows. Perl/Gtk rocks. :)

    - C++: difficile a dire. Perso, en utilisant correctement la STL (pas la STL de microsoft, mais STLPort), mes petites applications OpenGL sont portables. En utilisant QT tu as une portabilite casiment a 100% si tu respecte le design. Evidement, il faut pouvoir tester car ici les bugs arriveront, c'est presque sur. Suffit d'avoir un projet QT et le projet se compilera aussi bien sous Windows que sous Linux (moyennant quelques adaptations de temps a autre). Sous MacOS aussi devrait pas poser de probleme.
    Apres le probleme de QT sous Windows, c'est la licence...

    • [^] # Re: Portabilite portablite

      Posté par  . Évalué à 2.

      pour completer ton experience:
      - Java: j ai fait un programme utilisant SWT sous linux avec une vm. apres avoir pris la derniere vm de sun, ce programme posait des problemes avec SWT sous windows et sous linux (pas les memes problemes en plus!)

      - XUL: j ai eu des petits problemes sous windows mais c etait une version ancienne de mozilla donc ca ne doit pas vouloir dire grand chose. de toutes facon XUL/... ne m'a pas convaincu dans la pratique, meme si le principe est sympa. et puis tant qu il n y aura pas de gui builder...

      - perl: oui mais c est un langage de script, donc pas forcement adapte a tout projet

      - C/C++: pas d'experience de portage sous windows, ceci dit, quand on compile avec le bons drapeaux genre -Wall -Werror -std=c99, ca doit regler 95% des problemes de portage, exemple je n ai eu qu a modifier une dizaine de lignes dans mon programme pour un portage sous solaris...

      ps: quasiment s il te plait!

      --
      pouet

  • # Développement multi-plateformes

    Posté par  . Évalué à 4.

    Mon avis :
    Prend un langage que tu connais deja parmi ceux que tu as deja cite ou parmi les suivants :

    - C++ / Qt ou Gtk ou wxWindows : Tu peux cibler pratiquement tous les OS, wxWindows a l'avantage de s'integrer au desktop en reutilisant le toolkit de l'OS, Qt est tres complet mais non libre sous windows, Gtk est libre et dispo sous toutes les plate-formes mais c'est pas vraiment de l'objet, on aime ou on aime pas. Dans tout les cas tu pourras compiler sur ces OS avec peut etre quelques adaptations a faire d'un os a l'autre, mais en general, en faisant du code portable, il ne devrait pas y avoir de probleme.

    - un langage interprete, encore une fois prend celui que tu connais et utilise wxWindows. Avantage, tu es sur que ca passera parfaitement sur tous les OS supporte par l'interpreteur. Le couple python/wxWindows est parfait pour ce genre d'applis (petite et multiplateforme vite developpe pour un besoin specifique)

    - Java avec les avantages des langages interpretes et compiles, si tu le couples avec SWT ton appli s'integrera parfaitement au desktop

    - Mono, encore tres jeune mais surtout cible pour l'instant peu de plateforme

    - GNUStep / Objective C : ca vaut le detour honnetement !

    • [^] # GNUStep/Obj-C

      Posté par  . Évalué à 2.

      Le support de GNUStep sous windows, cela vaut quoi ?

      • [^] # Re: GNUStep/Obj-C

        Posté par  . Évalué à 2.

        support de GNUStep sous windows, cela vaut quoi ?
        A mon avis, ce n'est pas encore envisageable. Il faudra en effet utiliser cingwin et cpgnie pour pouvoir faire tourner des applis utilisant gnustep-gui (cad toutes les IHM graphique). Donc c'est pas vraiment top...

        cf. http://www.gnustep.org/information/machines_toc.html(...)

        Et le jour ou on pourra se passer totalement de cygwin le principal defaut sera le manque d'integration au bureau.

        Mais ca avance !

        Pour une application ne ciblant que MacOS et Unix et pour peux que l'on maitrise bien la POO, je pense que GNUStep est une veritable alternative a Qt ou Gtk par exemple.

    • [^] # Re: Développement multi-plateformes

      Posté par  . Évalué à 1.

      n'oublie pas : s/wxWindows/wxWidgets/ :-)

      http://www.wxwidgets.com/(...)

    • [^] # Re: Développement multi-plateformes

      Posté par  . Évalué à 2.

      wxWindows
      wxWidgets. Et de ce que j'en ai vu, supporte mal l'Unicode et GTK 2

      Qt
      Ne permet pas de faire un logiciel GPL sous Windows

      Gtk
      Nécessite un serveur X sous Mac OSX... Pas encore le top

  • # mon avis

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

    Mon expérience me dit qu'il ne faut pas trop te baser sur un langage, la plupart peuvent être utilisés sur la plupart des OS, mais sur des API indépendants de l'OS.
    En fait le principal soucis vient de l'interface graphique, et là il y a 2 écoles :
    - même code pour toutes les plateformes :
    - avantages : 100% portable, diminue le boulot du programmeur
    - inconvénients : malgrès ce que evulent faire croirent leurs concepteurs, il est impossible d'avoir à la fois un toolkit graphique portable et puissant qui utilise toutes les possibilités de l'OS cible : bien que visuellement corrects lorsqu'ils utilisent directement les API graphique de l'OS cible, ils leurs manquent soient des fonctionnalités (parcque il fau prendre les facteurs communs), soit émulés (beaucoup moins classs déjà) et surtout ils ne sont pas du tout intégrés à l'environnement (parcque si c'était juste une histoire de skin je verrais vraiment pas l'intérêt d'avoir conçu pleins de toolkit différents, de charte graphique, ou tout simplement d'environnement)
    - exemples : Java, Python+Qt, Perl+GTK, etc.

    - même code pour l'application, mais pas pour la couche graphique :
    - avantages : tu garanties l'intégration visuelle et ergonomique de ton application, ce qui est beaucoup plus "professionnel", notamment pour des applications desktop destinées à monsieur-tout-le-monde.
    - inconvénients : il faut bien séparer l'interface graphique du reste de l'application (mais à vrai dire celà ne fera qu'augmenter la qualité de l'architecture de l'appli) et bien sûr il faut réécrire l'interface pour chaque environnement, ce qui est plus long à programmer et à maintenir si l'interface est amenée à changer.
    - exemples : N'importe quel langage "portable" + toolkit spécifique pour chaque plateforme Qt/Gtk/WinForms/Cocoa

    Mes conseils :
    Il est intéressant de noter que tu peux envisager la deuxième solution en utilisant un toolkit "portable" comme Qt ou GTK que l'on retrouve sur de nombreuses plateforme, ce qui te permet d'obtenir une application dans un premier temps 100% portable même si elle n'est pas intégrée. Tu pourras dans un 2nd temps réécrire l'interface spécifique. Utilise au passage un langage "portable" , soit interprété (Python, Perl, Ruby, etc.), soit utilisant un code intermédiaire (Java, C#).
    C++ peut être une solution mais tu devras recompiler pour chaque plateforme, le code binaire n'étant pas vraiment portable, surtout lorsque tu changes d'architecture (par exemple sur Mac).
    Par contre je vois pas trop l'intérêt de PHP qui a pour objectif d'être utilisé dans le cadre d'une application web. Je ne te conseillerai XUL et tout ce qui va avec seulement si ton application est là encore orientée web, parcque pour le moment les API sont un peu limité si on sort de ce cadre.
    Perso j'utilise Mono et une couche graphique différence pour chaque plateforme.

    • [^] # Re: mon avis

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

      Merci pour ta réponse :-)

      Je note bien la séparation interface graphique et application.

      >Par contre je vois pas trop l'intérêt de PHP....

      PHP - au même titre que python ou perl - peut être utilisé pour faire du développement. Avec "php-gtk" il y a possibilité d'utiliser gtk pour l'interface graphique.

      L'un des avantages que je peux voir et qu'il sera ensuite relativement facile d'intégrer ce genre d'application dans un site web. Sans compter l'accès aux bases de données.

  • # concernant xul et c++

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

    D'une part, XUL existe sous mac et plein d'autres plateformes.

    Les développeurs de mozilla ont été confronté à ce problème de portabilité du C++ (oui, tout le navigateur n'est pas codé en javascript ou en XUL ;-)
    Ils ont même ecrit un petit guide sur la portabilité du code C++ : quels sont les rêgles à respecter en C++ pour que le code soit portable sur un maximum de plateforme :

    http://www.mozilla.org/hacking/portable-cpp.html(...)

  • # Une expérience.

    Posté par  . Évalué à 10.

    Voilà un petit rapport d'expérience d'applis multi-plateformes en...C.

    Le projet était de développer un outil de configuration graphique (souris, menu, bouton...) permettant de configurer un modèle océanique de vagues sous Linux (et sous Windows, au cas ou).

    photo (sous win): http://dpithon.free.fr/gtkwin.jpg(...)

    Le langage était donc le C, la librairie graphique Gtk2 avec la palette d'outils suivante:

    - Glade, qui s'est révélé indispensable, l'interface compte la bagatelle de 1500 widgets
    - MinGW et MSYS, pour windows qui t'offre un compilateur gcc "natif" (sans couche intermédiaire comme peut en offrir cygwin) et un environement UNIX-like (bash, ls, make...)
    - UNIX est un environement de développement en soi donc pas d'IDE particuliers (vim + cmd UNIX + pipe + script shell = bonheur)
    - Un petit CVS au milieu permet de développer indifférement sur Windows ou sur Linux (ou plutôt de faire des "cvs update; make" sur Windows)

    J'ai donc construit l'interface intégralement avec Glade (le fichier glade pèse son Méga octet). L'auto-connection évenements/fonctions callbacks depuis Glade fonctione merveilleusement bien sous Linux et sous Windows... (en déclarant les fonctions callbacks __declspec(dllexport) pour windows).

    L'ensemble pèse 11500 lignes. 50 lignes de code sont dédiées à windows (pour les I/O).

    J'ai produit un petit doc pour l'installation et l'utilisation de GTK2/LibGlade sur Win32 ici -> http://www.boost-technologies.com/gtkwin/(...)
    Au cas ou ça interesserait quelqu'un

  • # Python

    Posté par  . Évalué à 2.

    Mon avis: AnyGui (http://anygui.sourceforge.net/(...)) + Python. Pas essayé, mais étant donné qu'il permet le choix du toolkit il doit vraiment être portable :)

  • # http://epeios.org/ pour le C++.

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

    Le projet Epeios (http://epeios.org/(...)) propose des bibliothèques généralistes, mais également dédiées au multitâche, aux sockets et autres joyeusetés non disponibles avec les bibliothèques C++ ou C standards. Mais elles ne gèrent rien de ce qui touche aux interfaces graphiques, exception faite des interfaces WEB. Ces bibliothèques, qui se présentent uniquement sous forme de sources C++, tournent actuellement sous Windows (Visual C++, Metrowerks Codewarrior, gcc/cygwin, ... ) et Linux (gcc :-> ). Leur adaptation à la plateforme MAC devrait intervenir prochainement.

    Les sources s'appuyant sur ces bibliothèques peuvent être compilés sous l'une ou l'autre des plateformes sans avoir à être retouchés. Elles sont actuellement utilisées pour développer une application destinés à tourner sous Windows, Linux et MAC (d'où leur future adaptation à cette plateforme). Développée sous Windows, l'application en question tourne effectivement sans modification aucune sous Linux. La portabilité est donc vraiment une réalité avec ces bibliothèques.

    Le site n'est pas mis souvent à jour, n'étant gèré que par une seule personne, qui se trouve être également l'unique développeur de ces bibliothèques. Bien que disponibles sous licence GNU GPL, ces bibliothèques n'ont guère rencontrés de succés auprés de la communauté du Logiciel Libre. Elles ne sont maintenues que parce que l'auteur les utilisent pour ses propres développements et ceux réalisés dans le cadre de sa profession.

    Pour nous émanciper des géants du numérique : Zelbinium !

  • # python et wxpython

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

    Si j'étais toi, je choisirai, sans aucun doute, python et wxpython ...
    c'est ce qui réponds le mieux à ça :

    "L'intérêt est de "pouvoir développer une fois et exécuter partout" en incorporant les routines et bibliothèques éventuellement sur un support amovible"

    - python.org : car c'est bien multiplateforme, et intègre de base toute une flopée de librairies, permettant de faire pas mal de chose

    - wxpython.org : qui est l'équivalent de wxwidgets (ancien wxwindows), mais pour python ... son énorme avantage, est qu'il reprends le look de l'os hote (ainsi t'auras les MFC sous win, gtk sous *nux, cocoa sous os x) .. tout en utilisant un set d'api unique ... et comme dirait "timaniac" : forcément nivellé par le bas ... mais déjà nettement suffisant pour faire qqchose d'utilisable ...

    evidemment, il faut aussi "coder proprement", sans appel systèmes (exec/system/...), sans utiliser de lib spécifique à une plateforme (win32api, ...) ... et ça marchera à 99% sure ...

    (les 1%, étant les cas mal documentés de certaines libs, dans wxpython par exemple, cependant, en prennant des pincettes, ça va ...)

    Attention, je suis un partisan qui pense que le tout QT, ou le tout GTK sur les trois plateformes n'est pas excellent (y a qu'à voir gtk2 sous win, avec le look "win" : c'est très lourd, et c'est pas très beau/réaliste)
    Je suis un partisan de wxwidget/wxpython ...qui à mon sens, est l'idée la plus sympa ... et contente les end users qui veulent des interfaces natives ... un set d'api pour tous les widgets/plateformes, même s'il faut niveller par le bas, wxwidget/wxpython est bien avancé ... et promet bien plus dans le future ... (grosse communauté active)

  • # Développement multi-plateformes

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

    Bien qu'il soit pas présent sur Mac et manque un peu de support / doc / maturité, lazarus est un beau projet multi-plateforme basé sur fpc.

    Je trouve qu'il a sa place ici.

    http://www.lazarus.freepascal.org/(...)

Suivre le flux des commentaires

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