Un choix difficil à faire...

[elnemo]

Salut à tous,

A force de rechercher sur Google une solution à mon problème, je me dirige vers les forums de MacG pour tenter d'obtenrir de véritables réponses.

Le problème est simple

enfin il me semblait que le pb était simple avant de commener à faire des recherches.

J'explique : J'aimerais développer un logiciel type bureautique pour des utilisateurs finaux tournant essentiellement sous Windows... Cependant, comme j'aime passionément la pomme j'aimerais pour des raisons personnelles faire tourner ce soft sur mon mac

Le choix du langage
Ce langage devrait pouvoir tourner sur les deux environnements, le choix le plus judicieux serait d'écrir ce soft en java !

Le problème est pour la construction de l'interface graphique... je n'ai pas envis d'avoir une interface en java du type SWING ou AWT qui à mon gout est particulièrement mal réussi, d'autant plus que je ne me sens pas très bien face à un soft qui n'a pas la même tronche que le reste du système.

Bref, je ne sais pas trop quel direction choisir... développer sur PC et me demerder pour faire tourner le logiciel sous Mac

Bizarement, le nombre d'articles sur le portage d'appli Win vers Mac est bcp plus important que l'inverse...

Si j'ai pu donner l'impression que le choix Java me semblé être un peut merdique, ça vient escenciellement de l'interface graphique que le logiciel aurait, et non du code lui même (code qui est plus facile pour moi à générer que du C++ par exemple)

Merci de m'aider dans ma recherche

PS : La configuration récente d'un PC m'a montré à quel point j'aimais mon Mac

Même si ça n'a rien à voir avec ce thread, je voulais juste le signaler !

 

[elnemo]

Il y a un post sur le sujet du portage un peut plus bas... mais ma question reste pausée !

Merci à tous

 

[Didier Guillion]

Bonjour,

Je me suis également posé ce problème en 1991... Je ne pense pas pouvoir t'apporter de reelle solution miracle, juste, peut etre, un retour d'expérience puisque je développe sur des codes compatibles Mac OS/Windows depuis cette date.

Quel que soit le langage que tu choisit au final, ce qui importe avant tout c'est l'analyse que tu vas donner à ton probleme. Il est primordial dans ton cas de séparer la partie interface graphique et la partie logique de ton programme.

D'une certaine maniere et si l'on se place a un niveau assez haut, Windows et Mac OS sont assez similaire dans les accés à l'interface.
Ils utilisent tous les deux fenetres, menus, bouton, etc. La majeure difference est que Mac OS propose une barre de menu globale alors que dans Windows, elle est par application.
Ensuite une application Windows peut ouvrir ses fenetres dans son propre espace de travail. Un peu comme si chaque application Windows travaillait dans son propre "bureau".

En creant cette "couche", une interface entre toi et les acces systeme à l'interface, tu deviens independant du systeme.

Apres tout dépend de tes besoins en matiere d'interface, si tu n'est pas trop exigeant, cela doit pouvoir se faire avec un minimum d'effort.


Cordialement

PS: Un autre conseil, si tu choisit le C++, vérifie bien la compatibilité entre la version Mac et PC.

 

[Manu]

Pour t'aider à choisir, je vais plutôt te raconter mon expérience. A toi de voir si cela peut te donner une idée ne fût ce pour avancer dans tes invetigations. J'ai développer jadis sous Windows en utilisant les environnement de type L4G comme SQLWindows de Gupta. Ensuite je me suis interessé à la technologie objet et à ce qu'elle apportait au développement d'applications. J'ai été très déçu par les apis C++ en général. C'est NeXTSTEP et son api objet en objective-c qui m'a vraiment réconcilié avc l'orienté objet.En effet c'était la première fois que dans le développement d'application, l'aspect de l'interface graphique était pris en compte non seulement dans les frameworks, mais dans le concept de développement tout entier. C'est le MVC ibnitié avant NeXT par SmallTalk. Ce paradigme en schématisant permet de décomposer une appli en 3 parties un modèle (les données utilisées), une vue (l'interface homme-applition), et le controleur, qui fait le lien entre les deux. En outre sous NeXSTEP (cocoa aujourd'hui), la mise en oeuvre de ce concept est faite en utilisant les 3 environnement de développement Xcode (pour le model ), Interface Builder (pour l'interface) et Xcode+Interface Builder (pour le controleur).
En plus le framework Cocoa offre des objets prêts à être utilisés qui sont de très haut niveau et te divise le boulot parfois d'un facteur 3 voire nettement plus.
En tout cas toutes les personnes à qui j'ai conseillés l'utilisation de cocoa, et qui avaient vaguement des notions en orienté objet, sont devenus de fervents défenseurs de cocoa.
Pour tout savoir sur cocoa je te conseille ce site
pour des exemples je te conseille ce site de o'reilly

L'approche MVC de cocoa permet de mieux décomposer ton appli et donc au niveau conceptuel, de bien designer ton appli et pouvoir facilement la porter sous n'importe quelle plate-forme.

 

[Didier Guillion]

L'approche MVC de cocoa permet de mieux décomposer ton appli et donc au niveau conceptuel, de bien designer ton appli et pouvoir facilement la porter sous n'importe quelle plate-forme.

Bonjour,

La tu m'interesse, tu veut dire que les API Cocoa ont été portées sur Windows ou autre ?

Cordialement

 

[elnemo]

OK merci pour vos réponses.

Le seul hic dans mon cas c'est que l'IHM est très important à mes yeux.. je ne veux pas d'un truc pas bo, avec des boutons, non système etc...

Personnellement j'ai commencé le cocoa il y a quelques semaines et même si je n'en suis plus à "Hello World" je suis pour le moment très dérouté ! Mais bon, je ne vais pas ma laisser abatre par ça

Si je comprend bien, il me suffit de faire mon interface sous IB, de faire un classe cocoa qui serve de lien comme ceci
[INTERFACE] <--> Classe de lien <--> Classe d'action

C'est ça ?

 

[Didier Guillion]

Bonjour,

Oui, en gros c'est ca.
Mais on s'éloigne de la question de base, un appli écrite en ObjectiveC utilisant des classes Cocoa sera t"elle facilement portable sur PC...

Hmmm...

Cordialement

 

[elnemo]

Oui en effet on s'éloigne du thread de base... mais apparement il n'y a pas de solution miracle !

Meci pour vos info à tous

 

[Manu]

Bonjour,

Oui, en gros c'est ca.
Mais on s'éloigne de la question de base, un appli écrite en ObjectiveC utilisant des classes Cocoa sera t"elle facilement portable sur PC...

Hmmm...

Cordialement

Je ne parle pas de portage sur une autre plateforme en cocoa. Mais l'analyse du problème et sa résolution en utilisant le concept MVC te permet par la suite d'utiliser n'importe quel langage pour effectuer le portage.

 

[elnemo]

heu....

c'est quoi le MVC ?

 

[GrandGibus]

C'est très simple:
M = Model
V = View
C = Controller

En gros (et en java) tu as:
M = Personne.java qui est un bean simple représentant les attributs d'une personne (nom, prénom...)
V = PersonnePanel.java qui est un panel swing qui contient des TextFields pour éditer les attributs de la personne
C = PersonneController.java qui est une classe qui sert à:
- dire à V qu'un attribut de M a changé (quelqu'un d'autre a modifié M et il faut rafraichir l'interface)
- dire à M que l'utilisateur a changé la valeur d'un des champs (ex le nom)

Il est conseillé que les 3 entités (M, V et C) communiquent par message. De fait, la manière dont sont présentées tes données n'est pas dépendante de la manière dont tes données sont modelisées. Par exemple, tu peux implémenter Personne.java avec une hashmap de paires clés valeurs ou avec une liste d'attributs simples... Dans les deux cas, ta couche de présentation (V) ne sera pas affectée par ces changements.

Note que MVC est à la base de beaucoup de frameworks et c'est une bonne pratique permettant une meilleure réutilisabilité des composants.

J'espère que ça peut aider

 

[elnemo]

OUI ça m'aide beaucoup.

Je suis en train de lire un bouquin chez EYROLES (Cocoa par la pratique), il parle de ce genre de patern-design (si c'est bin ça).

Je crois avoir compris le concept d'MVC.

Pourtant, ce genre de "FAÇON DE CONCEVOIR UN SOFT" ne veux pas dire qu'on peut porter une appli vers une autre plateforme !!
non ?

 

[GrandGibus]

Ca permet de réutiliser les couches Model et Controller !!! La partie View étant dédiée à la platforme sur laquelle tu comptes distribuer... D'où l'interet de déconnecter completement ces 3 éléments entre eux de manière à ne pas introduire de dépendances et de changer selon la cible.

Mais dis-moi ce qui ne va pas avec Java

Question look, as-tu regardé cetaines extension genre JGoodies ?

Question perfs, as-tu regardé du coté de SWT (qui est le framework d'Eclipse) ?

Faut pas croire tout ce qu'il y a d'écrit dans les forums où la plupart du temps, ils en sont restés à des versions antédiluvienne de Java 1.1 où je l'admets, il y avait des soucis de performances

Car malgré tout, il me semble que Java réponde particulièrement bien à ta problématique de multi-platforme et c'est de plus un langage objet aisé à apprendre.

 

[elnemo]

Je n'ai rien contre JAVA, hors mis la manière dont on construit l'IHM, j'aime beaucoup l'approche des soft comme RealBasic IB, ou WinDev (merdique par aileurs)... je ne me sens pas très pret à créer des bouton en tapant le code approprié ! C'est pour moi une perte de temps considérable, car j'aime beaucoup voir graphiquement ce que ça donne avant toute chose.

D'autre part la devise de Java "Build one time, Run everywhere" ou un trcu dans le genre (j'sais plus trop

)...

Par aileurs j'ai téléchargé il n'y a pas si longtemps ECLIPSE et j'ai été particulièrment décu par la lenteur du soft ! Ya pas à dire c'est lent de chez lent. (machine de test Powerbook 12" RAM 512 DD 5400 t/min)

Bref, si je trouve que le java possède une jolie syntaxe, facile à comprendre, et pas trop dur à apprendre, le seul fait de développer dans un envirronement lent, me décourage je l'avous

J'ai pas les € pour m'acheter un G5 bi-Pro avec 8 Go de RAM pour faire tourner les truc correctement.

T'en penses quoi de la lenteur d'Eclipse toi ?

 

[GrandGibus]

Oulala que de confusions !!!

D'abord, Eclipse est écrit en java soit, mais l'ihm est en SWT (normalement plus rapide que Swing)... Mais eclipse fait de la recompil en temps réel... C'est vrai que c'est lent... mais c'est le cas sur toutes les machines: j'ai au boulot un PowerMac biPro et un aluBook perso. Je travaille avec Eclise depuis plus d'un an... et je n'envisage pas de changer pour l'instant... De plus le portage de SWT sous mac (mais aussi sous linux) n'est pas vraiment top top

Concernant la devise de Java... c'est vrai... à condition de ne pas programmer comme un bourin. Nous sommes 5 développeurs sur mon projet: 3 sous windows (xp et 2000) un sous linux (débian) et moi sous mac os X. On travaille tous sur les mêmes sources... presque tous avec Eclipse. C'est une appli multi tiers (je m'occupe du serveur d'appli sous JBoss)... et tout tourne sur toutes les platformes et tous les types de machine (portables, desktops...)

Il y a deux client (un lourd en Java-Swing et un html)... On a pris nos précautions pour le client Java , mais on obtient des temps de réponse largement supérieurs aux seuils de tolérences pour ce genre d'appli (PDM) !!! La couche réseau étant le principal frein aux perfs !!!

Pour la création d'ihm, perso, je vais plus vite en faisant mes gridbaglayout à la main: je n'ai pas trouvé de builder assez puissant ou qui génèrent un code assez propre à mon gout. Ceci dit, ce n'est que mon avis, et que la période d'apprentissage peut rebuter quelques uns !!!

Bref, tout ça n'est que mon avis et je ne veux pas lancer de polémique genre Java/C++...

Dernier point, tu peux me contacter par chat (c.f. mon profil macgé) en soirée si je suis connecté, je répondrai (dans la limite de mes connaissances) avec plaisir.

 

[elnemo]

Pour une fois que je trouve quelqu'un comme toi sur un Forum

ça fait plaisir. Je vais essayer de faire le tri dans tout ce que j'ai appris dans un premier temps, puis ensuite quand j'aurai plein de question je me retournerai vers toi, je pense

Merci encore à tout le monde

 

[GrandGibus]

no problemo

 

[AL-1]

Bonjour,

Oui, en gros c'est ca.
Mais on s'éloigne de la question de base, un appli écrite en ObjectiveC utilisant des classes Cocoa sera t"elle facilement portable sur PC...

Hmmm...

Cordialement

A l'époque (2000-2002) Apple vendais YellowBox pour PC... C'est l'ancien nom de Cocoa. ça tournais sur NT en objective-C avec projectBuilder et Interface Builder tournant sur NT et si mes souvenirs sont bon, c'étais livré avec EOF en Objc.
Malheureusement la société pour la quel je travaillais à l'époque a du abandonné le development avec ce framework. because... Apple vendais Yellowbox à un prix excessif, et prévoyais d'abandonner le support :-(

 

[Didier Guillion]

A l'époque (2000-2002) Apple vendais YellowBox pour PC... C'est l'ancien nom de Cocoa. ça tournais sur NT en objective-C avec projectBuilder et Interface Builder tournant sur NT et si mes souvenirs sont bon, c'étais livré avec EOF en Objc.
Malheureusement la société pour la quel je travaillais à l'époque a du abandonné le development avec ce framework. because... Apple vendais Yellowbox à un prix excessif, et prévoyais d'abandonner le support :-(

Bonjour,

La, c'est vraiment dommage car la pérennité d'un langage ou d'un systeme d'interface depends essentiellement de sa plus grande diffusion.
Cocoa sur Windows, cela aurait été un grand plus.

Cordialement

 

[aLittleWoodElfe]

Pour tout ce qui est portabilité d'applications écrites en Obj-C il faut regarder GNUStep : http://www.gnustep.org/

C'est un framework se basant sur OpenStep, largement compatible avec les frameworks cocoa (ce qui ne veux pas dire totalement...). Ils ont des versions tournant sous Linux bien sûr mais aussi Windows, *BSD et Mac OS X.

Ce qui veut dire que, à terme une application écrite en se basant sur leur framework tournerait sur tous les OS !

Mais bon tout est loin d'être fini. Et à l'heure actuelle il est hors de question d'utiliser ça pour une application pro sous Windows (installation du framework trés délicate et le tout considéré comme instable ensuite).

Voir la barre de progression ici : http://www.gnustep.org/information/progress.html