Discussion :

[Ceylo]

Bonjour à tous,

J'ai depuis peu en tête le plus gros projet qui me soit jamais passé par la tête. J'en profite pour le présenter ici. Il s'agit d'une interface graphique pour OpenGL en objective-c (on ne se refait pas). Vous allez me dire… mais il y a déjà GLUI en C++ ! Et bien justement, je compte ajouter certaines particularités bien avantageuses à mon projet. En effet, en plus d'être totalement portable (j'utilise uniquement l'objective-c standard), le style de toute l'interface graphique sera entièrement personnalisable ! Et ceci dans le but de pouvoir parfaitement intégrer cette interface dans n'importe quel jeu vidéo, puisque ce projet est né de mon soucis pour trouver une interface pour mes projets de jeux vidéos (oui je sais j'ai 36 000 projets en même temps). Le plus (dans mes doux rêves, mais réalisable) serait de pouvoir faire réagir différemment l'interface en fonction de la valeur de la couche alpha (la transparence quoi) à l'endroit désigné par la fenêtre. De cette façon si on clique sur une zone entièrement transparente, le message "clic de souris" sera envoyé au jeu et non pas à l'UI. Ceci permet également d'utiliser des fenêtres aux formes les plus variées, et donc pas forcément quelque chose de "carré".

Et pourquoi avoir choisi l'Objective-C ? Principalement parce que je le connais beaucoup mieux (faut dire qu'il plus simple d'après moi) que le C++. Mon deuxième argument était sa performance, qu'après des tests concrets je croyais meilleure que celle du C++, mais je m'étais trompé. Le C++ est plus rapide. Il me reste cependant un argument qui ne me permet pas d'hésitation : la flexibilité du langage, une chose que je n'ai pu trouver dans le C++.

*pfffiou… fallait que ça sorte…*

Pour l'instant ce projet est fermé à toute participation, principalement à cause du fait que je ne sais pas si je serai disponible continuellement pour le faire avancer.

Venons en maintenant au problème pour lequel j'ai posté ici. Comme le projet doit être portable, j'utilise des bibliothèques portables (donc pas de Cocoa). Je cherche en fait l'implementation de la classe List définie par <objc/List.h>. Pourquoi ? Parce que j'avais déjà codé en C façon objet (TDA) une implementation de liste qui fonctionne parfaitement et avec de bonnes performances. Je cherche donc, en comparant mon implementation et l'implementation standard, à savoir si j'ai intérêt à choisir la classe standard ou convertir mon code C pour mon projet.

J'ai regardé du côté de GNUstep, mais utiliser NSArray m'obligerait à utiliser toute la bibliothèque Core de GNUstep, ce à quoi je ne tiens pas. Je n'ai pas besoin de tout le fratras de classes fournies. En plus de ça, je n'ai pas réussi à compiler la bilbiothèque. gnumake n'était soit disant pas installé. Je l'ai réinstallé à partir des sources données sur le site de GNUstep, retenté la configuration de GNUstep Core, même résultat… bon bref, ça ne colle pas.


Voilà, j'espère que le pavé n'était pas trop long à lire
Bon développement à tous

P.S.: j'ai commencé les premiers tests pour traquer les bugs et j'ai obtenu sur mon écran… devinez quoi…*un écran noir !

[Mala]

Un sacré projet auquel tu t'attelles là!

Et pourquoi avoir choisi l'Objective-C ? Principalement parce que je le connais beaucoup mieux (faut dire qu'il plus simple d'après moi) que le C++. Mon deuxième argument était sa performance, qu'après des tests concrets je croyais meilleure que celle du C++, mais je m'étais trompé. Le C++ est plus rapide. Il me reste cependant un argument qui ne me permet pas d'hésitation : la flexibilité du langage, une chose que je n'ai pu trouver dans le C++.

Effectivement, contrairement au C++ qui est un langage static, objective-c est entièrement dynamique. Cela lui confère une grande souplesse ainsi que des capacités d'introspection et de modularité plus poussées qu'en java. Mais cela à un prix. Les appels de méthodes sont plus coûteux.

Venons en maintenant au problème pour lequel j'ai posté ici. Comme le projet doit être portable, j'utilise des bibliothèques portables (donc pas de Cocoa). Je cherche en fait l'implementation de la classe List définie par <objc/List.h>. Pourquoi ? Parce que j'avais déjà codé en C façon objet (TDA) une implementation de liste qui fonctionne parfaitement et avec de bonnes performances. Je cherche donc, en comparant mon implementation et l'implementation standard, à savoir si j'ai intérêt à choisir la classe standard ou convertir mon code C pour mon projet.

J'ai regardé du côté de GNUstep, mais utiliser NSArray m'obligerait à utiliser toute la bibliothèque Core de GNUstep, ce à quoi je ne tiens pas.

Dommage, j'allais te proposer NSMutableArray. L'implémentation de list est beaucoup plus sommaire (ne se conforme pas NSCopying, NSCoding, etc). A cela, j'ajouterais que pour gérer une hiérarchie d'objets (imbrication d'éléments graphiques de l'IHM), NSMutableDictionary serait aussi très pratique. Maintenant, la réécriture de List n'est pas un gros boulot en soit (ça gère juste un tableau d'objets et le lancement de selecteurs). Je ne sais pas si le source est dispo quelque part sur le Web.

Je n'ai pas besoin de tout le fratras de classes fournies.

Mon sentiment c'est que tu risques de devoir réinventer pas mal de choses alors que tu as déjà un gros boulot a faire. Ce qui serait dommage, c'est de te noyer dans ton projet juste à cause de ça.

En tous les cas bon courage, c'est un projet ambitieux. Je travaille actuellement sur un projet qui intègre un éditeur d'IHM entièrement codé en Obj-C (Voir vidéo QuickTime...) pour OSX. Donc si tu as des questions sur l'approche n'hésites pas.

[gibet_b]

En tous les cas bon courage, c'est un projet ambitieux. Je travaille actuellement sur un projet qui intègre un éditeur d'IHM entièrement codé en Obj-C (Voir vidéo QuickTime...) pour OSX. Donc si tu as des questions sur l'approche n'hésites pas.

Ton projet est vraiment très impressionnant !

[Ceylo]

Dommage, j'allais te proposer NSMutableArray. L'implémentation de list est beaucoup plus sommaire (ne se conforme pas NSCopying, NSCoding, etc). A cela, j'ajouterais que pour gérer une hiérarchie d'objets (imbrication d'éléments graphiques de l'IHM), NSMutableDictionary serait aussi très pratique. Maintenant, la réécriture de List n'est pas un gros boulot en soit (ça gère juste un tableau d'objets et le lancement de selecteurs). Je ne sais pas si le source est dispo quelque part sur le Web.


Mon sentiment c'est que tu risques de devoir réinventer pas mal de choses alors que tu as déjà un gros boulot a faire. Ce qui serait dommage, c'est de te noyer dans ton projet juste à cause de ça.

Je n'ai pour l'instant pas l'impression d'avoir besoin de NSCopying, NSCoding… (en fait même avec Cocoa je ne m'en suis jamais servi). Je ne vois pas bien où est le besoin de faire des copies d'objets ou de les enregistrer sur le disque dur. Et pour le lancement de sélecteur euh… je ne vois pas ce que tu veux dire. Je récupère l'objet de la liste, je fais un appel dessus et hop c'est fini, où est le problème ?

Quant à réinventer beaucoup… je dirais que le pire pour moi est passé (c'était réussir à charger convenablement une image PNG pour OpenGL).

Sinon à propos de l'implementation de la classe List, je n'ai pas l'impression qu'elle existe en standard. J'ai téléchargé le compilateur GCC pour l'Obj-C et il y avait les fichiers d'en-tête principaux, mais pas celui de List. Je pense donc utiliser ma propre implementation.

En tout cas, merci pour le soutien, ça fait toujours plaisir. Et si l'avenir est propice, je compte ouvrir le développement de ce projet à une équipe un peu plus nombreuse .

Une dernière remarque : je n'avais pas précisé la licence sous laquelle cette bibliothèque serait distribuée. Elle sera entièrement libre et gratuite pour tous usages (donc probablement sous licence GNU GPL).

Bon développement

[kOrt3x]

Mais ça m'as l'air super sympa ce projet, c'est du bon boulot.
Bon courage pour la suite.

[Mala]

Ton projet est vraiment très impressionnant !

Merci. Avec l'accord de la rédac, je vais faire un post sur le sujet pour présenter un peu ce qu'on peut faire avec Cocoa. On pourra en rediscuter plus longuement si tu veux.

Je n'ai pour l'instant pas l'impression d'avoir besoin de NSCopying, NSCoding… (en fait même avec Cocoa je ne m'en suis jamais servi). Je ne vois pas bien où est le besoin de faire des copies d'objets ou de les enregistrer sur le disque dur.

Les besoins où sa pourrait se justifier:
NSCoding -> Sauvegarde d'un projet d'IHM sur le disque. L'interface graphique peut alors être modélisée à partir d'un simple fichier xml. C'est ce que je fais perso.
NSCopying -> Gestion du copier/coller d'éléments graphiques.
Après tout dépend jusqu'où tu veux aller niveau édition d'interface (accès par une simple API au niveau du code ou bien édition graphique à la volée).

Et pour le lancement de sélecteur euh… je ne vois pas ce que tu veux dire. Je récupère l'objet de la liste, je fais un appel dessus et hop c'est fini, où est le problème ?

Je disais ça juste parce que List l'implémente. Je suppose que c'est utilisé pour des init telle que awakeFromNib qui est envoyée directement à toutes les classes. C'est plus performant car cela évite d'accéder à la liste pour chaque objet.

Quant à réinventer beaucoup… je dirais que le pire pour moi est passé (c'était réussir à charger convenablement une image PNG pour OpenGL).

Gestion des impacts des clics (sur un entête de tableau, une colonne, un onglet, etc) sur une arborescence d'objets, redimensionnement dynamique (ou pas) avec la fenêtre, calage (gauche/droite/haut/bas) par rapport à l'objet père. Répercussion du redimensionnement d'un objet à tous ses fils en fonction de leurs propriétes de calage. Conception d'une librairie d'objet graphique de base. Et tout cela en ayant une approche modulaire (Pierre, Paul ou Jacques ne vont pas vouloir la même IHM). Charger une image PNG en OpenGL me semble assez simple en comparaison.

[Tarul]

Merci. Avec l'accord de la rédac, je vais faire un post sur le sujet pour présenter un peu ce qu'on peut faire avec Cocoa. On pourra en rediscuter plus longuement si tu veux.

J'espère que tu auras l'accord, tu as utiliser beaucoup de concept d'objective-c et de cocoa.

Les besoins où sa pourrait se justifier:
NSCoding -> Sauvegarde d'un projet d'IHM sur le disque. L'interface graphique peut alors être modélisée à partir d'un simple fichier xml. C'est ce que je fais perso.

J'ignorais que l'on pouvais utiliser NSCoding pour sauvegarder une ihm en xml. Tu l'as fait pour ton projet, ou uniquement pour tes boites?

[Mala]

J'espère que tu auras l'accord, tu as utiliser beaucoup de concept d'objective-c et de cocoa.

Oui c'est bon. Je suis en train de préparer un petit topo.

J'ignorais que l'on pouvais utiliser NSCoding pour sauvegarder une ihm en xml. Tu l'as fait pour ton projet, ou uniquement pour tes boites?

On ne peut pas le faire avec un nib à ma connaissance. Je sauvegardes la hiérarchie de mes boîtes comme ça aussi bien pour la partie traitement que la partie interface. Je peux ainsi reconstruire ma structure très simplement. C'est aussi beaucoup plus évolutif que du binaire.

[Tarul]

Oui c'est bon. Je suis en train de préparer un petit topo.


On ne peut pas le faire avec un nib à ma connaissance. Je sauvegardes la hiérarchie de mes boîtes comme ça aussi bien pour la partie traitement que la partie interface. Je peux ainsi reconstruire ma structure très simplement. C'est aussi beaucoup plus évolutif que du binaire.

Cela doit aussi faciliter le développement de nouvelle boite que ce soit par toi ou par un tiers. Plus j'en apprend, plus je me dit que tu as bien réfléchi sur le papier de ce que tu voulais faire.

[Mala]

Je te réponds sur l'autre discussion.

[Ceylo]

Pour l'instant je n'ai pas besoin d'enregistrer d'interface sur le disque. Mon projet ressemble plutôt à une interface du genre GTK+. Mais c'est vrai que pouvoir charger l'interface à partir d'un fichier serait un plus, mais pas ce qu'il y a de plus important pour l'instant.

Quant à répercuter le redimensionnement aux sous zones, cela ne posera pas de problème vu la structure en arbre que j'ai mis en place. Chaque sous-zone est dessinée en fonction des coordonnées et de la taille de la zone parent. La seule chose à laquelle je n'ai pas encore réfléchis c'est la façon exacte donc réagiront mes zones lors du redimensionnement de la fenêtre. Mais ça viendra .

En fait plus j'avance et plus je vois le bout du tunel s'éloigner , il y a tellement de choses à faire… mais c'est fesable.

Bon développement à tous

[Mala]

La seule chose à laquelle je n'ai pas encore réfléchis c'est la façon exacte donc réagiront mes zones lors du redimensionnement de la fenêtre. Mais ça viendra .

Moi je te conseillerais d'étudier de près le fonctionnement des composants graphiques de Cocoa. L'idéal serait même d'aller plus loin en "calquant" tes objets graphiques (fonctionnement, méthodes, etc) dessus. J'y verrais au moins deux avantages:
- Faciliter ton développement car dans un premier temps tu pourrais déjà faire rapidement tes premièrs test avec une version de ta lib se basant sur l'existant de cocoa (capturer les images des composants, se baser sur leur réponse au redimensionnement, etc).
- Faciliter l'apprentissage futur des nouveaux developpeurs qui ne devront pas tout réapprendre en arrivant sur ta lib (la majorité des devs Obj-C sont des devs Cocoa).

En fait plus j'avance et plus je vois le bout du tunel s'éloigner ,

Mmm, déjà vécu ça.

[Ceylo]

Le fonctionnement EST calqué sur Cocoa. J'ai cependant gardé uniquement l'essentiel dans le fonctionnement de mes classes (il y a trois tonnes de choses que je trouve inutiles chez Cocoa).

Quant à captuer les images des composants, faudrait déjà que j'arrive à terminer ma classe OView (équivalent de NSView). En fait je suis revenu pour l'instant sur le codage de ma classe OWindow (équivalent de NSWindow mais version OpenGL) à cause d'un problème de conception (pour faire la liaison entre la fenêtre et la zone principale où seront placés les sous-zones de l'interface.

[Mala]

Le fonctionnement EST calqué sur Cocoa. J'ai cependant gardé uniquement l'essentiel dans le fonctionnement de mes classes (il y a trois tonnes de choses que je trouve inutiles chez Cocoa).

Nickel!