[HUMEUR MAUVAISE] Panther, Mac OS X, Apple... vers une "Microsoftisation" ???
65 réponses
miniotdr
Bonjour à tous,
Applemaniac depuis l'Apple II du lycée, Mac *PowerUser* depuis le Mac
128, NexTien en son temps, adorateur fervent de Steve Jobs et de son
Reality Distorsion Field, et parmi les premiers utilisateurs de Mac OS
X "Beta", je me demande sérieusement quel est le chemin emprunté par
les hommes du logiciel à Infinite Loop...
Je viens de faire l'upgrade Panther sur mon vieil iMac DV SE de fin
99, et j'ai la fort désagréable impression de me retrouver face à un
PC sous un Windows quelconque (sont tous aussi m*rdiques les uns que
les autres ;-) mâtiné d'OS X.0... béta.
Depuis le passage à... Mac OS8.0, c'est bien la première fois que j'en
viens presque à regretter l'upgrade : l'assistant BlueTooth qui se
lance automatiquement à chaque redémarrage (eh, oui, faut redémarrer
souvent, voir plus loin) et cherche la souris Apple BT (j'ai une
Wacom, malin le Mac hein ?), les menus de Safari qui ne répondent pas
au premier lancement (faut quitter et relancer), Mail qui pédale dans
la semoule avec les spams et refuse parfois de me sauvegarder mes
drafts, la tablette Wacom et sa souris qui ne sont plus reconnus sous
les autres comptes que le mien-admin, etc...
Cela ne fait que deux jours, pas encore imprimé ni même réalisé un
document sous Keynote ou GraphicConverter, mais ça me fout un peu la
trouille : vais-je finir par ne plus aimer mon Mac et le considérer
comme un vulgaire PC ?
Tout avait commencé avec Safari et ces p*tains de pages qui me sautent
à la figure alors que je suis en train de faire autre chose : la
première fois depuis... 1984 que c'est mon Mac qui me dicte ma
conduite !!!
Bref, je suis légèrement énervé...
Suis-je le seul, hein, suis-je le seul ?...
Ciao,
_Marc
ps : je vais peut-être remettre en service le IIFx prévu pour ma fille
;-)
Pour la commande mv, le choix a été fait de faire une copie puis de supprimer l'original.
Lorsque le fichier ne change pas de partition, il n'y a même pas de copie qui est effectuée. Il s'agit simplement de modifier le répertoire source et destination.
Effectivement, j'avais sous entendu le contexte "déplacement entre deux partitions" puisque c'est ce problème qui était soulevé.
-- Schmurtz
Pour la commande mv, le choix a été fait de faire une copie puis de
supprimer l'original.
Lorsque le fichier ne change pas de partition, il n'y a même pas de
copie qui est effectuée. Il s'agit simplement de modifier le
répertoire source et destination.
Effectivement, j'avais sous entendu le contexte "déplacement entre deux
partitions" puisque c'est ce problème qui était soulevé.
Pour la commande mv, le choix a été fait de faire une copie puis de supprimer l'original.
Lorsque le fichier ne change pas de partition, il n'y a même pas de copie qui est effectuée. Il s'agit simplement de modifier le répertoire source et destination.
Effectivement, j'avais sous entendu le contexte "déplacement entre deux partitions" puisque c'est ce problème qui était soulevé.
-- Schmurtz
Stephane Dupille
Lorsque le fichier ne change pas de partition, il n'y a même pas de copie qui est effectuée. Il s'agit simplement de modifier le répertoire source et destination. Effectivement, j'avais sous entendu le contexte "déplacement entre deux
partitions" puisque c'est ce problème qui était soulevé.
Dans le cas de changement de partition (terme impropre d'ailleurs, on devrait parle de changement filesystem (d'ailleurs en parlant des FS, est-ce qu'OS X a repris le concept des slices et des partitions des BSD ?)) ou de disque, il n'y a pas d'autre moyens que la copie, puis suppression.
-- Je suis d'accord avec toi Phil, les FAI qui offrent des accès gratuits sont des profiteurs, et d'ailleurs on ne sait pas très bien de quoi ils profitent... on ne sait pas encore ! -+- Biz in <http://www.le-gnu.net> : Le profiteur râle et chocolat -+-
Lorsque le fichier ne change pas de partition, il n'y a même pas de
copie qui est effectuée. Il s'agit simplement de modifier le
répertoire source et destination.
Effectivement, j'avais sous entendu le contexte "déplacement entre deux
partitions" puisque c'est ce problème qui était soulevé.
Dans le cas de changement de partition (terme impropre d'ailleurs,
on devrait parle de changement filesystem (d'ailleurs en parlant des
FS, est-ce qu'OS X a repris le concept des slices et des partitions
des BSD ?)) ou de disque, il n'y a pas d'autre moyens que la copie,
puis suppression.
--
Je suis d'accord avec toi Phil, les FAI qui offrent des accès gratuits
sont des profiteurs, et d'ailleurs on ne sait pas très bien de quoi ils
profitent... on ne sait pas encore !
-+- Biz in <http://www.le-gnu.net> : Le profiteur râle et chocolat -+-
Lorsque le fichier ne change pas de partition, il n'y a même pas de copie qui est effectuée. Il s'agit simplement de modifier le répertoire source et destination. Effectivement, j'avais sous entendu le contexte "déplacement entre deux
partitions" puisque c'est ce problème qui était soulevé.
Dans le cas de changement de partition (terme impropre d'ailleurs, on devrait parle de changement filesystem (d'ailleurs en parlant des FS, est-ce qu'OS X a repris le concept des slices et des partitions des BSD ?)) ou de disque, il n'y a pas d'autre moyens que la copie, puis suppression.
-- Je suis d'accord avec toi Phil, les FAI qui offrent des accès gratuits sont des profiteurs, et d'ailleurs on ne sait pas très bien de quoi ils profitent... on ne sait pas encore ! -+- Biz in <http://www.le-gnu.net> : Le profiteur râle et chocolat -+-
david.andriana
Schmurtz wrote:
Ben tu peux toujours continuer à t'en passer.
Oui mais non. D'une part je pense aux autres. D'autre part... je ne sais pas comment dire, mais ce n'est pas parce que je "peux m'en passer" que c'est acceptable.
Le fichier *sont* des objets :
En termes conceptuels, ce sont des objets, oui. Le problème c'est qu'on n'est pas dans la même couche fonctionnelle que les objets sur lesquels on fait des manipulations d'édition (copier/couper/coller). Par exemple, un morceau de texte de Word.
L'idée, en gros, c'est que si je suis dans Word, et que je fais "copier", je peux aller ensuite dans Illustrator, je fais "coller", et j'ai un résultat transformé (en général du texte formaté de façon minimale). Si je fais "coller" dans un autre document Word, j'aurais le texte formaté à l'identique, et si je vais dans BBEdit, j'aurais juste le texte.
Voilà, on est sur un même niveau fonctionnel, les items et leurs comportements sont bien connus. On passe l'édition d'une appli à l'autre par transformations avec pertes. Activer le menu Édition est donc parfaitement valide.
Pour le système de fichiers, on est largement plus bas niveau. Si je fais "copier" dans le Finder, et que je fais "coller" dans Word : dois-je récupérer le fichier ? le contenu du fichier ? seulement son nom ?
Voilà, j'arrive à un peu mieux préciser ma pensée.
Non, le seul problème que tu peux avoir, c'est de perdre ton fichier :
C'est énorme, comme problème.
Pour une bonne expérience utilisateur, si on laisse l'accès aux fichiers, alors ils doivent être des entités stables : leur intégrité doit être garantie même en cas de plantage, de déplacement, etc. Pas de droits exotiques, pas de problème à la suppression, etc. Pas de comportement bizarre si on change le nom, etc.
Là tu parles carrément du risque de perdre son fichier si on se trompe dans une manip qui n'a pas feedback visuel !
C'est un risque de niveau ligne de commande !
La fonction "Annuler" existe sous MacOS X.
J'ai dit "implémenter", pas "faire croire que ça marche" ;-)
(étagères)
Il n'y aucune différence avec le presse-papier :
Si : dans le presse-papier, si tu fais deux fois "couper", tu écrases le premier élément qui était en mémoire. C'est invisible. Avec l'étagère, tu ne peux pas avoir ce genre d'étourderie.
Le concept de presse-papiers multiples correspond exactement à l'idée que je me fais des étagères.
Conceptuellement, oui. Mais en termes d'expérience utilisateur, la visibilité (et la lisibilité, deux notions dont Aqua n'a rien à carrer) est très importante.
On peut afficher le presse-papier.
Les "on peut" sont des arguments _techniques_.
D'ailleurs ça m'étonne toujours que les MOA indiquent si souvent "on doit pouvoir" dans leurs spécifications, et non quelque chose du genre "l'utilisateur doit clairement voir comment il est possible de".
C'est vrai que le concept d'étagère *visible* est bien meilleur
Eh.
Il faudrait aussi que cette implémentation des étagères puisse gérer n'importe quel type de données (et pouvoir afficher les plus classique).
Cela est parfaitement possible, et ce, en rapport ou non avec le presse-papier. Avec une étagère, on n'est pas dans les manips d'édition dont je parlais plus haut.
On peut imaginer une confirmation de remplacer le fichier présent dans le presse-papier.
Non, surtout pas : parfois tu aurais un presse-papier muet, et parfois un presse-papier qui t'ouvre des dialogues de confirmation ? Surtout pas. La cohérence, la simplicité, la répétabilité avant tout.
Si ! Ça arrive de perdre un paragraphe entier juste parce que tu fait un copier-coller dans une boîte de dialogue.
Pas grave. Tu retapes ton texte et tu rejoues.
Donc en fait, la fonctionnalité "couper" est très dangeureuse, avec tout type de données.
Non, non, non. Il y a des degrés. Perdre un fichier peut te saloper tout le système. Perdre un bout de texte, simplement le bouquin sur lequel tu bosses depuis 6 ans ;-)
-- voir l'expérience utilisateur sous Windows).
Si je me souviens bien, sous Windows, si tu ne colles pas, le fichier reste à ça place. C'est vraiment pas dans l'esprit du couper/copier/coller. Mais bon, c'est Windows.
Le couper/copier/coller de fichiers est inimplémentable.
La grosse erreur de Windows, c'est simplement d'avoir voulu l'implémenter.
Et MacOS X a voulu copier. Minable.
-- David
Schmurtz <moi@ici.com> wrote:
Ben tu peux toujours continuer à t'en passer.
Oui mais non. D'une part je pense aux autres. D'autre part... je ne sais
pas comment dire, mais ce n'est pas parce que je "peux m'en passer" que
c'est acceptable.
Le fichier *sont* des objets :
En termes conceptuels, ce sont des objets, oui. Le problème c'est qu'on
n'est pas dans la même couche fonctionnelle que les objets sur lesquels
on fait des manipulations d'édition (copier/couper/coller). Par exemple,
un morceau de texte de Word.
L'idée, en gros, c'est que si je suis dans Word, et que je fais
"copier", je peux aller ensuite dans Illustrator, je fais "coller", et
j'ai un résultat transformé (en général du texte formaté de façon
minimale). Si je fais "coller" dans un autre document Word, j'aurais le
texte formaté à l'identique, et si je vais dans BBEdit, j'aurais juste
le texte.
Voilà, on est sur un même niveau fonctionnel, les items et leurs
comportements sont bien connus. On passe l'édition d'une appli à l'autre
par transformations avec pertes. Activer le menu Édition est donc
parfaitement valide.
Pour le système de fichiers, on est largement plus bas niveau. Si je
fais "copier" dans le Finder, et que je fais "coller" dans Word :
dois-je récupérer le fichier ? le contenu du fichier ? seulement son
nom ?
Voilà, j'arrive à un peu mieux préciser ma pensée.
Non, le seul problème que tu peux avoir, c'est de perdre ton fichier :
C'est énorme, comme problème.
Pour une bonne expérience utilisateur, si on laisse l'accès aux
fichiers, alors ils doivent être des entités stables : leur intégrité
doit être garantie même en cas de plantage, de déplacement, etc. Pas de
droits exotiques, pas de problème à la suppression, etc. Pas de
comportement bizarre si on change le nom, etc.
Là tu parles carrément du risque de perdre son fichier si on se trompe
dans une manip qui n'a pas feedback visuel !
C'est un risque de niveau ligne de commande !
La fonction "Annuler" existe sous MacOS X.
J'ai dit "implémenter", pas "faire croire que ça marche" ;-)
(étagères)
Il n'y aucune
différence avec le presse-papier :
Si : dans le presse-papier, si tu fais deux fois "couper", tu écrases le
premier élément qui était en mémoire. C'est invisible. Avec l'étagère,
tu ne peux pas avoir ce genre d'étourderie.
Le concept de
presse-papiers multiples correspond exactement à l'idée que je me fais
des étagères.
Conceptuellement, oui. Mais en termes d'expérience utilisateur, la
visibilité (et la lisibilité, deux notions dont Aqua n'a rien à carrer)
est très importante.
On peut afficher le presse-papier.
Les "on peut" sont des arguments _techniques_.
D'ailleurs ça m'étonne toujours que les MOA indiquent si souvent "on
doit pouvoir" dans leurs spécifications, et non quelque chose du genre
"l'utilisateur doit clairement voir comment il est possible de".
C'est vrai que le concept d'étagère *visible* est bien meilleur
Eh.
Il faudrait aussi que cette implémentation des étagères
puisse gérer n'importe quel type de données (et pouvoir afficher les
plus classique).
Cela est parfaitement possible, et ce, en rapport ou non avec le
presse-papier. Avec une étagère, on n'est pas dans les manips d'édition
dont je parlais plus haut.
On peut imaginer une confirmation de remplacer le fichier présent dans
le presse-papier.
Non, surtout pas : parfois tu aurais un presse-papier muet, et parfois
un presse-papier qui t'ouvre des dialogues de confirmation ? Surtout
pas. La cohérence, la simplicité, la répétabilité avant tout.
Si ! Ça arrive de perdre un paragraphe entier juste parce que tu fait un
copier-coller dans une boîte de dialogue.
Pas grave. Tu retapes ton texte et tu rejoues.
Donc en fait, la
fonctionnalité "couper" est très dangeureuse, avec tout type de données.
Non, non, non. Il y a des degrés. Perdre un fichier peut te saloper tout
le système. Perdre un bout de texte, simplement le bouquin sur lequel tu
bosses depuis 6 ans ;-)
-- voir l'expérience utilisateur sous Windows).
Si je me souviens bien, sous Windows, si tu ne colles pas, le fichier
reste à ça place. C'est vraiment pas dans l'esprit du
couper/copier/coller. Mais bon, c'est Windows.
Le couper/copier/coller de fichiers est inimplémentable.
La grosse erreur de Windows, c'est simplement d'avoir voulu
l'implémenter.
Oui mais non. D'une part je pense aux autres. D'autre part... je ne sais pas comment dire, mais ce n'est pas parce que je "peux m'en passer" que c'est acceptable.
Le fichier *sont* des objets :
En termes conceptuels, ce sont des objets, oui. Le problème c'est qu'on n'est pas dans la même couche fonctionnelle que les objets sur lesquels on fait des manipulations d'édition (copier/couper/coller). Par exemple, un morceau de texte de Word.
L'idée, en gros, c'est que si je suis dans Word, et que je fais "copier", je peux aller ensuite dans Illustrator, je fais "coller", et j'ai un résultat transformé (en général du texte formaté de façon minimale). Si je fais "coller" dans un autre document Word, j'aurais le texte formaté à l'identique, et si je vais dans BBEdit, j'aurais juste le texte.
Voilà, on est sur un même niveau fonctionnel, les items et leurs comportements sont bien connus. On passe l'édition d'une appli à l'autre par transformations avec pertes. Activer le menu Édition est donc parfaitement valide.
Pour le système de fichiers, on est largement plus bas niveau. Si je fais "copier" dans le Finder, et que je fais "coller" dans Word : dois-je récupérer le fichier ? le contenu du fichier ? seulement son nom ?
Voilà, j'arrive à un peu mieux préciser ma pensée.
Non, le seul problème que tu peux avoir, c'est de perdre ton fichier :
C'est énorme, comme problème.
Pour une bonne expérience utilisateur, si on laisse l'accès aux fichiers, alors ils doivent être des entités stables : leur intégrité doit être garantie même en cas de plantage, de déplacement, etc. Pas de droits exotiques, pas de problème à la suppression, etc. Pas de comportement bizarre si on change le nom, etc.
Là tu parles carrément du risque de perdre son fichier si on se trompe dans une manip qui n'a pas feedback visuel !
C'est un risque de niveau ligne de commande !
La fonction "Annuler" existe sous MacOS X.
J'ai dit "implémenter", pas "faire croire que ça marche" ;-)
(étagères)
Il n'y aucune différence avec le presse-papier :
Si : dans le presse-papier, si tu fais deux fois "couper", tu écrases le premier élément qui était en mémoire. C'est invisible. Avec l'étagère, tu ne peux pas avoir ce genre d'étourderie.
Le concept de presse-papiers multiples correspond exactement à l'idée que je me fais des étagères.
Conceptuellement, oui. Mais en termes d'expérience utilisateur, la visibilité (et la lisibilité, deux notions dont Aqua n'a rien à carrer) est très importante.
On peut afficher le presse-papier.
Les "on peut" sont des arguments _techniques_.
D'ailleurs ça m'étonne toujours que les MOA indiquent si souvent "on doit pouvoir" dans leurs spécifications, et non quelque chose du genre "l'utilisateur doit clairement voir comment il est possible de".
C'est vrai que le concept d'étagère *visible* est bien meilleur
Eh.
Il faudrait aussi que cette implémentation des étagères puisse gérer n'importe quel type de données (et pouvoir afficher les plus classique).
Cela est parfaitement possible, et ce, en rapport ou non avec le presse-papier. Avec une étagère, on n'est pas dans les manips d'édition dont je parlais plus haut.
On peut imaginer une confirmation de remplacer le fichier présent dans le presse-papier.
Non, surtout pas : parfois tu aurais un presse-papier muet, et parfois un presse-papier qui t'ouvre des dialogues de confirmation ? Surtout pas. La cohérence, la simplicité, la répétabilité avant tout.
Si ! Ça arrive de perdre un paragraphe entier juste parce que tu fait un copier-coller dans une boîte de dialogue.
Pas grave. Tu retapes ton texte et tu rejoues.
Donc en fait, la fonctionnalité "couper" est très dangeureuse, avec tout type de données.
Non, non, non. Il y a des degrés. Perdre un fichier peut te saloper tout le système. Perdre un bout de texte, simplement le bouquin sur lequel tu bosses depuis 6 ans ;-)
-- voir l'expérience utilisateur sous Windows).
Si je me souviens bien, sous Windows, si tu ne colles pas, le fichier reste à ça place. C'est vraiment pas dans l'esprit du couper/copier/coller. Mais bon, c'est Windows.
Le couper/copier/coller de fichiers est inimplémentable.
La grosse erreur de Windows, c'est simplement d'avoir voulu l'implémenter.
Et MacOS X a voulu copier. Minable.
-- David
ludovic.thebault
dom wrote:
Mais je ne peux pas faire glisser un dmg de la même manière que je faisais glisser une image disque montée sur OS 8.6, car j'obtiens seulement un alias !
Et en appuyant sur option ?
dom <dominique@alussinan.org> wrote:
Mais je ne peux pas faire glisser un dmg de la même manière que je
faisais glisser une image disque montée sur OS 8.6, car j'obtiens
seulement un alias !
Mais je ne peux pas faire glisser un dmg de la même manière que je faisais glisser une image disque montée sur OS 8.6, car j'obtiens seulement un alias !
Et en appuyant sur option ?
dominique
Ludovic Thébault wrote:
Et en appuyant sur option ?
Ah je n'ai pas essayé... Normalement, d'un volume à un autre, il n'y a pas besoin d'option ?!
-- Mes photos (nature, jardin) : http://cooldomi.free.fr/ Scripting : http://domiscript.free.fr/
Ah je n'ai pas essayé... Normalement, d'un volume à un autre, il n'y a pas besoin d'option ?!
Oui, ça marche... j'ai encore des réflexes "Classic", pour moi ça ne devait pas marcher, alors je n'y avais même pas pensé... ;->
-- Mes photos (nature, jardin) : http://cooldomi.free.fr/ Scripting : http://domiscript.free.fr/
pas_de_pub
Sinbad21 wrote:
J'ai toujours apprécié cette fonction dans Windows, et je suis bien contente qu'Apple ait *piqué* cette idée à Windows. Étonnant quand même que le couper-coller de fichiers ne soit pas prévu, il existe dans Windows, même entre partitions.
L'approche d'Apple avait aussi son avantage pour copier/coller des listes de noms de fichiers par exemple. Mais je reconnais que je me sers moi-même de ça sous Windows. Faut dire qu'avec cet OS, vaut mieux pouvoir faire comme ça parce que la navigation dans les dossiers n'est vraiment pas aussi souple que sous OS Classic.
Le problème qui se pose avec l'OS X, c'est que beaucoup de comportements standards du Mac ont disparu pour être remplacés par ceux du PC. Ca avait pour but de favoriser l'adoption de OS X par les Windowsiens.
Le problème, c'est que j'ai l'impression que ça a fait fuir les vieux macqueux comme moi, et que ça n'a attiré que très peu les OuinOuinophiles. Bilan final : une part de marché encore plus réduite.
Sinbad21 <sinbad21@chez.com> wrote:
J'ai toujours apprécié cette fonction dans Windows, et je suis bien
contente qu'Apple ait *piqué* cette idée à Windows. Étonnant quand même
que le couper-coller de fichiers ne soit pas prévu, il existe dans
Windows, même entre partitions.
L'approche d'Apple avait aussi son avantage pour copier/coller des
listes de noms de fichiers par exemple. Mais je reconnais que je me sers
moi-même de ça sous Windows. Faut dire qu'avec cet OS, vaut mieux
pouvoir faire comme ça parce que la navigation dans les dossiers n'est
vraiment pas aussi souple que sous OS Classic.
Le problème qui se pose avec l'OS X, c'est que beaucoup de comportements
standards du Mac ont disparu pour être remplacés par ceux du PC. Ca
avait pour but de favoriser l'adoption de OS X par les Windowsiens.
Le problème, c'est que j'ai l'impression que ça a fait fuir les vieux
macqueux comme moi, et que ça n'a attiré que très peu les
OuinOuinophiles. Bilan final : une part de marché encore plus réduite.
J'ai toujours apprécié cette fonction dans Windows, et je suis bien contente qu'Apple ait *piqué* cette idée à Windows. Étonnant quand même que le couper-coller de fichiers ne soit pas prévu, il existe dans Windows, même entre partitions.
L'approche d'Apple avait aussi son avantage pour copier/coller des listes de noms de fichiers par exemple. Mais je reconnais que je me sers moi-même de ça sous Windows. Faut dire qu'avec cet OS, vaut mieux pouvoir faire comme ça parce que la navigation dans les dossiers n'est vraiment pas aussi souple que sous OS Classic.
Le problème qui se pose avec l'OS X, c'est que beaucoup de comportements standards du Mac ont disparu pour être remplacés par ceux du PC. Ca avait pour but de favoriser l'adoption de OS X par les Windowsiens.
Le problème, c'est que j'ai l'impression que ça a fait fuir les vieux macqueux comme moi, et que ça n'a attiré que très peu les OuinOuinophiles. Bilan final : une part de marché encore plus réduite.
david.andriana
Sinbad21 wrote:
L'image qui me vient à propos du copier-coller, c'est de pouvoir se déplacer dans l'arborescence d'un disque sans avoir les bras chargés de paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans avoir besoin de copier/coller stupide.
-- David
Sinbad21 <sinbad21@chez.com> wrote:
L'image qui me vient à propos du copier-coller, c'est de pouvoir se
déplacer dans l'arborescence d'un disque sans avoir les bras chargés de
paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence
du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans
avoir besoin de copier/coller stupide.
L'image qui me vient à propos du copier-coller, c'est de pouvoir se déplacer dans l'arborescence d'un disque sans avoir les bras chargés de paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans avoir besoin de copier/coller stupide.
-- David
yotabaza_anti_spam_
David Andriana wrote:
Sinbad21 wrote:
L'image qui me vient à propos du copier-coller, c'est de pouvoir se déplacer dans l'arborescence d'un disque sans avoir les bras chargés de paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans avoir besoin de copier/coller stupide.
Euh, quelle est la différence entre la navigation dans les disques sous Mac OS <X et celle de Mac OS X une fois que l'on a désactivé la barre d'icônes dans les fenêtres ?
L'image qui me vient à propos du copier-coller, c'est de pouvoir se
déplacer dans l'arborescence d'un disque sans avoir les bras chargés de
paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence
du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans
avoir besoin de copier/coller stupide.
Euh, quelle est la différence entre la navigation dans les disques sous
Mac OS <X et celle de Mac OS X une fois que l'on a désactivé la barre
d'icônes dans les fenêtres ?
L'image qui me vient à propos du copier-coller, c'est de pouvoir se déplacer dans l'arborescence d'un disque sans avoir les bras chargés de paquets.
Oui, cette fonctionnalité est indispensable sous Windows, vu l'indigence du browser de fichiers par défaut.
Là-dessus, MacOS classique enfonce facilement Windows et MacOS X, sans avoir besoin de copier/coller stupide.
Euh, quelle est la différence entre la navigation dans les disques sous Mac OS <X et celle de Mac OS X une fois que l'on a désactivé la barre d'icônes dans les fenêtres ?
