Il y a une amélioration très intéressante dans Delphi, C++Builder et RAD Studio 11.0 Alexandria : l’IDE prend désormais entièrement en charge la mise à l’échelle haute résolution sur les écrans haute résolution. Cela signifie que si vous utilisez Windows et que vous disposez d’un écran haute résolution 4K ou similaire, l’IDE s’affichera de manière nette et claire sur votre écran. En fait, si vous avez deux écrans avec des échelles différentes, vous pouvez avoir différentes fenêtres IDE sur ces multiples écrans et chacun sera rendu parfaitement, net et clair, sur chaque moniteur. Cette prise en charge de la mise à l’échelle DPI élevée utilise la prise en charge de la VCL pour la mise à l’échelle perMonitorv2, que nous avons introduite il y a quelques versions, ainsi que notre propre collection d’images et nos composants de liste d’images virtuelles. En d’autres termes, nous utilisons les mêmes outils que nous mettons à votre disposition.
Il est important de noter que la prise en charge DPI élevée inclut la prise en charge dans l’éditeur de code, pour un texte net et lors de la conception de formulaires, à la fois VCL et FMX. (Si vous avez démarré RAD Studio 11 et que vous vous êtes dit « hé, ma fiche est petite ! », lisez la suite : nous avons des paramètres contrôlant la mise à l’échelle dans le concepteur de fiches VCL et vous êtes défini sur non mis à l’échelle par défaut.)
Examinons aujourd’hui le comportement de l’IDE sur les écrans haute résolution et basse résolution, quelques notes intéressantes sur la façon dont il a été implémenté, et examinons en particulier la conception de formulaires VCL.
Table of Contents
Comparaison haute résolution
La meilleure façon de voir la différence dans l’IDE est de l’utiliser. L’utilisation de l’IDE sur un écran haute résolution, c’est comme la nuit et le jour – il y a certaines choses que les captures d’écran ne transmettent qu’à moitié, et l’apparence et la convivialité de RAD Studio 11 en fait partie. En personne, c’est une différence incroyable.
Mais pour montrer ce que nous pouvons juste dans un article de blog, voici une excellente image créée par Jim McKeeth comparant les IDE 10.4.2 et 11.0 :
Sur la droite, le nouvel IDE à haute résolution de la v11. Il est net et clair, quelle que soit la taille de l’échelle.
Vous pouvez voir que l’image de droite, dans la v11.0 Alexandria, le texte et les icônes sont clairs, quelle que soit la taille de l’écran sur lequel l’IDE est placé.
Contexte – pourquoi un DPI élevé ?
Une échelle typique définie dans Windows aujourd’hui est de 200 %. C’est 2x la densité de pixels, ce qui signifie vraiment que pour chaque pixel dans le passé, il y a maintenant quatre pixels (il est divisé en deux verticalement et horizontalement.) J’écris ceci sur un moniteur 4K, qui mesure 2160 pixels de haut. C’est 2 fois 1080, une résolution verticale qu’avant le DPI élevé j’ai utilisé pendant des années. Pour que tout apparaisse à la même taille physique à l’écran, je dois redimensionner par 2.
Si une application ne prend pas en charge le DPI élevé (n’est pas compatible avec le DPI), Windows la redimensionnera, mais la mise à l’échelle ajoute du flou. C’est bien mieux si une application est consciente de la mise à l’échelle appliquée à l’écran de ses fenêtres et peut dessiner de manière nette. Nous avons ajouté la prise en charge de la VCL pour cela dans 10.3 , en prenant en charge la mise à l’échelle haute résolution perMonitorv2 (la dernière et la meilleure des options fournies par Windows) et en ajoutant des composants pour les icônes haute résolution et le dessin d’images , offrant une meilleure prise en charge des images haute résolution dans les barres d’outils et les menus que Windows a intégrés. L’IDE, qui est principalement construit avec la VCL, les utilise et constitue une excellente démonstration des capacités de la VCL.
L’IDE utilise des styles pour dessiner ses thèmes clair, sombre et brumeux, et les styles VCL prennent également en charge la mise à l’échelle DPI élevée .
Concepteurs de formulaires à haute résolution
Alors que la prise en charge DPI élevée de la VCL est en grande partie une question d’ activation de la prise en charge de perMonitorv2 dans la page Application > Manifeste des options de votre projet et de la recompilation, ainsi que la mise à jour des images (plus d’informations ci-dessous) et la mise à jour de tout dessin personnalisé ou des constantes de pixels codées en dur pour utiliser le Surcharges ScaleValuepour obtenir le nouveau point, valeur, rect etc. pour le formulaire à haute résolution, ce n’est pas aussi simple que cela. Nous avions un domaine spécifique qui ne s’appliquait pas aux applications client sur lequel nous devions travailler, et c’est celui-ci qui a pris la plupart de nos efforts de développement. En fait, la recherche et le prototypage de la meilleure approche ici sont l’une des raisons pour lesquelles il a fallu attendre la v11 pour implémenter un DPI élevé dans l’IDE après que nous ayons introduit la prise en charge de la VCL elle-même dans 10.3. Cette zone est le concepteur de formulaires VCL. Nous avons trouvé une solution qui, nous l’espérons, répond à tous les besoins.
Vous pouvez mettre à l’échelle le concepteur de formulaire VCL à n’importe quel DPI (n’importe quelle échelle.) Ceci est fait en utilisant la même technologie de mise à l’échelle que la VCL utilise lors de la mise à l’échelle au moment de l’exécution, c’est-à-dire lorsqu’une application est exécutée et qu’elle doit ajuster sa taille et sa disposition pour correspondre l’écran c’est allumé. Ce paramètre se trouve dans Outils > Options > Interface utilisateur > Concepteur de formulaires > DPI élevé. Lorsque vous le modifiez, vous devez fermer et rouvrir le concepteur de formulaires pour avoir un effet.
Par défaut, lorsque vous ouvrez un formulaire, le formulaire est conçu à 96 DPI, c’est-à-dire à 100 %. Cela signifie que si votre IDE est à 200%, le formulaire apparaîtra plus petit que les contrôles qui l’entourent. Un élément clé de la connaissance est que lorsqu’un formulaire est mis à l’échelle, les propriétés Gauche, Hauteur, etc. sont modifiées – c’est exactement la même chose que lorsque vous exécutez une application et qu’elle est mise à l’échelle ; ces valeurs sont multipliées par l’échelle de l’écran. La conception à 100 %, la valeur par défaut, signifie que le formulaire n’est pas du tout mis à l’échelle : l’ouverture d’un formulaire ne modifie pas les valeurs stockées dans le DFM par rapport à son ouverture dans, disons, 10.4.2. Si vous installez la v11 et remarquez que vos formulaires semblent petits, voici pourquoi : nous avons défini le comportement par défaut pour ne pas modifier un formulaire.
Nous allons probablement modifier la légende du concepteur de formulaire pour la mettre à l’échelle dans une prochaine version – actuellement, elle ne met à l’échelle que le contenu réellement conçu de votre formulaire.
Vous pouvez également laisser le concepteur de formulaire correspondre à votre écran. Cela signifie qu’un bouton sur un formulaire correspondra à la taille d’un bouton dans une boîte de dialogue IDE : il correspondra toujours à la mise à l’échelle de l’écran, peu importe l’écran ou la mise à l’échelle (125%, 150%, 300%…) C’est le plus pratique si vous voulez juste voir votre formulaire de la même taille que tout ce avec quoi vous interagissez dans l’interface utilisateur. Dans la boîte de dialogue Options de l’IDE, il s’agit de « Automatique » car il le définira en fonction de l’écran sur lequel se trouve le concepteur chaque fois que vous l’ouvrez.
Enfin, vous pouvez définir une échelle spécifique que vous utilisez pour la conception de formulaires. Cela peut être n’importe quelle échelle – 125%, 300%, tout ce que vous voulez.
Windows et donc la VCL utilise des coordonnées entières pour ses tailles et emplacements. Cela signifie que toute mise à l’échelle – de toute application – peut ne pas toujours être exactement précise. En pratique, c’est bien lors d’une mise à l’échelle une fois (comme lorsqu’une application est exécutée, et elle s’étend à partir des coordonnées basse résolution avec lesquelles elle a été conçue.) après le lancement. C’est plus important lors de la mise à l’échelle plusieurs fois (et c’est l’une des raisons pour lesquelles nous n’avons pas de fonctionnalité où vous concevez à n’importe quelle échelle mais réduisez à 100% lors de l’enregistrement.) Il est donc bien de concevoir à haute résolution à n’importe quelle échelle, et s’exécuter même à une échelle inférieure – la VCL mettra votre application à l’échelle correctement – mais il est important d’éviter de redimensionner encore et encore, ce qui se produira si chaque fois que vous ouvrez un formulaire dans le concepteur, il est ouvert à un DPI différent. Par conséquent,
Concepteur FireMonkey
Le concepteur FireMonkey est beaucoup plus simple. Il s’adapte simplement à la propre échelle de l’IDE, de la même manière que si vous mettez à l’échelle une application FMX dans le code. FireMonkey utilise des coordonnées à virgule flottante et n’a pas les mêmes considérations techniques que les applications VCL. Dans la v11, nous avons également modifié FireMonkey sous Windows pour utiliser un système de coordonnées basé sur les unités de l’appareil, et non sur les pixels, ce qui signifie que sur Windows, les formulaires FMX peuvent mieux s’adapter à l’échelle d’affichage que par le passé, y compris avec un rendu de meilleure qualité.
Modifications techniques
Les fournisseurs de composants n’ont besoin d’aucune modification des icônes qu’ils fournissent avec leurs composants, puisque nous prenons en charge les icônes de composants haute résolution au format PNG depuis 10.2.2 . Les fournisseurs de plugins ou d’addons ont de nouvelles API dans ToolsAPI pour ajouter des images dans la collection d’images haute résolution interne de l’IDE (elles sont hors de portée de cet article, mais vérifiez ToolsAPI.pas pour TGraphicArray : chacune de ces nouvelles surcharges permet d’ajouter plusieurs tailles de une image à la collection d’images soutenant les listes d’images de l’IDE.)
En interne, et cela n’affectera aucun développeur mais peut être intéressant à savoir : chaque formulaire IDE a sa propre liste d’images . Ceci est nécessaire pour la prise en charge DPI élevée car il s’agit d’un formulaire qui évolue, et deux formulaires sur deux écrans différents peuvent évoluer différemment, de sorte qu’une liste d’images ne peut pas être partagée entre plusieurs formulaires ou contrôles sur plusieurs formulaires car les images peuvent être de la bonne taille pour une forme mais fausse pour l’autre. En fait, dans le passé, l’EDI avait de toute façon plusieurs listes d’images à l’ancienne, souvent une par formulaire ; mais dans le passé, comme les listes d’images à l’ancienne stockaient leurs propres images, cela signifiait également que de nombreuses images étaient dupliquées. Un X de suppression rouge pouvait se trouver dans plusieurs listes d’images, ce qui rendait difficile la mise à jour des icônes.
L’IDE dispose désormais d’une seule collection d’images centrale . Cela contient toutes les images utilisées dans l’IDE (autres que les icônes de composants, stockées séparément.) Plusieurs listes d’images dans l’IDE se connectent à cette collection d’images. Dans le cadre de ce travail, nous avons utilisé à la fois un logiciel et l’œil humain pour dédupliquer les icônes, de sorte que la collection d’images a une seule copie de chacune. Cela a rendu beaucoup plus facile la mise à jour des icônes. La collection d’images dispose désormais d’un champ de commentaire pour chaque icône, également, qui peut être utilisé pour stocker toutes les informations que vous souhaitez : nous l’utilisons pour stocker des notes sur l’endroit et la manière dont l’icône est utilisée.
Nous espérons que cet aperçu de l’approche que nous avons adoptée pourra vous être utile lors de la mise à jour de votre propre logiciel vers un DPI élevé. Nous avons également une documentation complète sur les images à haute résolution ici .
Autres changements
Un dernier petit changement que nous avons apporté concerne certaines des icônes de l’IDE. La plupart des icônes ont été remplacées par des versions haute résolution (multi-res), afin qu’elles puissent être affichées de manière nette à n’importe quelle échelle. Cependant, nous avons également repensé certaines des icônes pour les éléments clés du produit.
Certains des boutons de barre d’outils les plus importants de l’ensemble de l’IDE sont Exécuter avec le débogage – c’est pour cela que vous utilisez l’IDE, en fin de compte ! – ainsi que des opérations de débogage telles que franchir, tracer, etc. Celles-ci ont toutes maintenant de nouvelles icônes spécialement conçues pour leur objectif, pour paraître claires mais aussi pour illustrer l’opération. Ils ressemblent à ça :
 |
 |
| The new Run with Debugging icon. It looks more like a Run symbol, and has a bug being squashed underneath. | Step Over – such a simple design! But I think a very elegant way of showing the concept |
Vous remarquerez peut-être que la partie Exécuter ressemble à l’ancienne icône d’exécution de Delphi 7 (moins large horizontalement), l’icône Plates-formes ressemble à celle que l’EDI avait l’habitude d’avoir un cercle de plusieurs parties (elle est destinée à indiquer l’unité de plusieurs éléments différents), et certaines autres icônes ont également de nouvelles versions.
De plus, nous sommes passés à Consolas comme police par défaut pour l’éditeur. Consolas est une police très semblable à Delphi – c’est-à-dire que vous aurez l’impression d’avoir utilisé l’ancienne police par défaut Courier New dans le passé (que vous pouvez toujours utiliser.) Nous installons également plusieurs polices de programmeur : Fira Code, Monoïde, Source Code Pro, etc.
IDE haute résolution
RAD Studio 11.0 apporte une refonte très demandée et très importante de l’IDE : prise en charge complète des DPI élevés. Un rendu net et clair sur tous les écrans, avec la prise en charge de la conception de formulaires à plusieurs échelles et un texte clair avec une police nouvelle mais familière dans l’éditeur, c’est l’un des changements et améliorations les plus importants que nous ayons apportés.