Portage d'une application Windows WPF sous Mac OS X
71 réponses
Steph
Bonjour,
Nous avons développé une application entreprise Windows sous C# utilisant de
nombreux composants WPF qui ont été crées par un graphiste professionnel
(notamment au niveau de la charte graphique de l'entreprise, des logos,
etc).
Cette même entreprise souhaiterait voir cette application portée sur Mac OS
X. Au delà du code C# qui est à réécrire en Objective C, notre principal
inquiétude est l'obligation de réutiliser les composants WPF personnalisés
qui ont été crées par le graphiste. Or, j'ignore complètement quelles sont
les possibilités offertes par XCode à ce niveau.
En effet, je n'ai jamais vu d'applications Mac OS X qui avaient un look
complètement différent de l'ambiance Apple de Mac OS, à la différence des
applications Windows WPF qui peuvent adopter toutes sortes de chartes
graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement
personnalisée, etc). Quels sont nos espoirs de réutiliser nos composants WPF
sous Mac OS X ?
Nous avons développé une application entreprise Windows sous C# utilisant de nombreux composants WPF qui ont été crées par un graphiste professionnel (notamment au niveau de la charte graphique de l'entreprise, des logos, etc).
C'est simple, tu n'as aucune chance de porter ton appli WPF sous OS X, tu aurais pu porter le code avec Mono (sans tout réécrire).
La piste que tu devrais sérieusement explorer, c'est de porter l'application en Silverlight.
Comme ça tu n'as plus de problèlme de plateforme
Steph a présenté l'énoncé suivant :
Bonjour,
Nous avons développé une application entreprise Windows sous C# utilisant de
nombreux composants WPF qui ont été crées par un graphiste professionnel
(notamment au niveau de la charte graphique de l'entreprise, des logos, etc).
C'est simple, tu n'as aucune chance de porter ton appli WPF sous OS X,
tu aurais pu porter le code avec Mono (sans tout réécrire).
La piste que tu devrais sérieusement explorer, c'est de porter
l'application en Silverlight.
Nous avons développé une application entreprise Windows sous C# utilisant de nombreux composants WPF qui ont été crées par un graphiste professionnel (notamment au niveau de la charte graphique de l'entreprise, des logos, etc).
C'est simple, tu n'as aucune chance de porter ton appli WPF sous OS X, tu aurais pu porter le code avec Mono (sans tout réécrire).
La piste que tu devrais sérieusement explorer, c'est de porter l'application en Silverlight.
Comme ça tu n'as plus de problèlme de plateforme
yapu
Steph wrote:
je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur. on appelle ça l'ergonomie.
à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se croit le plus malin et redéfinit tout pour chaque application. Pitoyable. -- Philippe Manet en fait, c'est manet avant @
Steph <nospam@zou.zou> wrote:
je n'ai jamais vu d'applications Mac OS X qui avaient un look
complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur.
on appelle ça l'ergonomie.
à la différence des
applications Windows WPF qui peuvent adopter toutes sortes de chartes
graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement
personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se
croit le plus malin et redéfinit tout pour chaque application.
Pitoyable.
--
Philippe Manet
en fait, c'est manet avant @
je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur. on appelle ça l'ergonomie.
à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se croit le plus malin et redéfinit tout pour chaque application. Pitoyable. -- Philippe Manet en fait, c'est manet avant @
Raminagrobis
Philippe Manet a formulé la demande :
Steph wrote:
je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur. on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son utilisateur pour un crétin incapable de s'adapter à une nuance de couleur?
à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se croit le plus malin et redéfinit tout pour chaque application. Pitoyable.
Comme tu dis...
Philippe Manet a formulé la demande :
Steph <nospam@zou.zou> wrote:
je n'ai jamais vu d'applications Mac OS X qui avaient un look
complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur.
on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son
utilisateur pour un crétin incapable de s'adapter à une nuance de
couleur?
à la différence des
applications Windows WPF qui peuvent adopter toutes sortes de chartes
graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement
personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se
croit le plus malin et redéfinit tout pour chaque application.
Pitoyable.
je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS,
oui, c'est un peu fait exprès, pour éviter de dérouter l'utilisateur. on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son utilisateur pour un crétin incapable de s'adapter à une nuance de couleur?
à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc).
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se croit le plus malin et redéfinit tout pour chaque application. Pitoyable.
Comme tu dis...
anneleguennec
Philippe Manet wrote:
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se croit le plus malin et redéfinit tout pour chaque application. Pitoyable.
Me rappelle une bagarre avec un Works pour DOS qui ne savait pas gérer une Epson 500 jet d'encre. Lui fallait ses propres pilotes à lui tout seul.
Si c'est ça le progrès, il fait rage.
Philippe Manet <yapu@invivo.edu> wrote:
c'est bien ce que je disais. Retour en 1983, où chaque developpeur se
croit le plus malin et redéfinit tout pour chaque application.
Pitoyable.
Me rappelle une bagarre avec un Works pour DOS qui ne savait pas gérer
une Epson 500 jet d'encre. Lui fallait ses propres pilotes à lui tout
seul.
Philippe Manet a tapoté du bout de ses petites papattes :
Raminagrobis wrote:
on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son utilisateur pour un crétin incapable de s'adapter à une nuance de couleur?
pas exactement ; en fait, ça s'appelle diminuer la charge cognitive. C'est un facteur majeur de la productivité des utilisateurs.
C'est une science, mais il y a des gens qui s'imaginent qu'ils peuvent improviser.
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle appli on est améliore la productivité.
-- LeLapin
david.remacle
Steph wrote:
Bonjour,
Nous avons développé une application entreprise Windows sous C# utilisant de nombreux composants WPF qui ont été crées par un graphiste professionnel (notamment au niveau de la charte graphique de l'entreprise, des logos, etc).
Bon courage... car passer du C# a objective-C, faudra tout réécrire....
Cette même entreprise souhaiterait voir cette application portée sur Mac OS X. Au delà du code C# qui est à réécrire en Objective C, notre principal inquiétude est l'obligation de réutiliser les composants WPF personnalisés qui ont été crées par le graphiste. Or, j'ignore complètement quelles sont les possibilités offertes par XCode à ce niveau.
En effet, je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS, à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc). Quels sont nos espoirs de réutiliser nos composants WPF sous Mac OS X ?
Si vous faite une appli pour Mac, il faut respecter un point, les guidelines d'Apple pour interfacer votre application.
voir ce site : http://tinyurl.com/64odask
Merci,
Steph
Steph <nospam@zou.zou> wrote:
Bonjour,
Nous avons développé une application entreprise Windows sous C# utilisant de
nombreux composants WPF qui ont été crées par un graphiste professionnel
(notamment au niveau de la charte graphique de l'entreprise, des logos,
etc).
Bon courage... car passer du C# a objective-C, faudra tout réécrire....
Cette même entreprise souhaiterait voir cette application portée sur Mac OS
X. Au delà du code C# qui est à réécrire en Objective C, notre principal
inquiétude est l'obligation de réutiliser les composants WPF personnalisés
qui ont été crées par le graphiste. Or, j'ignore complètement quelles sont
les possibilités offertes par XCode à ce niveau.
En effet, je n'ai jamais vu d'applications Mac OS X qui avaient un look
complètement différent de l'ambiance Apple de Mac OS, à la différence des
applications Windows WPF qui peuvent adopter toutes sortes de chartes
graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement
personnalisée, etc). Quels sont nos espoirs de réutiliser nos composants WPF
sous Mac OS X ?
Si vous faite une appli pour Mac, il faut respecter un point, les
guidelines d'Apple pour interfacer votre application.
Nous avons développé une application entreprise Windows sous C# utilisant de nombreux composants WPF qui ont été crées par un graphiste professionnel (notamment au niveau de la charte graphique de l'entreprise, des logos, etc).
Bon courage... car passer du C# a objective-C, faudra tout réécrire....
Cette même entreprise souhaiterait voir cette application portée sur Mac OS X. Au delà du code C# qui est à réécrire en Objective C, notre principal inquiétude est l'obligation de réutiliser les composants WPF personnalisés qui ont été crées par le graphiste. Or, j'ignore complètement quelles sont les possibilités offertes par XCode à ce niveau.
En effet, je n'ai jamais vu d'applications Mac OS X qui avaient un look complètement différent de l'ambiance Apple de Mac OS, à la différence des applications Windows WPF qui peuvent adopter toutes sortes de chartes graphiques (boutons personnalisés, menu vectoriel dédié, jauge totalement personnalisée, etc). Quels sont nos espoirs de réutiliser nos composants WPF sous Mac OS X ?
Si vous faite une appli pour Mac, il faut respecter un point, les guidelines d'Apple pour interfacer votre application.
voir ce site : http://tinyurl.com/64odask
Merci,
Steph
Raminagrobis
Philippe Manet a exprimé avec précision :
Raminagrobis wrote:
on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son utilisateur pour un crétin incapable de s'adapter à une nuance de couleur?
pas exactement ; en fait, ça s'appelle diminuer la charge cognitive. C'est un facteur majeur de la productivité des utilisateurs.
Ca doit être pour ça que toutes les icones applicatives sont identiques... pour diminuer la charge cognitive... Ha... mais non, elles sont différentes... ça ne serait pas pour les différencier du premier coup d'oeil?
La remarque est valable pour des fenêtre à l'écran.
Avec des écrans capables de caser de plus en plus de fenêtres de grande taille en simultané, il n'est vraiment pas idiot de différencier les IHM...
Ensuite, il y a ceux qui pensent que le télégraphe est une régression dans la communication...heu pardon...le téléphone... heu pardon...internet... heu...etc...
Bref.. les passéistes.
C'est une science, mais il y a des gens qui s'imaginent qu'ils peuvent improviser.
Philippe Manet a exprimé avec précision :
Raminagrobis <ramina@grosbiss.com> wrote:
on appelle ça l'ergonomie.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son
utilisateur pour un crétin incapable de s'adapter à une nuance de
couleur?
pas exactement ; en fait, ça s'appelle diminuer la charge cognitive.
C'est un facteur majeur de la productivité des utilisateurs.
Ca doit être pour ça que toutes les icones applicatives sont
identiques... pour diminuer la charge cognitive...
Ha... mais non, elles sont différentes... ça ne serait pas pour les
différencier du premier coup d'oeil?
La remarque est valable pour des fenêtre à l'écran.
Avec des écrans capables de caser de plus en plus de fenêtres de grande
taille en simultané, il n'est vraiment pas idiot de différencier les
IHM...
Ensuite, il y a ceux qui pensent que le télégraphe est une régression
dans la communication...heu pardon...le téléphone... heu
pardon...internet... heu...etc...
Bref.. les passéistes.
C'est une science, mais il y a des gens qui s'imaginent qu'ils peuvent
improviser.
C'est parce que sur MacOS, le concepteur a toujours pris par défaut son utilisateur pour un crétin incapable de s'adapter à une nuance de couleur?
pas exactement ; en fait, ça s'appelle diminuer la charge cognitive. C'est un facteur majeur de la productivité des utilisateurs.
Ca doit être pour ça que toutes les icones applicatives sont identiques... pour diminuer la charge cognitive... Ha... mais non, elles sont différentes... ça ne serait pas pour les différencier du premier coup d'oeil?
La remarque est valable pour des fenêtre à l'écran.
Avec des écrans capables de caser de plus en plus de fenêtres de grande taille en simultané, il n'est vraiment pas idiot de différencier les IHM...
Ensuite, il y a ceux qui pensent que le télégraphe est une régression dans la communication...heu pardon...le téléphone... heu pardon...internet... heu...etc...
Bref.. les passéistes.
C'est une science, mais il y a des gens qui s'imaginent qu'ils peuvent improviser.
anneleguennec
LeLapin wrote:
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont les fonctions utiles, j'ai l'impression d'une productivité correcte.
LeLapin <ipub-enlever@neuf-enlever.fr> wrote:
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle
appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont
les fonctions utiles, j'ai l'impression d'une productivité correcte.
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont les fonctions utiles, j'ai l'impression d'une productivité correcte.
LeLapin
Anne a tapoté du bout de ses petites papattes :
LeLapin wrote:
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont les fonctions utiles, j'ai l'impression d'une productivité correcte.
95% des applis Windows sont quasi-standardisées en ce qui concerne l'emplacement et les fonctions des menus. Le fait qu'un développeur joue avec la cosmétique en plus ne peut déranger personne de normalement constitué. Pour les 5% restants, ils se manipulent avec de gros boutons simplissimes et l'interface est totalement intuitive.
-- LeLapin
Anne a tapoté du bout de ses petites papattes :
LeLapin <ipub-enlever@neuf-enlever.fr> wrote:
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle
appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont
les fonctions utiles, j'ai l'impression d'une productivité correcte.
95% des applis Windows sont quasi-standardisées en ce qui concerne
l'emplacement et les fonctions des menus. Le fait qu'un développeur
joue avec la cosmétique en plus ne peut déranger personne de
normalement constitué.
Pour les 5% restants, ils se manipulent avec de gros boutons
simplissimes et l'interface est totalement intuitive.
Je me demande en quoi passer 3 plombes à essayer de savoir sur quelle appli on est améliore la productivité.
Moi, c'est l'inverse : quand je ne passe pas 3 plombes à deviner où sont les fonctions utiles, j'ai l'impression d'une productivité correcte.
95% des applis Windows sont quasi-standardisées en ce qui concerne l'emplacement et les fonctions des menus. Le fait qu'un développeur joue avec la cosmétique en plus ne peut déranger personne de normalement constitué. Pour les 5% restants, ils se manipulent avec de gros boutons simplissimes et l'interface est totalement intuitive.
