Alors, dans l'idée c'est ça, mais la mise en pratique est plus compliquée.
On pourrait en effet choisir de changer le rapport entre "points" et pixels, mais il y a des cas ou l'application a vraiment besoin de manipuler des pixels directement, du coup ça mettrait le bazar.
A single coordinate unit is 1/72 of an inch, roughly equal to a typographical point. However, all screens are considered to have a resolution of 72 pixels per inch (regardless of the actual dimension), so coordinate units actually count screen pixels. In other words, one unit is the distance between the centers of adjacent pixels on-screen.
"Une unité de coordonnées vaut 1/72 de pouce, environ un point typographique. Cependant, on considère que tous les écrans ont une résolution de 72dpi (peu importe la taille réelle), donc l'unité de coordonnée est en fait un nombre de pixels. Autrement dit, une unité est la distance entre le centre de deux pixels adjacents sur l'écran"
Lorsque le support de l'impression est arrivé, c'est clairement la deuxième définition qui a été retenue. Sur papier, on a des unités de 1/300 ou 1/600 de pouce selon l'imprimante utilisée. Il faut donc faire la mise à l'échelle en utilisant des polices de caractères plus grandes, etc.
La solution retenue est donc:
- Laisser l'utilisateur choisir une taille de texte dans les préférences (fait)
- Ajuster la taille de tous les éléments en fonction (le texte lui-même, les icônes, l'espacement entre les éléments de l'interface, etc (en cours)
- Ajuster la taille de texte (et du reste par conséquent) par défaut en fonction de la résolution de l'écran (pas encore fait, et de trop nombreux écrans ne donnent pas des informations correctes)
Il y a quelques détails pénibles, par exemple les constantes B_V_SCROLL_BAR_WIDTH et B_H_SCROLL_BAR_HEIGHT qui donnent l'épaisseur des barres de défilement et qui sont fixées à 16 pixels, ce qui est trop petit sur un écran haute définition.
Et là ou ça devient le bazar, c'est quand il y a plusieurs écrans avec des résolutions différentes. Si une fenêtre est visible sur 2 écrans en même temps, on ne sait pas encore bien comment faire. L'approche ou on fait une mise à l'échelle entre les "points" et les pixels n'est pas forcément meilleure, par exemple sous Windows on se retrouve avec un rendu flou et très moche sur certaines applications. On aurait probablement le même genre de problème si une application essaie d'allouer un bitmap pour dessiner quelque chose hors de l'écran: comment savoir si ce bitmap va être ensuite affiché (un cas assez courant, ça permet d'éviter certains clignotements désagréables de l'interface), ou si c'est un traitement d'une image destinée à être enregistrée sur le disque dur, par exemple?
[^] # Re: Gestion des écrans haute résolution ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 18 ans. Évalué à 10.
Alors, dans l'idée c'est ça, mais la mise en pratique est plus compliquée.
On pourrait en effet choisir de changer le rapport entre "points" et pixels, mais il y a des cas ou l'application a vraiment besoin de manipuler des pixels directement, du coup ça mettrait le bazar.
Si on reprend la doc de BeOS à ce sujet:
"Une unité de coordonnées vaut 1/72 de pouce, environ un point typographique. Cependant, on considère que tous les écrans ont une résolution de 72dpi (peu importe la taille réelle), donc l'unité de coordonnée est en fait un nombre de pixels. Autrement dit, une unité est la distance entre le centre de deux pixels adjacents sur l'écran"
Lorsque le support de l'impression est arrivé, c'est clairement la deuxième définition qui a été retenue. Sur papier, on a des unités de 1/300 ou 1/600 de pouce selon l'imprimante utilisée. Il faut donc faire la mise à l'échelle en utilisant des polices de caractères plus grandes, etc.
La solution retenue est donc:
- Laisser l'utilisateur choisir une taille de texte dans les préférences (fait)
- Ajuster la taille de tous les éléments en fonction (le texte lui-même, les icônes, l'espacement entre les éléments de l'interface, etc (en cours)
- Ajuster la taille de texte (et du reste par conséquent) par défaut en fonction de la résolution de l'écran (pas encore fait, et de trop nombreux écrans ne donnent pas des informations correctes)
Il y a quelques détails pénibles, par exemple les constantes B_V_SCROLL_BAR_WIDTH et B_H_SCROLL_BAR_HEIGHT qui donnent l'épaisseur des barres de défilement et qui sont fixées à 16 pixels, ce qui est trop petit sur un écran haute définition.
Et là ou ça devient le bazar, c'est quand il y a plusieurs écrans avec des résolutions différentes. Si une fenêtre est visible sur 2 écrans en même temps, on ne sait pas encore bien comment faire. L'approche ou on fait une mise à l'échelle entre les "points" et les pixels n'est pas forcément meilleure, par exemple sous Windows on se retrouve avec un rendu flou et très moche sur certaines applications. On aurait probablement le même genre de problème si une application essaie d'allouer un bitmap pour dessiner quelque chose hors de l'écran: comment savoir si ce bitmap va être ensuite affiché (un cas assez courant, ça permet d'éviter certains clignotements désagréables de l'interface), ou si c'est un traitement d'une image destinée à être enregistrée sur le disque dur, par exemple?