@Johnny B. Good :
arrête tu me fait peur :'(

En fait, ça ne change rien au rendu du texte quand on zoom avec la loupe (option d'accessibilité).
De plus, sur l'iMac 27", la plus haute résolution proposée en HiDPI est 1280*720, beaucoup moins sympa que le 2560*1440.

Sur mon MacBook Pro Early 2011 ça ne sert à rien, seul l'affichage en 720x450 est supporté...

Aucun intérêt!!!

@ Madalvée : « Le Mac, c'est simple. Vivement la base de registre. »

Oui, pour un outil à destination des développeurs, c’est en effet assez simple d’accès par rapport à ce que ça aurait pu être.
Et vu que ça n’est absolument pas une option visant les utiilisateurs normaux pour l’instant, il n’y a pas de raison que ce soit présenté plus simplement que ça.

Désolé pour ton troll…

Avec des écrans standards, ce mode n'a aucun intérêt, puisqu'il se résume à utiliser 4px de l'écran pour afficher un pixel de l'image... du coup, la résolution est divisée par 4.

Ça deviendra intéressant quand on aura un écran natif 3840 x 2160.

Ce que je demande à Lion, c'est une fonction native permettant d'augmenter facilement la taille des textes et des icônes d'un seul coup (comme le fait si bien Windows 7).

@ Sephi-Chan : « De plus, sur l'iMac 27", la plus haute résolution proposée en HiDPI est 1280*720 »
@ Juju67 : « Sur mon MacBook Pro Early 2011 ça ne sert à rien, seul l'affichage en 720x450 est supporté... »

Mais évidemment, vu que c’est le principe même de ce mode HiDPI : proposer une définition virtuelle quatre fois plus petite que la définition réelle de votre écran.
Il est absolument évident que ça ne présente aucun intérêt avec les écrans actuels, pas la peine de venir le rappeler, l’article le dit déjà. C’est bien pour ça que cette option n’est pas proposée aux utilisateurs.
Ce n’est [b]pas[/b] un mode magique qui va prendre votre écran actuel et lui doubler sa résolution, hein…

@ Johnny B. Good : Il n’y a aucun risque.
Le fait qu’Apple n’ait pas encore activé cette option n’a absolument rien à voir avec un quelconque risque. C’est juste dû à son inutilité totale avec les écrans actuels.
Cette option ne sera disponible que quand Apple aura sorti des machines avec des écrans à très haute résolution, nécessitant donc ce mode d’affichage.

@ alexadvance : « Ce que je demande à Lion, c'est une fonction native permettant d'augmenter facilement la taille des textes et des icônes d'un seul coup (comme le fait si bien Windows 7). »

Il n’y aura manifestement jamais cette option, qui ne donne pas des résultats très esthétiques.
Apple a abandonné cette approche en faveur du mode HiDPI (qui du coup ne règlera pas le problème de la taille d’affichage des textes et icônes pour ceux qui la trouvent trop petite).

Pour le faire, il faudrait aussi que Xcode fonctionne car depuis la mise à jour je ne peux même pas l'installer :/
Si quelqu'un a un solution ...

HiDPI est toujours en chantier dans 10.7.3 (si ça se trouve, c'est un reliquat d'une piste abandonnée par apple qui était encore dans 10.7.2)

-
Quartz Debug est simple. Il a toujours servi à activer et tester des fonctions de Quartz. Quartz est le nom donné au moteur graphique de os x depuis le millénaire dernier (si monsieur ! )

-
"je pense que si tu n'est pas un gros gamer ou que tu ne fais pas de 3D ça ne posera pas de probleme pour ton GPU"

quasi aucun impact, hormis que ici c'est une fonction cachée, non finie, pas censée être activé par les utilisateurs etc. Le principe n'a aucune raison de se sentir sur les performances des machines.

"Ce que je demande à Lion, c'est une fonction native permettant d'augmenter facilement la taille des textes et des icônes d'un seul coup (comme le fait si bien Windows 7)."

et bien depuis la nuit des temps, Apple résiste à cette demande.

Je me sers du zoom vidéo (fonction accessibilité, activable via un a geste sur souris ou trackpad)

-
"@Johnny B. Good :
arrête tu me fait peur :'(
"

Mieux vaut se passer de bidouiller, sauf à en faire sa passion/métier dans l'informatique. Il a raison de déconseiller.

@camiapp [12/01/2012 18:38]

"Pour le faire, il faudrait aussi que Xcode fonctionne car depuis la mise à jour je ne peux même pas l'installer :/"

ha ben évidemment, pour utiliser xcode faut que xcode marche. Mais quel rapport? Quartz Debug est un programme séparé fourni dans le cadre de la chaine d'outils Xcode.

"Si quelqu'un a un solution ..."

mise à jour de quoi ? Lion ? et vous avez encore Xcode pour Snow ?

vous virez votre dossier Developer (désinstallez moi la cochonnerie que vous avez mis)

Récupérez une version à jour (via l'app store ou compte ADC), réinstallez proprement.

si ça ne marche pas (?!) alors il est temps de virer toutes les bidouilles accumulées dans os X et refaire un mac propre !

@ Madalvée : Je pense que c'est une des plus importantes différences entre un PC sous Windows et un Mac, la base de registre... J'ai pas dit LA plus importante ;) donc si c'est pour se retrouver avec un système instable comme l'est celui de Microsoft, non merci ! MacOS est très bien comme ça, activent cette option ceux qui veulent, un point c'est tout.

Astuce : activer le mode HiDPI
12/01/2012 16:51 | Arnauld de La Grandière

Une petite faute ;

Écran Rétina et pas Rétrina

;)

C'est exactement le même principe que Palm OS en son temps lorsque les écrans sont passés de 320x200 à 640x400 et plus. Les développeurs, pour rendre leurs programmes compatibles "haute-définition" et les garder compatibles "basse-définition" devaient prévoir pour chaque élément graphique les images correspondantes.
Rien de nouveau, rien de révolutionnaire.

@Xynoo : Pour être utilisateur des deux OS, je ne fais pas vraiment de différence en terme de "foutoir" entre la base de registre Windows et la commande "defaults" et les nombreux fichiers .plist de MacOS.

Au moins, avec la base de registre, toutes les configurations sont au même endroit et parcourable à la souris....(et du coup, modifiable sans trop de sécurité il est vrai...)

Je me demande si la meilleure organisation ne serait pas celle de Linux, des fichiers .conf lisible et modifiable en clair.

@ alexadvance : « Pour être utilisateur des deux OS, je ne fais pas vraiment de différence en terme de "foutoir" entre la base de registre Windows et la commande "defaults" et les nombreux fichiers .plist de MacOS. »

Ben c’est bizarre. Parce qu’il y en a pourtant plusieurs, des différences.

Les fichiers de préférences de Mac OS X permettent de bien séparer les préférences des diverses applications et du coup de faciliter énormément la gestion des préférences : réinitialiser les préférences d’une application n’est plus qu’un effacement de fichier, et recopier les préférences d’un utilisateur à l’autre ou d’un ordinateur à l’autre est extrêmement facile.

Ce découpage en fichiers présente également l’avantage de limiter les risques de corruption, la corruption d’un fichier de préférences n’affectant en rien les autres.

Ça facilite aussi la récupération d’un lot de préférences depuis une copie de sauvegarde.

L’organisation de ces préférences permet aussi de bien séparer les niveaux de réglages et leur priorité : les préférences partagées par toutes les applications et tous les utilisateurs, les préférences partagées par tout les utilisateurs pour une application donnée, les préférences partagées par toutes les applications d’un utilisateur donné, les préférences d’un utilisateur donnée pour une application donnée, et on peut encore affiner en ayant des préférences spécifiques à une machine précise, pour un couple utilisateur/application donné.

Enfin, l’organisation interne des fichiers de préférences (quand ils sont au format property list, ce qui n’est pas obligatoire il faut bien l’avouer, seulement recommandé) est bien plus claire que celle de la base de registre de Windows, et bénéficie d’une habitude heureusement bien répandue chez les développeurs Mac OS d’utiliser des noms bien plus clairs que les machins obscurs qu’on trouve pour les clés de la base de registre.

Bref, c’est vraiment le jour et la nuit avec la base de registre de Windows.
Comme tu le soulignes d’ailleurs ensuite en disant : « Je me demande si la meilleure organisation ne serait pas celle de Linux, des fichiers .conf lisible et modifiable en clair. »

Car c’est un système très proche de celui utilisé dans Mac OS.
Mais la version Mac OS présente deux avantages.
D’une part, les emplacements où ranger les divers niveaux de fichiers de préférences sont bien spécifiés, ce qui permet à toutes les applications (à de très rares exceptions près, mais qui existent malheureusement) de faire les choses de la même manière — un énorme avantage quand on cherche un fichier de préférences.
D’autre part, une incitation similaire à la standardisation se retrouve pour le contenu des fichiers de préférences, en poussant à l’usage du format property list. Ça évite d’avoir à essayer de comprendre le format qu’a bien pu décider d’utiliser tel ou tel développeur — car non, avoir un fichier de configuration en texte brut éditable via vi n’est absolument pas un gage d’avoir un format « lisible et modifiable en clair ».
Enfin, l’usage d’un éditeur dédié pour modifier ces fichiers présente l’avantage, par rapport à de bêtes fichiers texte édités via un simplé éditeur de texte, de réduire le risque d’erreurs de syntaxe.

Vraiment, quand on prend la peine de se pencher sérieusement dessus, on ne peut que se rendre compte que c’est un bon système (pas un système parfait, mais mieux que ce qu’on trouve ailleurs pour l’instant).

@Bee Potato : J'avoue m'être moins penché sur les fichiers de préférences OSX que sur la base de registre Windows.

Le registre Windows est, je pense, plutôt bien organisé, comme une hiérarchie de fichiers : On distingue facilement le registre concernant la machine, les utilisateurs, l'utilisateur en cours, etc... puis une distinction pour le hardware, les logiciels ou la sécurité.
Le gros soucis, c'est qu'il y a foule de développeur Windows et tous n'ont pas de rigueur pour gérer leurs prefs. Entre ceux qui feront un fichier de conf à la sauce maison, ce qui feront du XML et ceux qui utiliseront mal la base de registre et ceux qui l’utiliseront mieux, c'est vite le bordel. sans parler de Microsoft, qui pour éviter qu'on modifie certains paramètres, les ont codés avec des UID sortis de leurs chapeaux....

Ce qui m'ennuie avec OSX , c'est que j'ai l'impression que les commandes "defaults ...." sont des formules magiques sorties de nulle part. Comment connait-on le nom du fichier (domaine), le nom du paramètre à modifier, et son type ?

En fait, vu tout le bien que tu en dis, je penses qu'il faut vraiment que je m'y penche à fond pour en apprécier la qualité.

@ alexadvanc : «  Ce qui m'ennuie avec OSX , c'est que j'ai l'impression que les commandes "defaults ...." sont des formules magiques sorties de nulle part. Comment connait-on le nom du fichier (domaine), le nom du paramètre à modifier, et son type ? »

Le nom de domaine, c’est l’identifiant de l’application, qu’on trouve notamment via le fichier Info.plist présent dans cette dernière (c’est la valeur associé à la clé CFBundleIdentifier) — ou tout simplement en regardant le nom du fichier de préférences, ces identifiants étant suffisamment clairs pour qu’on puisse déduire à quel logiciel correspond quel fichier.
Sinon, il y a aussi la possibilité d’utiliser l’option -app de la commande defaults, qui permet de lui fournir le nom d’une application.

Pour ce qui est du nom de la clé à modifier et de son type, mais aussi des valeurs possibles, il n’y a pas plus de miracles que dans les autres solutions : il faut trouver une source de documentation sur le sujet, qu’elle soit le résultat d’une recherche sur le web ou d’un effort de documentation (bien plus rare) de la part du développeur.
Quand la clé concernée est déjà présente dans le fichier de préférences (après avoir modifié les préférences via l’interface du logiciel, généralement), ça simplifie le travail puisque le nom et le type de valeur sont très faciles à trouver. Mais il reste un petit travail de recherche à faire pour les valeurs possibles.

Bref, exactement comme pour une entrée dans la base de registre, quoi. Il n’y rien de standardisable au niveau du choix des noms de clés pour les préférences propres à une application, et il faut donc faire des recherches pour trouver ce qu’on veut modifier et comment le modifier, quel que soit le système utilisé.

« En fait, vu tout le bien que tu en dis, je penses qu'il faut vraiment que je m'y penche à fond pour en apprécier la qualité. »

En tout cas, je conseille d’utiliser un outil comme le Property List Editor qui était fourni avec Xcode avant la version 4, ou Xcode lui-même depuis la version 4 — c’est bien plus pratique d’éditer un fichier de préférences de cette façon que via la commande defaults. Cette dernière reste utile, en complément (par exemple pour obtenir l’état actuel des préférences d’une appli après fusion des divers niveaux de préférences), mais ne devrait pas être l’outil principal pour cette tâche.

Bon amusement ! :)

Il se trouve ou le dossier "Developer"? Car je le trouve pas!

De même que guillardmarc ...
J'ai installer Xcode mais toujours pas de répertoire "Developer" à la racine du MBP :-(

Quid de la charge supplémentaire pour le gpu ?

je pense que si tu n'est pas un gros gamer ou que tu ne fais pas de 3D ça ne posera pas de probleme pour ton GPU

Le GPU n'a pas plus de pixels à pousser qu'avant..
À voir s'il gère plus de vectoriel qu'avant.
Va tester ça.