portage appli Windows pour OSX et Linux

[dafoo]

Bonjour messieurs dames,

Je suis a la recherche d informations sur les differentes méthodes existantes pour porter une application windows, sur Linux et OS X.

J ai compris que le fossé technique separant OSX de Linux n est pas aussi grande que celui séparant Windows du monde Unix, que cela depend enormement du langage de programmation, des APIs employées a l'origine... Dans mon cas, il s agit d une app ecrite en c++ avec Studio.NET (je crois).

Je ne suis pas programmateur, juste un passionné du mac, interessé par le sujet de la portabilité d'un environnement à un autre.

Alors, Existe-t-il un environnement de programmation permettant a terme de disposer d'un seul code, que l on recompilerait a loisir pour windows, OS X et Linux tout en gardant les memes fonctionabilités ?

Si vous avez de quoi alimenter ma reflexion et éclairer ma lanterne...
1000 merci et a bientot,

 

[GrandGibus]

C'est vrai, tu as raison: le fossé technique séparant OSX de Linux n'est pas aussi grand que celui séparant Windows du monde Unix. Cependant, il convient de ne pas confondre language de programmation et environnement de developpement:

Dans ce que tu as écrit, il y a les deux: Tu pourras facilement porter un programme écrit en C++ (ansi) faisant appel à des librairies standards juste en le recompilant sur la plateforme cible.

Par contre, tu n'auras pas le même environnement de developpement. .net est spécifique à windows ! De plus, il apparaît peu probable (à mon avis) que l'appli écrite sous .net soit écrite qu'avec des librairies standard

d'où un portage improbable.

Dernier point, l'environement de programmation xcode est fourni avec Mac OS X et est gratuit (contrairement à m$ où il faut bourse délier). Il te permet en outre de gérer des projet sous différents langages.


gg


P.S. sinon, vu ta problématique multi-platforme, t'as envisagé Java (et arretez de dire que c'est lent

 

[maousse]

P.S. sinon, vu ta problématique multi-platforme, t'as envisagé Java (et arretez de dire que c'est lent

et pourquoi pas XUL, ça fonctionne bien avec mozilla et consorts ? En fait, je ne sais pas grand chose des détails, et ce sujet m'intéresse aussi...

 

[SuperCed]

Comme dit plus haut, si tu fait du code C ou C++ ANSI pur, pas de problème pour recompiler.
Par contre, à partir du moment ou tu utilises des librairies spécifique à Windows (MFC, Win32, .net), alors cette partie là ne fonctionnera pas.

Pour faire du code portable, tu peux utiliser Java, ou alors des librairies C/C++ existantes sur toutes les plateformes : Qt, Gtk, et d'autres que je ne connais pas...

Ya aussi RealBasic, mais ça marche que moyennement car c'est très bugué (enfin, c'est mon avis personnel).

 

[plumber]

je crois qu'il y a un projet .net framework sur osx pour faciliter les portages

 

[SuperCed]

En effet, il existe un framework .net pour OS X, cependant, celui-ci est très limité et ne possède pas toutes les classes de la version Windows.

 

[dafoo]

je me sens un peu moins bete ce midi..merci a vous.

Recapitulons: alors si j ai bien compris, il faut reprendre le code d origine de l appli (C++) et modifier les APIs, en s orientant vers des bibliotheques standards fonctionnant sur les autres OS (type QT, GTK, et ???) .
Tout bon jusque la ?

Mais qu en sera-t-il de l interface graphique ?
Comme chaque OS repond a une logique bien precise, ne faudrait il pas produire une interface propre a chaque version ? ou bien, est il envisageable de ne developper qu une seule interface, qui sera, de faite, pas aussi "lechee" qu un soft developper pour OS X / Aqua.

Maousse: je ne pense pas que XUL convienne, car d'apres ce que j ai compris sur xulplanet.com, XUL conviendrait d avantage a des appications Internet.


Quid de Java ?
Pourquoi ne pas faire appel a Java. Avant d aller plus loin, je dois vous expliquer un peu dans quel cadre est envisagee l application.
Cette appli est un logiciel de geomatique, il permet donc de visualiser/analyser/produire des donnees geographiques: cartes, images sat, photos aeriennes assez lourdes (plusieurs mega chacune) et qui devront s afficher en meme temps. Ces images seront gerees par couche, a l instar du concept de "Layers" cher a Photoshop.

Java ne serait-il pas trop limite pour gerer autant de resources graphiques? (pas frapper fort please.. GrandGibus

)

A vos claviers !

 

[SuperCed]

Il est vrai que le problème de Java, c'est que c'est lent.
Cependant, il est plus facile de bien programmer en Java qu'en C++. Ce qui signifie qu'un programme bien programmé en Java est préférable à un mauvais code C ou C++.
Si tu utilises Qt, normalement, tu devrais avoir une interface native pour chaque système, sans effectuer de modif dans le code. Tu devras compiler une fois ton même code pour chaque plateforme. Avec Java, tu compiles une seule fois au total pour toutes les plateformes.
L'autre intérêt de Java, c'est que c'est super bien documenté, stable, et éprouvé. Par contre, il faut réécrire l'intégralité du code.

Dernière possibilité si l'interface de ton logiciel est simpliste et qu'elle est surtout composé d'images : GLUT + OpenGL.Très portable, une simple recompilation suffit dans la plupart des cas.

 

[GrandGibus]

Tout dépend de comment est foutu ton projet d'origine:

si l'architecture présente une bonne distinction entre la logique métier (algos, calculs) et la couche de présentation (réalisée avec .net ou mfc), tu pourras sans trop de difficulté faire le portage de ta couche de présentation en Java ou xul ou tout autre langage qui offre un pont vers cette fameuse couche métier.

Par exemple, tu réalises l'ihm en java (swing), un pont Jni vers ta couche métier et le tour est joué. Quand à dire que Swing est lent, je dirai plutôt qu'il est moins rapide qu'une ihm native (mais c'est normal).

Quoiqu'il en soit, tu auras toujours tout à gagner à bien séparer ta couche de présentation de ta couche métier. Il y a plein de patterns qui peuvent t'aider lors de la conception (MVC, h-MVC sont les plus connus).

Dernière idée reçue: on peut aussi écrire de la merde en Java... comme dans tous les autres langages

 

[plumber]

il est mieux d'utiliser awt avec des construction simple et propre
tu es sur d'avoir une appli a peu pre potable partout en utilisant le system ui

par contre swing en interface c'est moche trop compliqué c'est rigolo
mais c'est pas beau qu'esqu'on en a foutre de mettre des fonds dans des textarea

de beau png comme gise d'icon avec awt c'est beau avec swing c'est moche

Dernière idée reçue: on peut aussi écrire de la merde en Java... comme dans tous les autres langages

oUI SWING graphic interface est un example parfait


mais bon il vaut mieux faire un core portable d'appli
que tu recompile pour chaque OS avec les petites methodes

pui tu fais deux GUI toolkit

Cocoa , XFree

ps c'est assez simple de porter du windoz

pourquoi ? parce que les possibilités sont reduite arf

 

[GrandGibus]

Cependant, on ne peut pas nier que les dernières versions du JDK sont en net progré notament au niveau de Swing qui maintenant intègre les look and feel natifs ainsi que les skins !!!

Il va devenir de plus en plus difficile de différencier une appli swing d'une appli cocoa (mis à part le temps de démarrage

Par contre, si on a des talents de graphiste, alors, là, je m'incline... on peut pas lutter (pour ma part je dessine comme une merde et suis incapable de faire la moindre icone)