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 ?
Tu discutes avec quelqu'un qui trouve logique que les menus d'une fenêtre ne soient pas portés par la fenêtre mais par le bureau.
certainement, sauf que je ne parle pas de menu d'une fenetre, mais de menu d'une application ; sauf erreur de ma part, les commandes sont executées par une application, laquelle peut gérer plusieurs fenetres.
C'est la pire aberration possible en terme d'ergonomie
???
j'ai effectivement l'habitude de travailler avec 2 écrans, une dizaine d'applis et 30 fenetres ouvertes. Heureusement que les 5 lignes de menus de word, XL et Cie ne s'ouvrent pas 30 fois !
d'autant que comme le dit Jérome, la barre de menu correspond à des instructions destinées à l'application et non au document, ce qui correspond à une cohérence fonctionnelle utile.
le cas le plus net est celui des fonctions globales de l'application permettant de gérer les préférences, d'ouvrir des documents, etc..., il n'est pas logique de les retrouver au niveau de chaque document, qui n'est pas concerné.
autre avantage, activer une fenetre installe le menu de l'application (et son nom) dans la barre supérieure de l'écran (celle qui est la plus "parlante" sur le plan visuel, avec le nom de l'application dans le coin supérieur gauche, celui qui frappe l'oeil), ce qui fait que l'utilisateur sait immédiatement dans quelle application il travaille.
C'est en partie un problème de fonctionnement personnel ; j'ai remarqué que les windosiens travaillent souvent en plein écran, ce qui fait d'ailleurs qu'ils utilisent peu le drag'n drop, dont je ne saurais me passer. -- Philippe Manet en fait, c'est manet avant @
Raminagrobis <ramina@grosbiss.com> wrote:
Tu discutes avec quelqu'un qui trouve logique que les menus d'une
fenêtre ne soient pas portés par la fenêtre mais par le bureau.
certainement, sauf que je ne parle pas de menu d'une fenetre, mais de
menu d'une application ; sauf erreur de ma part, les commandes sont
executées par une application, laquelle peut gérer plusieurs fenetres.
C'est la pire aberration possible en terme d'ergonomie
???
j'ai effectivement l'habitude de travailler avec 2 écrans, une dizaine
d'applis et 30 fenetres ouvertes.
Heureusement que les 5 lignes de menus de word, XL et Cie ne s'ouvrent
pas 30 fois !
d'autant que comme le dit Jérome, la barre de menu correspond à des
instructions destinées à l'application et non au document, ce qui
correspond à une cohérence fonctionnelle utile.
le cas le plus net est celui des fonctions globales de l'application
permettant de gérer les préférences, d'ouvrir des documents, etc..., il
n'est pas logique de les retrouver au niveau de chaque document, qui
n'est pas concerné.
autre avantage, activer une fenetre installe le menu de l'application
(et son nom) dans la barre supérieure de l'écran (celle qui est la plus
"parlante" sur le plan visuel, avec le nom de l'application dans le coin
supérieur gauche, celui qui frappe l'oeil), ce qui fait que
l'utilisateur sait immédiatement dans quelle application il travaille.
C'est en partie un problème de fonctionnement personnel ; j'ai remarqué
que les windosiens travaillent souvent en plein écran, ce qui fait
d'ailleurs qu'ils utilisent peu le drag'n drop, dont je ne saurais me
passer.
--
Philippe Manet
en fait, c'est manet avant @
Tu discutes avec quelqu'un qui trouve logique que les menus d'une fenêtre ne soient pas portés par la fenêtre mais par le bureau.
certainement, sauf que je ne parle pas de menu d'une fenetre, mais de menu d'une application ; sauf erreur de ma part, les commandes sont executées par une application, laquelle peut gérer plusieurs fenetres.
C'est la pire aberration possible en terme d'ergonomie
???
j'ai effectivement l'habitude de travailler avec 2 écrans, une dizaine d'applis et 30 fenetres ouvertes. Heureusement que les 5 lignes de menus de word, XL et Cie ne s'ouvrent pas 30 fois !
d'autant que comme le dit Jérome, la barre de menu correspond à des instructions destinées à l'application et non au document, ce qui correspond à une cohérence fonctionnelle utile.
le cas le plus net est celui des fonctions globales de l'application permettant de gérer les préférences, d'ouvrir des documents, etc..., il n'est pas logique de les retrouver au niveau de chaque document, qui n'est pas concerné.
autre avantage, activer une fenetre installe le menu de l'application (et son nom) dans la barre supérieure de l'écran (celle qui est la plus "parlante" sur le plan visuel, avec le nom de l'application dans le coin supérieur gauche, celui qui frappe l'oeil), ce qui fait que l'utilisateur sait immédiatement dans quelle application il travaille.
C'est en partie un problème de fonctionnement personnel ; j'ai remarqué que les windosiens travaillent souvent en plein écran, ce qui fait d'ailleurs qu'ils utilisent peu le drag'n drop, dont je ne saurais me passer. -- Philippe Manet en fait, c'est manet avant @
