Dans le numéro de janvier de Macworld France, un article de la "boîte
à outils" (pages 100 et 101) conseille de supprimer les ressources
TYPE et CREATEUR pour améliorer la gestion de la correspondance
document <--> application, en basant celle-ci uniquement sur les
extensions.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Dans le numéro de janvier de Macworld France, un article de la "boîte à outils" (pages 100 et 101) conseille de supprimer les ressources TYPE et CREATEUR pour améliorer la gestion de la correspondance document <--> application, en basant celle-ci uniquement sur les extensions.
Premièrement, les type / créateur ne sont pas des ressources, mais des champs dans le catalogue du disque.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par les applis Mac OS X qui se basent encore sur ces champs.
Patrick -- Patrick Stadelmann
In article <df8aa16d.0402170149.693862bd@posting.google.com>,
herve.nospam@tiscali.fr (herve) wrote:
Dans le numéro de janvier de Macworld France, un article de la "boîte
à outils" (pages 100 et 101) conseille de supprimer les ressources
TYPE et CREATEUR pour améliorer la gestion de la correspondance
document <--> application, en basant celle-ci uniquement sur les
extensions.
Premièrement, les type / créateur ne sont pas des ressources, mais des
champs dans le catalogue du disque.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par
les applis Mac OS X qui se basent encore sur ces champs.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Dans le numéro de janvier de Macworld France, un article de la "boîte à outils" (pages 100 et 101) conseille de supprimer les ressources TYPE et CREATEUR pour améliorer la gestion de la correspondance document <--> application, en basant celle-ci uniquement sur les extensions.
Premièrement, les type / créateur ne sont pas des ressources, mais des champs dans le catalogue du disque.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par les applis Mac OS X qui se basent encore sur ces champs.
Patrick -- Patrick Stadelmann
gilbert.olivier
Patrick Stadelmann wrote:
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par les applis Mac OS X qui se basent encore sur ces champs.
Et de toute façon, les attributs de ces fichiers je pense devraient de nouveaux se remodifier tout seul après passage dans l'appli qui les exploites au moment de la sauvegarde.
-- Gilbert
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par
les applis Mac OS X qui se basent encore sur ces champs.
Et de toute façon, les attributs de ces fichiers je pense devraient de
nouveaux se remodifier tout seul après passage dans l'appli qui les
exploites au moment de la sauvegarde.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
Oui. Les fichiers ne seront plus reconnus par les applis Classic, et par les applis Mac OS X qui se basent encore sur ces champs.
Et de toute façon, les attributs de ces fichiers je pense devraient de nouveaux se remodifier tout seul après passage dans l'appli qui les exploites au moment de la sauvegarde.
-- Gilbert
Nicolas.MICHEL
herve wrote:
Salut,
Dans le numéro de janvier de Macworld France, un article de la "boîte à outils" (pages 100 et 101) conseille de supprimer les ressources TYPE et CREATEUR pour améliorer la gestion de la correspondance document <--> application, en basant celle-ci uniquement sur les extensions. Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
cette méthode a-t-elle des aventages ?
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
herve <herve.nospam@tiscali.fr> wrote:
Salut,
Dans le numéro de janvier de Macworld France, un article de la "boîte
à outils" (pages 100 et 101) conseille de supprimer les ressources
TYPE et CREATEUR pour améliorer la gestion de la correspondance
document <--> application, en basant celle-ci uniquement sur les
extensions.
Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
cette méthode a-t-elle des aventages ?
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Dans le numéro de janvier de Macworld France, un article de la "boîte à outils" (pages 100 et 101) conseille de supprimer les ressources TYPE et CREATEUR pour améliorer la gestion de la correspondance document <--> application, en basant celle-ci uniquement sur les extensions. Cette méthode " à la Windows" n'a-t-elle pas des inconvénients ?
cette méthode a-t-elle des aventages ?
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
herve.nospam
(Nicolas MICHEL) wrote in message news:<1g9awni.twddne1tkufeoN%...
cette méthode a-t-elle des aventages ?
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
Hervé
Nicolas.MICHEL@BonBon.net (Nicolas MICHEL) wrote in message news:<1g9awni.twddne1tkufeoN%Nicolas.MICHEL@BonBon.net>...
cette méthode a-t-elle des aventages ?
Je cite un extrait de l'article de Macworld France :
-----------------------------------------
Apple a aussi fait un compromis avec l'ancien système qui travaillait
avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes
se concurrencent allègrement, ce qui ne simplifie pas la compréhension
du comportement du système. Je vous conseille donc de supprimer ces
ressources.
-----------------------------------------
(Nicolas MICHEL) wrote in message news:<1g9awni.twddne1tkufeoN%...
cette méthode a-t-elle des aventages ?
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
Hervé
Schmurtz
herve wrote:
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
Ben, ils se trompent complètement sur les termes. Ce ne sont pas des ressources.
Par ailleurs, je ne suis pas persuadé que cela pose des problèmes dans le fonctionnement, bien qu'il soit clair que les deux systèmes se concurrencent.
Un ancien logiciel carbonisé, ne comprend en général que les informations type/créateur, sauf s'il a été réécrit pour tenir compte des extensions. Dans la plupart des cas, lorsqu'il s'agit de fichiers normalisé (images gif, tiff, sons mp3, aiff, page web) la plupart des logiciels savent déjà reconnaitre le type à partir de l'extension. Pour les formats propriétaire, cela ne pose aucun problème car c'est toujours le logiciel qui à servit à créer le fichier qui sert à l'ouvrir (donc il utilise le même système dans les deux cas).
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant) reconnaitra sans problème les deux système pour ce qui est de la lecture des informations, il ne sera en général pas capable de créer un fichier avec les champs type/créateur appropriés.
Les deux systèmes sont bien concurrenciel, mais il existe des applications uqi se basent entièrement sur l'un ou sur l'autre. Je pense donc qu'il n'est pas judicieux de supprimer toutes les informations de type/créateur.
-- Schmurtz
herve wrote:
Je cite un extrait de l'article de Macworld France :
-----------------------------------------
Apple a aussi fait un compromis avec l'ancien système qui travaillait
avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes
se concurrencent allègrement, ce qui ne simplifie pas la compréhension
du comportement du système. Je vous conseille donc de supprimer ces
ressources.
-----------------------------------------
Ben, ils se trompent complètement sur les termes. Ce ne sont pas des
ressources.
Par ailleurs, je ne suis pas persuadé que cela pose des problèmes dans
le fonctionnement, bien qu'il soit clair que les deux systèmes se
concurrencent.
Un ancien logiciel carbonisé, ne comprend en général que les
informations type/créateur, sauf s'il a été réécrit pour tenir compte
des extensions. Dans la plupart des cas, lorsqu'il s'agit de fichiers
normalisé (images gif, tiff, sons mp3, aiff, page web) la plupart des
logiciels savent déjà reconnaitre le type à partir de l'extension. Pour
les formats propriétaire, cela ne pose aucun problème car c'est toujours
le logiciel qui à servit à créer le fichier qui sert à l'ouvrir (donc il
utilise le même système dans les deux cas).
Un programme cocoa (et surtout le finder pour l'ouverture en
double-cliquant) reconnaitra sans problème les deux système pour ce qui
est de la lecture des informations, il ne sera en général pas capable de
créer un fichier avec les champs type/créateur appropriés.
Les deux systèmes sont bien concurrenciel, mais il existe des
applications uqi se basent entièrement sur l'un ou sur l'autre. Je pense
donc qu'il n'est pas judicieux de supprimer toutes les informations de
type/créateur.
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
Ben, ils se trompent complètement sur les termes. Ce ne sont pas des ressources.
Par ailleurs, je ne suis pas persuadé que cela pose des problèmes dans le fonctionnement, bien qu'il soit clair que les deux systèmes se concurrencent.
Un ancien logiciel carbonisé, ne comprend en général que les informations type/créateur, sauf s'il a été réécrit pour tenir compte des extensions. Dans la plupart des cas, lorsqu'il s'agit de fichiers normalisé (images gif, tiff, sons mp3, aiff, page web) la plupart des logiciels savent déjà reconnaitre le type à partir de l'extension. Pour les formats propriétaire, cela ne pose aucun problème car c'est toujours le logiciel qui à servit à créer le fichier qui sert à l'ouvrir (donc il utilise le même système dans les deux cas).
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant) reconnaitra sans problème les deux système pour ce qui est de la lecture des informations, il ne sera en général pas capable de créer un fichier avec les champs type/créateur appropriés.
Les deux systèmes sont bien concurrenciel, mais il existe des applications uqi se basent entièrement sur l'un ou sur l'autre. Je pense donc qu'il n'est pas judicieux de supprimer toutes les informations de type/créateur.
-- Schmurtz
Nicolas.MICHEL
herve wrote:
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
MDR :) Je cite :
ce qui ne simplifie pas la compréhension du comportement du système.
Effectivement, l'auteur de cet article ne semble pas avoir une très bonne compréhention du system. Mais c'est peut-être à lui de comprendre avant d'écrire un atricle et non au system de changer et de perdre sa compatibilité avec le system précédent.
Je me souviens d'articles du temps de la beta version de OSX, ou peutêtre de la 10.0, qui parlaient du choix fait par apple à ce niveau, choix probablement oportun. J'ai malheureusement pas le temps de les rechercher maintenant. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
herve <herve.nospam@tiscali.fr> wrote:
Je cite un extrait de l'article de Macworld France :
-----------------------------------------
Apple a aussi fait un compromis avec l'ancien système qui travaillait
avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes
se concurrencent allègrement, ce qui ne simplifie pas la compréhension
du comportement du système. Je vous conseille donc de supprimer ces
ressources.
-----------------------------------------
MDR :)
Je cite :
ce qui ne simplifie pas la compréhension
du comportement du système.
Effectivement, l'auteur de cet article ne semble pas avoir une très
bonne compréhention du system. Mais c'est peut-être à lui de comprendre
avant d'écrire un atricle et non au system de changer et de perdre sa
compatibilité avec le system précédent.
Je me souviens d'articles du temps de la beta version de OSX, ou
peutêtre de la 10.0, qui parlaient du choix fait par apple à ce niveau,
choix probablement oportun. J'ai malheureusement pas le temps de les
rechercher maintenant.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Je cite un extrait de l'article de Macworld France : ----------------------------------------- Apple a aussi fait un compromis avec l'ancien système qui travaillait avec les ressources TYPE et CREATOR. Dans MacOS X, les deux systèmes se concurrencent allègrement, ce qui ne simplifie pas la compréhension du comportement du système. Je vous conseille donc de supprimer ces ressources. -----------------------------------------
MDR :) Je cite :
ce qui ne simplifie pas la compréhension du comportement du système.
Effectivement, l'auteur de cet article ne semble pas avoir une très bonne compréhention du system. Mais c'est peut-être à lui de comprendre avant d'écrire un atricle et non au system de changer et de perdre sa compatibilité avec le system précédent.
Je me souviens d'articles du temps de la beta version de OSX, ou peutêtre de la 10.0, qui parlaient du choix fait par apple à ce niveau, choix probablement oportun. J'ai malheureusement pas le temps de les rechercher maintenant. -- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Jacques Perrocheau
In article <1g9aslg.1w7nranhlq52vN%, (Gilbert OLIVIER) wrote:
Et de toute façon, les attributs de ces fichiers je pense devraient de nouveaux se remodifier tout seul après passage dans l'appli qui les exploites au moment de la sauvegarde
Oui, si l'application le fait, mais elle ne le font pas toutes et pas toujours de manière "smart"...
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
In article <1g9aslg.1w7nranhlq52vN%gilbert.olivier@wanadoo.fr>,
gilbert.olivier@wanadoo.fr (Gilbert OLIVIER) wrote:
Et de toute façon, les attributs de ces fichiers je pense devraient de
nouveaux se remodifier tout seul après passage dans l'appli qui les
exploites au moment de la sauvegarde
Oui, si l'application le fait, mais elle ne le font pas toutes et pas
toujours de manière "smart"...
--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
In article <1g9aslg.1w7nranhlq52vN%, (Gilbert OLIVIER) wrote:
Et de toute façon, les attributs de ces fichiers je pense devraient de nouveaux se remodifier tout seul après passage dans l'appli qui les exploites au moment de la sauvegarde
Oui, si l'application le fait, mais elle ne le font pas toutes et pas toujours de manière "smart"...
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
gilbert.olivier
Jacques Perrocheau wrote:
Oui, si l'application le fait, mais elle ne le font pas toutes et pas toujours de manière "smart"...
Donc le mieux est de ne toucher à rien.... :-)
-- Gilbert
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Oui, si l'application le fait, mais elle ne le font pas toutes et pas
toujours de manière "smart"...
Oui, si l'application le fait, mais elle ne le font pas toutes et pas toujours de manière "smart"...
Donc le mieux est de ne toucher à rien.... :-)
-- Gilbert
laurent.pertois
Schmurtz wrote:
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant)
Le Finder est en carbon...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Schmurtz <moi@ici.com> wrote:
Un programme cocoa (et surtout le finder pour l'ouverture en
double-cliquant)
Le Finder est en carbon...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant)
Le Finder est en carbon...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Schmurtz
Laurent Pertois wrote:
Schmurtz wrote:
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant)
Le Finder est en carbon...
Pas entièrement et c'est une application carbon très bien intégrée dans MacOS X (pas un portage tout bête). mais il est effectivement essentiellement codé avec les bibliothèques carbon.
En fait, je ne parlais pas du finder en tant qu'application cocoa, mais en tant qu'application permettant d'ouvrir automatiquement les fichiers avec l'application qui correspond. Dans ce cas, il se débrouille beaucoup mieux avec les applications cocoa (et même carbon à condition qu'elle soit sous forme de paquet) qui peuvent disposer d'information de fichiers ouvrable dans les deux systèmes.
-- Schmurtz
Laurent Pertois wrote:
Schmurtz <moi@ici.com> wrote:
Un programme cocoa (et surtout le finder pour l'ouverture en
double-cliquant)
Le Finder est en carbon...
Pas entièrement et c'est une application carbon très bien intégrée dans
MacOS X (pas un portage tout bête). mais il est effectivement
essentiellement codé avec les bibliothèques carbon.
En fait, je ne parlais pas du finder en tant qu'application cocoa, mais
en tant qu'application permettant d'ouvrir automatiquement les fichiers
avec l'application qui correspond. Dans ce cas, il se débrouille
beaucoup mieux avec les applications cocoa (et même carbon à condition
qu'elle soit sous forme de paquet) qui peuvent disposer d'information de
fichiers ouvrable dans les deux systèmes.
Un programme cocoa (et surtout le finder pour l'ouverture en double-cliquant)
Le Finder est en carbon...
Pas entièrement et c'est une application carbon très bien intégrée dans MacOS X (pas un portage tout bête). mais il est effectivement essentiellement codé avec les bibliothèques carbon.
En fait, je ne parlais pas du finder en tant qu'application cocoa, mais en tant qu'application permettant d'ouvrir automatiquement les fichiers avec l'application qui correspond. Dans ce cas, il se débrouille beaucoup mieux avec les applications cocoa (et même carbon à condition qu'elle soit sous forme de paquet) qui peuvent disposer d'information de fichiers ouvrable dans les deux systèmes.
