Sondage: Nouvel Outil de Développement R.A.D
- Créateur du sujet eric210766
- Date de début
Ta description de la chose n'est pas sans me rappeler un certain Delphi... (dont il existe un équivalent x11 je crois). Si ça avait la même simplicité et la même richesse, ce serait pas inintéressant. 
ntx : aucun langage n'est has been, il n'y a rien de pire que les gens qui développent en fonction des effets de mode et non de l'intérêt d'une techno. En l'occurence Delphi qu'est basé sur du Pascal Objet surpasse largement x-code en terme d'ergonomie, tout en étant extrèmement riche. Il permet de développer des applis puissantes dans des temps reccords. Et personnellement j'ai rien contre le pascal. Taper "begin" n'est pas plus compliqué que de faire des acrobaties invraisemblables sur le clavier pour obtenir une accolade.
ntx : aucun langage n'est has been, il n'y a rien de pire que les gens qui développent en fonction des effets de mode et non de l'intérêt d'une techno.
En l'occurence Delphi qu'est basé sur du Pascal Objet surpasse largement x-code en terme d'ergonomie, tout en étant extrèmement riche. Il permet de développer des applis puissantes dans des temps reccords. Et personnellement j'ai rien contre le pascal. Taper "begin" n'est pas plus compliqué que de faire des acrobaties invraisemblables sur le clavier pour obtenir une accolade.Je travaille dans l'industrie depuis 10 ans, et là pas de Delphi et autres Pascals : C, C++, Java voire C#. Alors peut être quand dans d'autres domaines le Pascal est encore d'actualité. Mais le passage au Pascal "objet" semble aussi une ultime tentative pour sauver les éditeurs (l'éditeur ?) qui travaillent encore avec ce langage et pouvoir profiter de la "mode" des langages objets. Quant à Apple, le passage à la famille C est complètement fait, adieu le Pascal de Mac OS Classic.
Je ne juge pas mon électricien sur la marque de son tournevis, alors pourquoi pas Pascal.
Quel serait le degré de portabilité ?
Cordialement
Quel serait le degré de portabilité ?
Cordialement
J'ai plusieurs fois posé cette question et l'on m'a souvent répondu avec les mêmes arguments pour les deux camps (le pour et le contre).
Le choix du langage est basé sur plusieurs principes:
1°) Le Pascal est probablement le langage le plus plus proche du raisonnement que l'on doit effectuer avant de coder.
2°) C'est un langage peu permissif ce qui évite bon nombre d'erreurs à l'exécution.
3°) La version écrite à ce jour est fondé sur un Pascal Objet étendu, c'est à dire que certains concepts de l'Objective-C ont été introduits. Par exemple, les méthodes de classes, les chaînes unicodes, etc
4°) En ce qui concerne la portabilité. Puisque l'objectif principal est la production d'applications Mac et compte tenu que Cocoa est au cur du système, aucune portabilité n'est possible.
5°) En ce qui concerne le coté "has been" du langage, je partage cette idée et c'est précisemment l'objectif des extensions qui seront apportés dans ce projet.
Je remercie tous ceux qui ont particpés à ce forum.
Il reste ouvert à d'autres interventions.
Le choix du langage est basé sur plusieurs principes:
1°) Le Pascal est probablement le langage le plus plus proche du raisonnement que l'on doit effectuer avant de coder.
2°) C'est un langage peu permissif ce qui évite bon nombre d'erreurs à l'exécution.
3°) La version écrite à ce jour est fondé sur un Pascal Objet étendu, c'est à dire que certains concepts de l'Objective-C ont été introduits. Par exemple, les méthodes de classes, les chaînes unicodes, etc
4°) En ce qui concerne la portabilité. Puisque l'objectif principal est la production d'applications Mac et compte tenu que Cocoa est au cur du système, aucune portabilité n'est possible.
5°) En ce qui concerne le coté "has been" du langage, je partage cette idée et c'est précisemment l'objectif des extensions qui seront apportés dans ce projet.
Je remercie tous ceux qui ont particpés à ce forum.
Il reste ouvert à d'autres interventions.
Tu devrais plutôt faire un sondage.
Je vais me permettre de donner un avis très tranché: j'admire tes ambitions mais tu vas perdre ton temps.
Cocoa ne se combine bien qu'avec Objective-C. Je ne veux pas dire technologiquement parlant: Les ponts pour utiliser Cocoa avec Java, Eiffel, Ruby ou Python fonctionnent bien, mais Cocoa possède une culture Objective-C.
Le chapitre consacré à Cocoa-Java dans le livre d'Aaron Hillegass, commençait ainsi: "N'utilisez pas Java pour programmer Cocoa". L'idée est que cela prend trop de temps, que la syntaxe n'est pas adaptée, et que finalement, ObjC s'apprend en une demi-journée. La difficulté vient de maîtriser Cocoa, pas ObjC. Tu remarqueras sur Objective-Cocoa que très peu de questions portent sur ObjC, et quand c'est effectivement le cas, de gens qui n'ont jamais lu un chapître sur la gestion mémoire en ObjC.
Je n'irais pas programmer Cocoa avec mon langage préféré, Python, parce que je vais perdre tout l'intérêt d'utiliser Python.
Ce qui revient à dire qu'il faut, à mon avis, recadrer ton projet. Personne n'a besoin d'un Pascal new-age qui s'interface à Cocoa. Pas plus qu'un Basic new-age.
Ce que tout le monde attend, c'est un langage facile pour programmer rapidement des trucs intéressants; ce qu'AppleScript, ou RealBasic n'ont pas tout à fait réussi à faire. Et fort justement, Delphi est doué pour ça. Introduire Cocoa enlève immédiatement la facilité. Cocoa n'est pas facile; c'est ce que nous nous tuons à crier sur ce forum à longueur d'année.
Ensuite, au sujet du Pascal. Oui, c'est has-been. D'ailleurs Objective-C, C++ et Java aussi le sont. On ne peut en être convaincu qu'en ayant vraiment programmé quelque chose de conséquent en Python ou Ruby. Je vais prendre l'exemple de Python, que je connais bien: bien que la syntaxe puisse être entièrement mémorisée, les listes et les dictionnaires sont des types de bases du langage, ce qui rend leur manipulation beaucoup plus simple. On ne gâche pas son temps à faire des déclarations de variables et pourtant, le langage est très typé. Python est un langage qui permet au final de développer rapidement, en gardant un code très lisible.
Bon, j'ai pas tout dit, mais je pense que tu comprendras l'idée. Réponds aux besoins. Cherche des partenaires. Si tu n'arrives pas à convaincre une personne, alors ton projet vaut que dalle!
Je vais me permettre de donner un avis très tranché: j'admire tes ambitions mais tu vas perdre ton temps.
Cocoa ne se combine bien qu'avec Objective-C. Je ne veux pas dire technologiquement parlant: Les ponts pour utiliser Cocoa avec Java, Eiffel, Ruby ou Python fonctionnent bien, mais Cocoa possède une culture Objective-C.
Le chapitre consacré à Cocoa-Java dans le livre d'Aaron Hillegass, commençait ainsi: "N'utilisez pas Java pour programmer Cocoa". L'idée est que cela prend trop de temps, que la syntaxe n'est pas adaptée, et que finalement, ObjC s'apprend en une demi-journée. La difficulté vient de maîtriser Cocoa, pas ObjC. Tu remarqueras sur Objective-Cocoa que très peu de questions portent sur ObjC, et quand c'est effectivement le cas, de gens qui n'ont jamais lu un chapître sur la gestion mémoire en ObjC.
Je n'irais pas programmer Cocoa avec mon langage préféré, Python, parce que je vais perdre tout l'intérêt d'utiliser Python.
Ce qui revient à dire qu'il faut, à mon avis, recadrer ton projet. Personne n'a besoin d'un Pascal new-age qui s'interface à Cocoa. Pas plus qu'un Basic new-age.
Ce que tout le monde attend, c'est un langage facile pour programmer rapidement des trucs intéressants; ce qu'AppleScript, ou RealBasic n'ont pas tout à fait réussi à faire. Et fort justement, Delphi est doué pour ça. Introduire Cocoa enlève immédiatement la facilité. Cocoa n'est pas facile; c'est ce que nous nous tuons à crier sur ce forum à longueur d'année.
Ensuite, au sujet du Pascal. Oui, c'est has-been. D'ailleurs Objective-C, C++ et Java aussi le sont. On ne peut en être convaincu qu'en ayant vraiment programmé quelque chose de conséquent en Python ou Ruby. Je vais prendre l'exemple de Python, que je connais bien: bien que la syntaxe puisse être entièrement mémorisée, les listes et les dictionnaires sont des types de bases du langage, ce qui rend leur manipulation beaucoup plus simple. On ne gâche pas son temps à faire des déclarations de variables et pourtant, le langage est très typé. Python est un langage qui permet au final de développer rapidement, en gardant un code très lisible.
Bon, j'ai pas tout dit, mais je pense que tu comprendras l'idée. Réponds aux besoins. Cherche des partenaires. Si tu n'arrives pas à convaincre une personne, alors ton projet vaut que dalle!
Moralité, Apple n'aurait jamais dû sortir l'iPhone!!! Bein oui Steve Ballmer trouvait l'idée d'un téléphone sans clavier complétement débile...
Microsoft CEO Ballmer laughs at Apple iPhone
J'ai du mal à suivre vos raisonnement moi. On a l'impression que la seule chose qui vous va pas est le langage. Personnellement des langages j'en connais une trentaine (certains mieux que d'autres, évidemment), mais ce qui me fait choisir entre l'un ou l'autre pour une tâche donnée, c'est jamais le langage, c'est hyper secondaire ça. Un langage c'est qu'une syntaxe, éventuellement une idéologie derrière. Ce qui est décisif dans un choix, c'est la richesse des composants, des library, les frameworks, l'environnement de développement, le fait que le code soit compilé, pré-compilé ou interprété.
Bref le Pascal ça me rebute pas plus que ça, c'est un des premiers langages que j'ai appris, ça se compile donc c'est relativement performant, mais ce qui m'intéresserait c'est d'en savoir un peu plus sur ce qui sera développé autour. J'en reviens à une comparaison avec Delphi, vu que le premier message m'y fait fortement penser, est-ce que le but c'est d'avoir un environnement avec la même richesse de composants ? Est-ce que ce sera une ergonomie du même genre ou plus proche d'InterfaceBuilder ? Qui est certes puissant mais pas aussi simple.
Et bien sûr, la question la plus importante, à quel prix ?
Bref le Pascal ça me rebute pas plus que ça, c'est un des premiers langages que j'ai appris, ça se compile donc c'est relativement performant, mais ce qui m'intéresserait c'est d'en savoir un peu plus sur ce qui sera développé autour. J'en reviens à une comparaison avec Delphi, vu que le premier message m'y fait fortement penser, est-ce que le but c'est d'avoir un environnement avec la même richesse de composants ? Est-ce que ce sera une ergonomie du même genre ou plus proche d'InterfaceBuilder ? Qui est certes puissant mais pas aussi simple.
Et bien sûr, la question la plus importante, à quel prix ?
+1, sauf que je ne connais pas une 30aine de langages :rateau:
À part ça c'est exactement la même chose que ce que je pense mais sans la flemme de l'écrire
Je vais répondre à Céroce. J'ai lu avec intérêt sa critique.
Je suis d'accord sur le principe que Cocoa se combine naturellement avec l' Objective-C. C'est logique puisqu'il est écrit dans ce langage.
J'ai lu le livre d'Aaron Hillegass. Il est clair que dans le chapitre 4, il n'est pas tendre avec les outils C++ et Java.
Il se permet là de dire une contrevérité. La folie de surclasser ! J'ai travaillé avec CodeWarriors en utilisant le framework PowerPlant pendant plus 6 ans. Dans mes développements, je n'ai jamais dérivé la moindre classes relatives à l'interface visuelle. Je ne sais sur quel outil il se base, puisque son univers est Apple ! En revanche, son livre est précis et de de bonne facture.
Le but du projet n'est pas de modifier le couple Xcode d'un coté et Interface Builder de l'autre en remplaçant le langage.
Il s'agit plutôt d'introduire le concept d'intégration d'un environnement de développement. Concrètement, il n'est plus nécessaire de naviguer entre les deux applications. La création d'un objet graphique sera automatiquement identifié dans le code correspondant. Une liste permettrait de choisir l'événement à implémenter pour un objet concret. Tout ceci est l'idée même de real basic, de vb ou de delphi. D'autre part, plusieurs opérations fastidieuses, telles que les connections, seront à jamais bannies. J'ai construit de nombreuses interfaces et je peux dire que ça en devient pénible.
C'est la première idée du projet.
La seconde idée s'appliquera plus tard, une fois que la fiabilité sera au rendez-vous. Il est clair que le projet est de longue haleine. De nombreuses versions sortiront gratuitement.
Je cite "Personne n'a besoin". Je ne comprend pas. As-tu l'expérience suffisante pour affirmer ? Si tu as accès à des informations particulières, peux-tu me les communiquer ?
Pour finir, "réponds aux besoins", tu ne crois pas que je vais dans ce sens ? En ce qui concerne les partenaires, je développe seul et j'ai déjà beaucoup dans ma besace !
J'aurais aimé poursuivre mais je doit m'arrêter là.
A suivre ..
Je suis d'accord sur le principe que Cocoa se combine naturellement avec l' Objective-C. C'est logique puisqu'il est écrit dans ce langage.
J'ai lu le livre d'Aaron Hillegass. Il est clair que dans le chapitre 4, il n'est pas tendre avec les outils C++ et Java.
Il se permet là de dire une contrevérité. La folie de surclasser ! J'ai travaillé avec CodeWarriors en utilisant le framework PowerPlant pendant plus 6 ans. Dans mes développements, je n'ai jamais dérivé la moindre classes relatives à l'interface visuelle. Je ne sais sur quel outil il se base, puisque son univers est Apple ! En revanche, son livre est précis et de de bonne facture.
Le but du projet n'est pas de modifier le couple Xcode d'un coté et Interface Builder de l'autre en remplaçant le langage.
Il s'agit plutôt d'introduire le concept d'intégration d'un environnement de développement. Concrètement, il n'est plus nécessaire de naviguer entre les deux applications. La création d'un objet graphique sera automatiquement identifié dans le code correspondant. Une liste permettrait de choisir l'événement à implémenter pour un objet concret. Tout ceci est l'idée même de real basic, de vb ou de delphi. D'autre part, plusieurs opérations fastidieuses, telles que les connections, seront à jamais bannies. J'ai construit de nombreuses interfaces et je peux dire que ça en devient pénible.
C'est la première idée du projet.
La seconde idée s'appliquera plus tard, une fois que la fiabilité sera au rendez-vous. Il est clair que le projet est de longue haleine. De nombreuses versions sortiront gratuitement.
Je cite "Personne n'a besoin". Je ne comprend pas. As-tu l'expérience suffisante pour affirmer ? Si tu as accès à des informations particulières, peux-tu me les communiquer ?
Pour finir, "réponds aux besoins", tu ne crois pas que je vais dans ce sens ? En ce qui concerne les partenaires, je développe seul et j'ai déjà beaucoup dans ma besace !
J'aurais aimé poursuivre mais je doit m'arrêter là.
A suivre ..
Ça répond en bonne partie aux questions que je me pose, pour moi il y a un trou à combler dans le développement sur mac :
Je ne connais aucun environnement de développement qui permette de façon simple et rapide de construire une application stable, rapide, réactive avec une interface aqua et un grand éventail de composants. Bref, ce que fait Delphi sur PC, et dans une moindre mesure PowerBuilder.
Si c'est sur ce créneau que tu veux te positionner, et qui plus est gratuit dans un premier temps, ça m'intéresse évidemment.
Je ne connais aucun environnement de développement qui permette de façon simple et rapide de construire une application stable, rapide, réactive avec une interface aqua et un grand éventail de composants. Bref, ce que fait Delphi sur PC, et dans une moindre mesure PowerBuilder.
Si c'est sur ce créneau que tu veux te positionner, et qui plus est gratuit dans un premier temps, ça m'intéresse évidemment.
erratum: Un erreur s'est glissée lors de ma dernière intervention.
Il ne s'agit pas de "surclasser" mais de "sousclasser" ! car "surclasser" n'a aucun sens !
Il ne s'agit pas de "surclasser" mais de "sousclasser" ! car "surclasser" n'a aucun sens !
Excuse-moi, ma phrase est mal tournée, je voulais dire que "si tu n'arrives pas à convaincre au moins une autre personne, alors ton projet ne vaut rien".
Ça arrive quand tu exposes un projet à quelqu'un et que tu lui demandes son avis. Il te dit: "hum, moui, c'est intéressant
- Tu veux participer ?
- Ben là, tu comprends, j'ai plein de projets".
eric210766 a dit:
J'ai développé environ 2 ans (bon, pas au quotidien) avec PowerPlant, et si, tu passes ton temps à sous-classer les classes graphiques. Par exemple, comment faisais-tu pour gérer un clic sur un bouton ? Tu dérivais la classe Bouton pour pouvoir réécrire la méthode qui gérait les clics. Cette manière, en plus d'être très peu flexible (il faut créer une sous-classe pour chaque bouton, super), génère des Mo de classes inutiles. De plus, elle n'oblige pas à utiliser le paradigme M-V-C. On peut considérer que c'est une contrainte de moins, et en effet cela simplifie l'apprentissage dans un premier temps, mais pour les programmes conséquent, ce paradigme est indispensable.
Il ne faut pas exagérer, les bindings sont passés par là, et l'avantages des connexions, c'est qu'elles sont très flexibles et peuvent être attachés et détachées dynamiquement.eric210766 a dit:
Alors, non, je n'ai pas de statistiques à te soumettre, c'est juste une conviction, acquise après quelques années à voir les questions sur ce forum, entre autres. C'est pourquoi je te proposais de lancer un vrai sondage sur ce forum, qui affiche des pourcentages.eric210766 a dit:
Pour l'instant, je pense que le débat est intéressant; je tiens à préciser que mon but n'est pas de te démotiver, plutôt de t'aider à préciser ton idée. Pour l'instant, ton projet me semble positionné d'une façon bâtarde: pas vraiment un outil d'expert comme XCode/IB, ni vraiment un outil d'amateur comme RealBasic.
Ma conviction, c'est que c'est sur ce deuxième créneau que nous t'attendons.
InterfaceBuilder est séduisant dans son concept, mais me paraît difficile à utiliser pour un amateur. De plus, il est très lié à XCode. J'imagine qu'en faire une version simplifiée serait toutefois un travail très lourd (n'est-ce pas ce que tu as commencé à faire chez Objective-Cocoa?)
Ton idée est identique, au langage près, à celle d'AppleScript Studio on ne peut pas dire que ça ait vraiment décollé. Pas seulement la faute au concept, la faute à Apple aussi.
Moi je suis justement convaincu que c'est dans ce créneau intermédiaire qu'il y a un trou à combler.
Merci grumff ! Tu as tout compris !
Il s'agit de reprendre l'idée de delphi et de l'adapter à l'environnement Mac par l'intégration de Cocoa. Les classes relatives à l'interface visuelle ne posent aucun problème.
Les méthodes d'action, les notifications et les méthodes événementielles sont regroupées sous le terme unique d'événement. Elles s'écrivent pratiquement toutes de la même façon
Par exemple. on dispose d'un bouton butOk et l'on veut écrire le code de réaction, on obtient la méthode suivante:
Event x.butOK_Action;
Begin
End; { butOK_Action };
x étant le nom de la classe du controleur. Il peut s'agir d'un controleur de fenêtre ou de boite de dialogue (pannel), ce qui est équivalent à quelques propriétés près.
Si l'on veut traiter l'événement mouseEntered, il suffit de sélectionner cet événement dans l'éditeur de code, on obtient:
Event x.butOK_MouseEntered(inEvent:NSEvent);
Begin
End; { butOK_MouseEntered }
Pour les fenêtres, par exemple, la notification est traitée comme un événement.
Event x.WindowDidBecomeKey;
Begin
End; { WindowDidBecomeKey }
Fini les sous cas, délegate, target et compagnie. Une approche unique et globale. C'est l'idée directrice d'XDev.
La gestion des menus est également simplifiée. Chaque menu traité doit implémenter deux méthodes. La première consiste à l'exécution de l'action de la commande. Elle s'écrira pour l'article Nouveau :
Event x.mnuItemNew_Action;
Begin
End; { mnuItemNew_Action }
La seconde s'interesse à la façon de gérer la disponibilité. Elle s'écrira:
Event x.mnuItemNew_Validation:Boolean;
Begin
End; { mnuItemNew_Validation }
ou
Event x.mnuItemNew_Validation(inItem:NSMenuItem):Boolean;
Begin
End; { mnuItemNew_Validation }
A ce propos, je n'ai pas tranché. La seconde écriture permet de modifier l'article de menu dans son ensemble. La valeur retournée indique si oui ou non l'article est dispo.
Par ces quelques exemples, il est évident que certaines lourdeurs ont été radicalement éliminées.
Chaque fois que j'implémente une classe de Cocoa, je recherche toujours un moyen de masquer la lourdeur, l'initialisation, etc… C'est l'objectif de tout bon R.A.D. C'est la plus-value de l'application.
Je vais répondre à Céroce
Je vais aller à l'essentiel. En ce qui concerne PowerPlant, je suis très étonné car les controles sont probablement les classes que l'on étudie en premier lorsque l'on aborde un IDE qui le permet. Par défaut, on est attiré par tout ce qui est visuel.
Pour répondre à la question, comment gérer les clics d'un bouton, c'est simple. On instancie un objet de la classe LButton ou équivalent (de PowerPlant). Puisque LButton hérite de LBroadcaster, il est capable d'envoyer un message matérialisé par un MessageT (SInt32) qui identifie le controle. Le directeur est une classe dérivée de LListener. si bien qu'il est à l'écoute. Pour éviter l'anarchie, il faut lors de l'initialisation effectuer un enregistrement du listener par le broadcaster.
La ruse est: Si j'écoute quelqu'un, c'est que je le connais !
Je confirme que M. Aaron Hillegass se trompe sur ce point. Quoi penser en ce qui concerne Java ? Je ne sais pas (je n'ai pas vérifié) et ça ne m'interesse pas !
Pour la démotivation, qu'on se le dise franchement, le projet sortira.
Le compilateur fonctionne, l'éditeur de code est quasiment finalisé. L'éditeur de l'interface est en cours de réalisation.Toutefois, je reste prudent. J'ai, par le passé, appris à mes dépends que certaines tâches qui paraissaient faciles ne l'étaient pas !
Quand à Cocoa, c'est long et lourd à implémenter. C'est le poids !
Je t'invite lors de sa sortie à l'utiliser, si tu veux, car il sera disponible gratuitement....
... dans un premier temps !
Il s'agit de reprendre l'idée de delphi et de l'adapter à l'environnement Mac par l'intégration de Cocoa. Les classes relatives à l'interface visuelle ne posent aucun problème.
Les méthodes d'action, les notifications et les méthodes événementielles sont regroupées sous le terme unique d'événement. Elles s'écrivent pratiquement toutes de la même façon
Par exemple. on dispose d'un bouton butOk et l'on veut écrire le code de réaction, on obtient la méthode suivante:
Event x.butOK_Action;
Begin
End; { butOK_Action };
x étant le nom de la classe du controleur. Il peut s'agir d'un controleur de fenêtre ou de boite de dialogue (pannel), ce qui est équivalent à quelques propriétés près.
Si l'on veut traiter l'événement mouseEntered, il suffit de sélectionner cet événement dans l'éditeur de code, on obtient:
Event x.butOK_MouseEntered(inEvent:NSEvent);
Begin
End; { butOK_MouseEntered }
Pour les fenêtres, par exemple, la notification est traitée comme un événement.
Event x.WindowDidBecomeKey;
Begin
End; { WindowDidBecomeKey }
Fini les sous cas, délegate, target et compagnie. Une approche unique et globale. C'est l'idée directrice d'XDev.
La gestion des menus est également simplifiée. Chaque menu traité doit implémenter deux méthodes. La première consiste à l'exécution de l'action de la commande. Elle s'écrira pour l'article Nouveau :
Event x.mnuItemNew_Action;
Begin
End; { mnuItemNew_Action }
La seconde s'interesse à la façon de gérer la disponibilité. Elle s'écrira:
Event x.mnuItemNew_Validation:Boolean;
Begin
End; { mnuItemNew_Validation }
ou
Event x.mnuItemNew_Validation(inItem:NSMenuItem):Boolean;
Begin
End; { mnuItemNew_Validation }
A ce propos, je n'ai pas tranché. La seconde écriture permet de modifier l'article de menu dans son ensemble. La valeur retournée indique si oui ou non l'article est dispo.
Par ces quelques exemples, il est évident que certaines lourdeurs ont été radicalement éliminées.
Chaque fois que j'implémente une classe de Cocoa, je recherche toujours un moyen de masquer la lourdeur, l'initialisation, etc… C'est l'objectif de tout bon R.A.D. C'est la plus-value de l'application.
Je vais répondre à Céroce
Je vais aller à l'essentiel. En ce qui concerne PowerPlant, je suis très étonné car les controles sont probablement les classes que l'on étudie en premier lorsque l'on aborde un IDE qui le permet. Par défaut, on est attiré par tout ce qui est visuel.
Pour répondre à la question, comment gérer les clics d'un bouton, c'est simple. On instancie un objet de la classe LButton ou équivalent (de PowerPlant). Puisque LButton hérite de LBroadcaster, il est capable d'envoyer un message matérialisé par un MessageT (SInt32) qui identifie le controle. Le directeur est une classe dérivée de LListener. si bien qu'il est à l'écoute. Pour éviter l'anarchie, il faut lors de l'initialisation effectuer un enregistrement du listener par le broadcaster.
La ruse est: Si j'écoute quelqu'un, c'est que je le connais !
Je confirme que M. Aaron Hillegass se trompe sur ce point. Quoi penser en ce qui concerne Java ? Je ne sais pas (je n'ai pas vérifié) et ça ne m'interesse pas !
Pour la démotivation, qu'on se le dise franchement, le projet sortira.
Le compilateur fonctionne, l'éditeur de code est quasiment finalisé. L'éditeur de l'interface est en cours de réalisation.Toutefois, je reste prudent. J'ai, par le passé, appris à mes dépends que certaines tâches qui paraissaient faciles ne l'étaient pas !
Quand à Cocoa, c'est long et lourd à implémenter. C'est le poids !
Je t'invite lors de sa sortie à l'utiliser, si tu veux, car il sera disponible gratuitement....
... dans un premier temps !
Moi je suis justement convaincu que c'est dans ce créneau intermédiaire qu'il y a un trou à combler.
Mon premier sentiment était le même mais les éléments d'éclaircissement apportés sur developpez.com m'ont fait changer d'opinion.
Voir ici:
http://www.developpez.net/forums/showthread.php?t=536335
