creer une applis avec interface sans interface builder

arankou

Membre enregistré
2 Avril 2003
7
0
Bonjour
J'ai recemment fait l'acquisition d'un livre sur la conception de jeux simples type breakout & autres petits jeux pour pc.
J'aimerais pouvoir realiser les exemples sur mon mac en cocoa
le probléme c'est qu'à l'heure actuelle je ne suis pas parvenu a trouver de site m'indiquant comment creer une fenetre, d'afficher une images etc ... sans passer par IB.
Quelqu'un pourrait il éclairer ma lanterne ?
Merci d'avance.
 
parce que dans certains cas ou tu ne souhaites pas avoir des boutons et autres truc du meme genre il est bien plus pratique de se faire les affichages d'images et les creations de fenetre a la main ...
Par ailleur je suis au très curieux or je sais le faire sous win mais je n'ai rien trouvé pour Mac
 
Il me semble que ce n'est pas bien compliqué (sur le principe en tout cas). Il suffit d'instancier tes objets (fenêtres, boutons, etc.), de les "mêler" et de les afficher, en utilisant les méthodes des classes voulues. Pour ça, tu vas devoir bien lire la documentation des classes d'Apple pour voir quelles méthodes tu as besoin. Si j'ai un moment cette après-midi, j'essaierai de te faire un exemple d'une création d'une fenêtre contenant qqs éléments d'interfaces via du code uniquement.

Mis à part ça, je trouve aussi cette idée un peu saugrenue
wink.gif
 
bah faut des fois savoir etre saugrenue
smile.gif

Mais j'avoue que pour certains trucs interface builder est lourd et limitant
Surtout dans le cas d'un jeux qui ne comporte pas de bouton ni rien
Oui ca serais cool si tu pouvais me faire une demo
 
Voilà je me suis amusé
smile.gif
et j'ai réalisé un petit exemple disponible sur mon site web.

L'exemple fonctionne très bien chez moi. N'étant pas très habitué à la gestion de la mémoire en Objective-C (je fais surtout du Cocoa-Java), j'espère n'avoir pas trop commis de fautes conceptuelles de ce côté-là. Note tout de même que j'ai utilisé Interface Builder pour créer une instance de mon controller (je suis quand même pas complétement maso!!)

Et s'il te prend l'idée de vraiment faire ton jeu ou ton programme sans utiliser InterfaceBuilder (ou presque), je te conseille d'avoir une bonne dose de patience!!
 
je te remerci
je vais eplucher ca tranquillement
t'en fait pas de la patience j'en ai plus qu'il n'en faut
deja mes interfaces en java et tout le reste d'ailleurs sont fait avec BBEdit de meme que le php et le html
j'avoue une certaines animosité pour les trucs d'interfaces
smile.gif
 
ça n'a rien à voir avec le sujet du post, mais c'est toi qui a fait le merveilleux logiciel Harmony Assistant ? et si oui, dans quel langage ?
Pour ne pas me faire jeter par le modo, je reviens au sujet : moi aussi, je trouve que c'est dommage de se passer des fonctionalités d'IB quand on voit comme c'est ch... d'utiliser les GridBagLayout et layout Manager etc...
 
Sken a dit:
ça n'a rien à voir avec le sujet du post, mais c'est toi qui a fait le merveilleux logiciel Harmony Assistant ? et si oui, dans quel langage ?

C et assembleur.

Pour ne pas me faire jeter par le modo, je reviens au sujet : moi aussi, je trouve que c'est dommage de se passer des fonctionalités d'IB quand on voit comme c'est ch... d'utiliser les GridBagLayout et layout Manager etc...

Surtout qu'il est peut etre plus simple d'ouvrir une simple fenetre et de travailler avec des offscreens, en general pour les jeux video on passe par la... Moins il y a de couches, plus c'est rapide (et portable).

Cordialement
 
Fais tout de même très attention. Interface Builder permet de créer facilement des interfaces respectant les Aqua HI Guidelines d'Apple. J'entends par là les règles qui devraient être appliquées par tous les programmes afin de rendre le plus à l'aise possible l'emploi d'un nouveau programme pour les utilisateurs: les espaces entre certains éléments, taille du texte, texte et positionnement des boutons d'annulation ou de confirmation, etc. Par contre, ne pas utiliser IB te permet de faire aussi du n'importe quoi, ce que je ne te conseille vraiment pas. N'oublies pas que les utilisateurs Mac ont l'habitude de porter une attention particulière à l'interface et au côté visuel.
 
Bonjour,

D'accord avec l'intervention de Molgow.
J'ajouterait même que le slogan "Think Different" ne s'adresse qu'aux utilisateurs d'autres systèmes d'exploitations, une fois que tu es passé sur Mac, tu dois suivre des règles très strictes sans dérogation possible en ce qui concerne l'Interface (qui a dit le mot "secte" ?
wink.gif
)
A noter que seuls les gradés, proche du Général en Chef, ont le droit de déroger aux règles : Project Builder, Final Cut, etc...
Produits Apple qui dérogent aux GuideLines.


Cordialement
 
.......ce que je trouve illogique.........Apple met des normes aux points et ne les respecte pas.........je ne vois pas pourquoi les autres softs se verraient obligés de respecter ces normes si Apple s'en fiche royalement. Personnellement je développe actuellement mon soft sans guidelines, et il ne s'en porte pas plus mal. :-)
 
Bonjour,

Je suis entièrement d'accord avec toi.

Dans un monde parfait, l'utilisateur Macintosh se rejouirait de disposer enfin d'un autre logiciel sur sa plateforme et le testerait en profondeur pour voir s'il correspond à ses besoins.

En fait, ce n'est malheureusement pas comme cela que ça marche. Tu risque fort de te faire descendre en flamme par des puristes, découpeur de pixel en 4, qui vont passer ton soft au crible des "table de la loi" de la secte : les Guidelines.

J'ai vu des personnes fondre carrèment les plombs car j'avait oublié un "..." dans un menu, alors que l'item ouvrait une boite de dialogue...


Cordialement
 
Pour te rassurer je te dirais que c pour tous les programmeurs
sur developez.com une fois je m'étais fait jeter car j'avais pas indenté mon code de la bonne facon
en fait j'avais un
if (toto) {
et non un
if (toto)
{
alors tu sais si il faut se soucier des avis des autres pour la forme on s'en sortiras jamais. Quand au guidelines j'avoue m'en servir quand ca m'arrange
smile.gif
 
Je trouve très intéressant vos points de vue, mais je ne les partage pas vraiment
zen.gif


Il est vrai qu'il y a quelques années, lorsqu'en programmation pour Classic (pour OS 8-9), on devait créer l'interface uniquement avec le code, il était assez difficile que tout le monde suive une même charte graphique. Mais à l'heure actuelle, que ce soit avec Carbon ou Cocoa, tu peux réaliser ton interface graphique avec Interface Builder qui permet de gérer facilement les espacements entre éléments, te donne à choix (par défaut) que 3 tailles de textes, etc... et te permet donc de réaliser facilement une interface respectant quelques règles. Pour ma part je trouve vraiment très important de les respecter, évidemment il ne faut pas que ça deviennent une complète obscession, mais ça reste tout de même très important à mes yeux.

Un utilisateur qui ne connaît pas votre application DOIT se sentir à l'aise très rapidement, sinon à moins qu'il soit très motivé, il passera son chemin et jettera votre appli à la poubelle. N'oubliez pas qu'une appli, ce n'est pas juste ses fonctionnalités, mais c'est aussi son interface. Je ne crois pas qu'Apple donne sa vision de l'interface, les guidelines, juste pour nous emmerder, bien au contraire. On peut seulement y gagner (en plus d'utilisateurs) à respecter le mieux possibles ces Guidelines.

Voilà, et je ne crois pas que ce soit contradictoire qu'Apple ne les respectes pas pleinement dans le sens où leur interface est tout de même très soignée et que au niveau des actions ils respectent leurs recommendations.
 
Bonjour,

Je suis à moitié d'accord avec toi, Molgow.
Tout d'abord les Guidelines existent depuis Mac OS 8, et je crois bien même avant. Elle définissait la présentation des dialogue, l'espacement entre les items, etc... Ce n'est pas une nouveauté.
Simplement, elles ont changées avec Mac OS X et Aqua, ce qui est perturbant.

Les Guidelines sont utiles dans bien des cas, et je pense que c'est une TRES bonne chose. Par exemple, le bouton "OK" est toujours à droite du bouton "Annuler" et c'est BIEN.

Ce que je trouve dommage, c'est que certaines personnes prennent ces Guidelines pour des Regles Absolues, or ce ne sont que des guides, comme leur nom l'indique.

Quand tu lit des critiques destructives sur un logiciel comme PowerMail uniquement basées sur l'aspect ou la couleur des palettes, tu te rends compte que ces Guidelines sont mal comprises.

Cordialement
 
Je trouve ca ridicule de descendre un soft parce qu'il ne suit pas à la lettre les "sacro-saintes guidelines" ;-) . Dans ce cas que dire de lightwave ? Ce soft fabuleux avec son interface propriétaire est loin de respecter les guidelines. Et pourtant son succés est reconnu. Il faut savoir enlever ses oeullières, et quand un soft ne respecte pas les guidelines, cela n'empêche pas celui-ci s'il est bien conçu, pratique d'emploi, de plaire tout de même.
Deux fenetres de mon soft sont entièrement construites à coup de drawRect(), de compositing et les actions gérées par matrices, ceci pour des raisons très particulières que je ne peut expliquer ici car le développement n'est pas encore assez avancé et il reste beaucoup de travail à faire. Mais pour l'instant je suis satisfait de mon boulot, et quand dans quelques mois le soft s'offrira aux critiques, et bien je verrais bien.
Il faut savoir innover et sortir des sentiers battus. Surtout quand un OS comme OS X permet bcp de choses grace à son sytème de compositing.
 
Didier Guillion a dit:
...
Tout d'abord les Guidelines existent depuis Mac OS 8, et je crois bien même avant.
Oui effectivement, ça fait très longtemps que apple donne des directives concernant l'apparence des applications. De l'utilisation de la Toolbox sur les premiers mac en 85, à la ToolBox des Apple 2gs en 86 jusqu'à nos jours, il y a toujours eu une définition de l'aparence, ne serait-ce simplement par l'utilisation des outils fournis.