Discussion :

[qventura]

Bonjour,

Je vais devoir développer une application graphique (donc toolkit pour les fenêtres + interaction et API Graphique utilisant l’accélération matérielle)

Les deux principales restrictions, et non des moindres, le langage C#, et une portabilité maximale ...

J'ai pas mal de choix a faire, donc voici ce sur quoi je reste pour le moment, et je voudrais des avis dessus:

- C#
- Mono pour le binding C#
- MonoDroid et MonoTouch pour la portabilité sur devices portables

- OpenGL pour la librairie graphique
- OpenTK pour la compatibilité C# / OpenGL
- OpenGL ES pour la librairie graphique sur devices portables

- Qt pour le fenêtrage et les entrées / sorties
- Qyoto pour le compatibilité C# / Qt

Donc voilà ... Les contraintes (Portabilité et C# ...) font que je risque de devoir utiliser pas mal de framework, et j ai vraiment très peu de connaissances à ce sujet !
Y a vraiment le couple Qt / Qyoto qui m'inquiète un peu, j ai pu lire pas mal de mauvais feedback à ce propos.
Est ce que le plus simple serait pas d'utiliser plusieurs toolkit pour le fenêtrage ? WPF pour windows, etc. Sachant que ça serait pas vraiment la tache critique en terme de temps de développement, qui serait plutôt le développement de l engine OpenGL (Qui lui devrait être portable facilement)

Donc avant de fixer un choix je voudrais l avis de gens qui ont plus d’expérience que moi à ce sujet (Je n ai jamais fait de développement cross platform)

Merci

[theMonz31]

avec mono, tu as un peu tout

Après, MonoDroid et MonoTouch sont payants...

Pour moi, l'utilisation de QT n'est pas justifiée...

Ou alors, tu fais TOUT en QT.... mais là, on sort de la "contrainte" C#.

MonoDevelopment est un bon choix.

Après, si tu veux tester sur plusieurs plateformes, tu as "intérêt" à te monter
pleins de Machines Virtuelles pour tester facilement ton application.

Et te faire une procédure de fabrique de ton code pour ces différentes plateformes cibles.

Bref, tout cela me "semble" assez ambitieux... et demande quand même un peu de reflexion.

Malheureusement, de la réflexion, j'en ai mais une expérience .Net multiplateforme, que nenni !!!

Bonne chance

[frecil]

Pas sur que faire du cross plateforme avec C# soit une si bonne idée, c'est quand même une techno Microsoft à la base, et Mono n'ayant pas les mêmes moyens financiers que MS, leurs APIs doivent être à la traine.

Je comprend l'intérêt de la chose si tu as un existant en C# et que tu dois le porter sous le Linux, mais si tu pars de zéro...

Si tu veux vraiment faire du cross-plateforme : je te conseille plutôt java (qui doit aussi avoir des bindings open-gl), voir du C/C++ avec QT.

[qventura]

Je vais pas trop m étendre, mais le C# et la portabilité sont deux choix qui me sont imposés

Bon après quelques recherches ...

Sachant que le gros du travail sera sur le moteur graphique en lui même, et que le système de fenêtrage demandera pas un grand travail, est ce que ca serait une bonne idée d utiliser:

- WPF pour Windows XXX
- Qt pour Linux / Max
- MonoXXXX pour iOS / Android ?

J'aurai toujours le problème pour Qt / C#. Après, ces deux OS sont vraiment pas la cible du projet, donc j vais peut être mettre ça de cote... Et si finalement ça revient parmi les priorités je verrais avec Qyoto

TheMonz31: Qu'entends tu par "Et te faire une procédure de fabrique de ton code pour ces différentes plateformes cibles." ?
Bien structurer pour avoir a réécrire le minimum de code pour la portabilité ? (En utilisant les design pattern approprié donc) Ou tu as en tête des procédures particulière ?

Merci de vos réponses qui confirment que je vais en chier en conception

[frecil]

Je vais pas trop m étendre, mais le C# et la portabilité sont deux choix qui me sont imposés

C'est bizarre comme cahier des charges, surtout que tu dis ensuite que la version QT (donc j'imagine linux/unix) n'est pas très prioritaire.

Ceci dit une autre alternative serait d'utiliser winform qui est plus ancien et donc peut-être mieux émulé par Mono que WPF.
http://www.mono-project.com/WinForms

[theMonz31]

si tu veux faire quelque chose de portable, il ne faut pas penser "cible" pour faire ton architecture...

Normalement, en Mono, je crois que tu peux faire du WPF.

La seule restriction est de ne pas utiliser des librairies Microsoft.xxx.XXX

Donc, evidement, pas de DirectX...

Après, du OpenGL est effectivement quelque chose d'adapter pour la partie graphique...

Il faut juste que tu valides que les versions d'openGL à utiliser existent pour chaque plateforme. Si c'est le cas.. bingo...


Après, et cela ne reste que mon avis, faire une application pour Tablette (ipad /Android), pour smartphone (iphone, Android) et bureau n'est pas forcément judicieux car on se trouve avec 3 modes de comportement différents et donc vouloir faire 3 versions "identiques" pour 3 cibles hétérogènes me semble surprenant, sinon dommageable pour le logiciel...

Si j'avais à faire l'architecture de mon système, je décorrèlerais bien la partie "Métier" et de la partie Graphique et de la partie IHM pour que, en fonction de la cible, les fonctionnalités dépendantes de la puissance de la machine cible soient prises en compte


Pour l'aspect fabrique, je veux simplement dire que lorsque tu dois compiler et livrer une version d'un logiciel pour plusieurs plateforme, il est utile d'avoir un process, un outil ou tu n'as qu'à lancer la fabrication logiciel et cet outil va créer chaque executable en prenant les bonnes librairies dédiés à chaque cible...

Ca s'appelle de la fabrication logicielle... Des outils que Make ou NMake me semble t-il fournissent cette approche.

[StringBuilder]

Je ne comprends pas bien le problème avec le développement 2D.

Comme dit précédement : WinForm est standard et est supporté par toutes les plateformes. Donc pourquoi ne pas l'utiliser ?

Ensuite, si le programme est principalement basé en OpenGL et que seulement quelques fenêtres sont nécessaires... pourquoi ne pas les faire en OpenGL ?

Tous les jeux 3D actuel utilisent directement des fenêtres dans le moteur 3D. J'ai aucune idée de comment ça marche, mais j'imagine que c'est pas bien sorcier. Ne serait-ce pas la solution pour ne pas avoir à choisir entre la peste et le choléra ?

En plus, ça permet d'avoir une interface bien plus "sexy"...

[frecil]

Normalement, en Mono, je crois que tu peux faire du WPF.

euh, justement non en fait.

At this point, no group in the Mono project has plans to implement Windows Presentation Foundation APIs as part of the project.
http://www.mono-project.com/WPF

Par contre, ça me rappelle que le runtime Silverlight (qui est dérivé de l'ancien projet ROTOR sous FREEBSD) tourne aussi sur Mac OS X et Windows Phone ainsi que Linux via Moonlight. Donc c'est peut-être le truc le plus portable qu'on peut trouver sur .NET.

Bon maintenant, la portabilité cela n'a jamais été le point fort de cette plateforme. Celui qui veut vraiment de la portabilité fait du Java ou du C/C++ à mon humble avis.

[qventura]

Merci de vos réponses

Donc je vais partir soit sur du: WPF / OpenGL (ES + Direct3D Mobile ?) / MonoTouchDroid
Soit : WPF / SlimDX / DirectX (Mobile + OpenGL ?)

J'laisse plus ou moins tomber Mac OS X / Unix pour le moment, donc en gros Windows pour plateformes desktop et Windows/Android/iOS pour le mobile

C est quand même chiant qu'y ai rien de standardisé sur mobile ...

[theMonz31]

salut

Dans ma société, on a développer une plateforme commune Mobilité, mais elle s'appuie sur HTML5 et Javascript... et quelques librairies payantes...

Après, si toutes les plateformes étaient homogènes au niveau Api (C++ ou .Net ou JAva), les développements en seraient grandement facilités...

Je pense que le pire reste la plateforme iOS du fait d'objective-C...(pas à cause de ce langage mais du peux d’interopérabilité de l'OS)...

[DonQuiche]

Bonjour, voici mes deux centimes sur le sujet : la poartabilité est tout à fait possible avec Mono.

Par contre, premier problème : les UI ne sont pas portables. Oh ! On peut bien trouver une bibliothèque qui le soit (encore que, sous dotnet, dur dur - et je n'irais pas tenter un binding vers Qt personnellement) mais l'UI doit de toute façon être refaîte en grande partie d'une plateforme à l'autre. Parce qu'une UI "souris" est totalement différente d'une UI "doigt" et que même entre smartphones les gestures sont différents, le look'n feel de chaque plateforme différent, etc. Dès lors une UI générique sera sans doute médiocre partout. A partir de là, autant utiliser sur chaque plateforme la biblio native en veillant simplement dans la conception de l'architecture à pouvoir réutiliser autant de code que possible.



Concernant l'accélération matérielle, ça peut etre très simple ou compliqué.
Cas simple : vous ne visez que des postes supportant OGL 2 et OGL ES 2. C'est à dire les smartphones un tant soit peu récents. Pour Windows, c'est plus compliqué car nombre de machines ont des chipsets Intel capables de supporter OGL2 mais dont les drivers sont moisis et l'empêchent, si bien que la moitié du marché actuel ne supporte pas l'accélération OGL2. Mais on peut utiliser Dx9 sous Windows, bien mieux supporté par Intel. Ça implique plusieurs backends mais ce n'est pas grave car le fonctionnement est dans tous les cas celui d'un pipeline programmable et il n'y aura pas gros à réécrire (OGL ES 2 est quasiment identique à un bon code OGL 2, donc disons 2.1 petits backends en comptant Dx9).

Cas compliqué : vous voulez tout supporter, y compris les vieilles machines Dx8, OGL 1.1 et les smartphones OGL ES 1. Là il vous faudra deux versions du code et chacune aura plusieurs backends, je vous souhaite bien du plaisir.

Possible alternative : passer par Cairo si le but est bien de faire de la 2D, il me semble qu'il est désormais accéléré. A vérifier. Et pour Mono System.Drawing s'appuie sur Cairo il me semble (mais est-ce une version récente et utilisant le GPU ?).