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 ?
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
-- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
LeLapin
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas fait le tour. Ca ne présume rien des interrupts soft du Bios vu que Windows gère directement les I/O à bas niveau et que les interrupts Dos sont des équivalents gérées par Windows (d'où le fait, par exemple, que le mode console soit fenêtré, que le buffer clavier soit géré par Win, que les I/O disque supportent des standards nouveaux - quoiqu'en même temps le Bios a évolué pour supporter pas mal de nouveautés). Si un jour je m'emmerde je reprendrai le bon vieux test de compatibilité que j'avais écrit dans les 80s pour écrire mes bancs d'essai (faudrait déjà que je retrouve un MASM d'époque ;) ); et on verra bien ce qui passe et par où.
-- LeLapin
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin <ipub-enlever@neuf-enlever.fr> a
écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient
simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même
celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard
que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge
correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en
asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je
suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas
fait le tour. Ca ne présume rien des interrupts soft du Bios vu que
Windows gère directement les I/O à bas niveau et que les interrupts Dos
sont des équivalents gérées par Windows (d'où le fait, par exemple, que
le mode console soit fenêtré, que le buffer clavier soit géré par Win,
que les I/O disque supportent des standards nouveaux - quoiqu'en même
temps le Bios a évolué pour supporter pas mal de nouveautés).
Si un jour je m'emmerde je reprendrai le bon vieux test de
compatibilité que j'avais écrit dans les 80s pour écrire mes bancs
d'essai (faudrait déjà que je retrouve un MASM d'époque ;) ); et on
verra bien ce qui passe et par où.
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas fait le tour. Ca ne présume rien des interrupts soft du Bios vu que Windows gère directement les I/O à bas niveau et que les interrupts Dos sont des équivalents gérées par Windows (d'où le fait, par exemple, que le mode console soit fenêtré, que le buffer clavier soit géré par Win, que les I/O disque supportent des standards nouveaux - quoiqu'en même temps le Bios a évolué pour supporter pas mal de nouveautés). Si un jour je m'emmerde je reprendrai le bon vieux test de compatibilité que j'avais écrit dans les 80s pour écrire mes bancs d'essai (faudrait déjà que je retrouve un MASM d'époque ;) ); et on verra bien ce qui passe et par où.
-- LeLapin
jperrocheau
LeLapin wrote:
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
cmd.exe et le mode de compatibiltié DOS n'ont rien à voir. C'est grace à la "machine virtuelle DOS".
-- Jacques Perrocheau ______________________________________________________________________ e-mail: mailto:
pehache
Le 14/07/11 17:09, LeLapin a écrit :
Non. Ils marchent sous Windows en mode console. Point.
Bon. Si tu veux. Win permet de faire fonctionner les applis Dos
*certaines* applis DOS, parce que ce sont aussi des applis Windows de fait.
Antérieures à l'existence de Windows pourtant. Tu expliques ça comment ? (ou tu t'es mal exprimé).
Je me suis mal exprimé mais j'ai aussi dit une connerie. Le fait que les applis soient antérieures à Windows n'est pas le problème : il pourrait y avoir compatibilité binaire, et compatibilité de l'API Win32. Néanmoins il y a bien un émulateur DOS dans Windows, qui prend en charge les applis 16 bits et qui émule le matériel auquel veut accéder une appli DOS.
Pour autant, cet émulateur n'a rien à voir avec cmd.exe
cmd.exe n'émule rien du tout, c'est l'interpréteur de commande natif de Windows, point.
cmd.exe n'est pas command.com. Il l'émule.
cmd.exe n'est pas command.com, et il ne l'émule pas :-)
Pas plus que /bin/csh d'un Linux 64 bits n'émule le /bin/csh d'un Linux 32 bits.
FU2 vers fcom-w
-- pehache
Le 14/07/11 17:09, LeLapin a écrit :
Non. Ils marchent sous Windows en mode console.
Point.
Bon. Si tu veux. Win permet de faire fonctionner les applis Dos
*certaines* applis DOS, parce que ce sont aussi des applis Windows de
fait.
Antérieures à l'existence de Windows pourtant. Tu expliques ça comment ?
(ou tu t'es mal exprimé).
Je me suis mal exprimé mais j'ai aussi dit une connerie. Le fait que les
applis soient antérieures à Windows n'est pas le problème : il pourrait
y avoir compatibilité binaire, et compatibilité de l'API Win32.
Néanmoins il y a bien un émulateur DOS dans Windows, qui prend en charge
les applis 16 bits et qui émule le matériel auquel veut accéder une
appli DOS.
Pour autant, cet émulateur n'a rien à voir avec cmd.exe
cmd.exe n'émule rien du tout, c'est l'interpréteur de commande natif
de Windows, point.
cmd.exe n'est pas command.com. Il l'émule.
cmd.exe n'est pas command.com, et il ne l'émule pas :-)
Pas plus que /bin/csh d'un Linux 64 bits n'émule le /bin/csh d'un Linux
32 bits.
Non. Ils marchent sous Windows en mode console. Point.
Bon. Si tu veux. Win permet de faire fonctionner les applis Dos
*certaines* applis DOS, parce que ce sont aussi des applis Windows de fait.
Antérieures à l'existence de Windows pourtant. Tu expliques ça comment ? (ou tu t'es mal exprimé).
Je me suis mal exprimé mais j'ai aussi dit une connerie. Le fait que les applis soient antérieures à Windows n'est pas le problème : il pourrait y avoir compatibilité binaire, et compatibilité de l'API Win32. Néanmoins il y a bien un émulateur DOS dans Windows, qui prend en charge les applis 16 bits et qui émule le matériel auquel veut accéder une appli DOS.
Pour autant, cet émulateur n'a rien à voir avec cmd.exe
cmd.exe n'émule rien du tout, c'est l'interpréteur de commande natif de Windows, point.
cmd.exe n'est pas command.com. Il l'émule.
cmd.exe n'est pas command.com, et il ne l'émule pas :-)
Pas plus que /bin/csh d'un Linux 64 bits n'émule le /bin/csh d'un Linux 32 bits.
FU2 vers fcom-w
-- pehache
pehache
Le 14/07/11 17:13, LeLapin a écrit :
Pour en revenir à cmd.exe, c'est juste un interpréteur de commandes, qui ressemble à celui du DOS.
Ben oui, il émule (je réitère) command.com.
"Ressembler à" n'est pas "émuler".
-- pehache
Le 14/07/11 17:13, LeLapin a écrit :
Pour en revenir à cmd.exe, c'est juste un interpréteur de commandes,
qui ressemble à celui du DOS.
Pour en revenir à cmd.exe, c'est juste un interpréteur de commandes, qui ressemble à celui du DOS.
Ben oui, il émule (je réitère) command.com.
"Ressembler à" n'est pas "émuler".
-- pehache
DuboisP
Le Thu, 14 Jul 2011 23:40:15 +0200, LeLapin a écrit:
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas fait le tour. Ca ne présume rien des interrupts soft du Bios vu que Windows gère directement les I/O à bas niveau et que les interrupts Dos sont des équivalents gérées par Windows (d'où le fait, par exemple, que le mode console soit fenêtré, que le buffer clavier soit géré par Win, que les I/O disque supportent des standards nouveaux - quoiqu'en même temps le Bios a évolué pour supporter pas mal de nouveautés). Si un jour je m'emmerde je reprendrai le bon vieux test de compatibilité que j'avais écrit dans les 80s pour écrire mes bancs d'essai (faudrait déjà que je retrouve un MASM d'époque ;) ); et on verra bien ce qui passe et par où.
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
-- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
Le Thu, 14 Jul 2011 23:40:15 +0200, LeLapin <ipub-enlever@neuf-enlever.fr>
a écrit:
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin
<ipub-enlever@neuf-enlever.fr> a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via
cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows
vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même
celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au
hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge
correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en
asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je
suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas
fait le tour. Ca ne présume rien des interrupts soft du Bios vu que
Windows gère directement les I/O à bas niveau et que les interrupts Dos
sont des équivalents gérées par Windows (d'où le fait, par exemple, que
le mode console soit fenêtré, que le buffer clavier soit géré par Win,
que les I/O disque supportent des standards nouveaux - quoiqu'en même
temps le Bios a évolué pour supporter pas mal de nouveautés).
Si un jour je m'emmerde je reprendrai le bon vieux test de compatibilité
que j'avais écrit dans les 80s pour écrire mes bancs d'essai (faudrait
déjà que je retrouve un MASM d'époque ;) ); et on verra bien ce qui
passe et par où.
une interruption Int16 ( interruption clavier) appellée en TurboPascal en
mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Le Thu, 14 Jul 2011 23:40:15 +0200, LeLapin a écrit:
DuboisP a tapoté du bout de ses petites papattes :
Le Thu, 14 Jul 2011 17:13:24 +0200, LeLapin a écrit:
pehache a tapoté du bout de ses petites papattes :
J'ai plein de vieux programmes sous Dos qui marchent encore via cmd.exe.
J'aurais du préciser : toutes les applications DOS.
Le fait que certaines applications DOS tournent encore sous Windows vient simplement du fait qu'il y une compatibilité binaire.
Sur un émulateur DOS, toutes les applications DOS tourneraient, même celles qui accèdent directement au matériel.
Quel rapport entre un logiciel sous Dos (qui n'utilise pour accéder au hard que les Int DOS)
les interruptions DOS, ou les interruptions BIOS ?
Toutes les fonctions de l'Int 21 m'ont l'air prises en charge correctement (enfin c'est pas exhaustifs mais tous mes vieux softs en asm n'utilisant que l'Int21 pour tout faire fonctionnent encore). Je suppose que les autres interrupts Dos le sont aussi mais je n'en ai pas fait le tour. Ca ne présume rien des interrupts soft du Bios vu que Windows gère directement les I/O à bas niveau et que les interrupts Dos sont des équivalents gérées par Windows (d'où le fait, par exemple, que le mode console soit fenêtré, que le buffer clavier soit géré par Win, que les I/O disque supportent des standards nouveaux - quoiqu'en même temps le Bios a évolué pour supporter pas mal de nouveautés). Si un jour je m'emmerde je reprendrai le bon vieux test de compatibilité que j'avais écrit dans les 80s pour écrire mes bancs d'essai (faudrait déjà que je retrouve un MASM d'époque ;) ); et on verra bien ce qui passe et par où.
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
-- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
filh
Raminagrobis wrote:
Sous Windows, je ne connais pas de fonction qui ne soit pas paramétrable par une IHM.
Ben si les logon script par exemple ne sont pas paramétrables par une IHM. Et c'est pas mal utile pour faire des montages réseaux au login et autres cochoncetés du genre...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Raminagrobis <ramina@grosbiss.com> wrote:
Sous Windows, je ne connais pas de fonction qui ne soit pas
paramétrable par une IHM.
Ben si les logon script par exemple ne sont pas paramétrables par une
IHM. Et c'est pas mal utile pour faire des montages réseaux au login et
autres cochoncetés du genre...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Sous Windows, je ne connais pas de fonction qui ne soit pas paramétrable par une IHM.
Ben si les logon script par exemple ne sont pas paramétrables par une IHM. Et c'est pas mal utile pour faire des montages réseaux au login et autres cochoncetés du genre...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
LeLapin
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par où ça passe ? M'étonnerait que ça tape directement dans le Bios.
-- LeLapin
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal en
mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par
où ça passe ? M'étonnerait que ça tape directement dans le Bios.
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par où ça passe ? M'étonnerait que ça tape directement dans le Bios.
-- LeLapin
DuboisP
Le Fri, 15 Jul 2011 14:36:05 +0200, LeLapin a écrit:
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par où ça passe ? M'étonnerait que ça tape directement dans le Bios.
ça m'étonnerait aussi... mes test s'arrêteront là, parce que le travail pour la gloire, ça va 5 minutes -- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
Le Fri, 15 Jul 2011 14:36:05 +0200, LeLapin <ipub-enlever@neuf-enlever.fr>
a écrit:
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal
en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par
où ça passe ? M'étonnerait que ça tape directement dans le Bios.
ça m'étonnerait aussi...
mes test s'arrêteront là, parce que le travail pour la gloire, ça va 5
minutes
--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Le Fri, 15 Jul 2011 14:36:05 +0200, LeLapin a écrit:
DuboisP a tapoté du bout de ses petites papattes :
une interruption Int16 ( interruption clavier) appellée en TurboPascal en mode fenêtre sous Windows 7 pro 32 bits est fonctionnelle.
Ouais mais est-ce que t'as regardé la table des vecteurs pour voir par où ça passe ? M'étonnerait que ça tape directement dans le Bios.
ça m'étonnerait aussi... mes test s'arrêteront là, parce que le travail pour la gloire, ça va 5 minutes -- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
yapu
Raminagrobis 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 @
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 @
