Terminal: Demande de fonctionnalité : options d'opacité standard comme la console traditionnelle.

Ce n'est pas pris en charge pour le moment, mais c'est certainement quelque chose que nous ne voulons pas perdre de vue. Nous devrons faire un peu de travail lourd pour que les visuels de la composition soient correctement configurés, mais c'est "dans le plan".

Voir aussi #593, qui contient des informations supplémentaires.

J'aime la transparence classique, mais je n'ai jamais utilisé d'acrylique, une des fonctionnalités indispensables pour moi :)

+1 à ce sujet !

S'il vous plaît ne faites pas de problèmes "+1", cela crée du bruit inutile. Il y a un très bon bouton +1 ici :

@zadjii-msft avec Microsoft, il n'existe pas de "bouton +1 parfaitement bon", même en faisant du bruit, personne ne s'en soucie vraiment ou n'écoute rien. Je suppose que quiconque a déjà utilisé un produit Microsoft le sait.

Mais bon, j'ai compris. Désolé.

@TCB13 Juste pour que vous le sachiez, nous sommes tous de vraies personnes ici assises dans nos bureaux en train de regarder nos boîtes de réception, notre file d'attente de triage et la liste des problèmes de github. Nous lisons chacun de ces numéros, et nous ressentons des choses à leur sujet et ce que les gens y disent. Essayez d'éviter d'être méchant.

@DHowett-MSFT @zadjii-msft

Le fait que l'acrylique ait été inclus au lieu de l'opacité signifie vraiment que personne n'a réellement considéré la convivialité de ce terminal. Il me semble qu'un PM vient de dire "Oh, les choses transparentes ont l'air cool, rendons-les encore plus cool et ajoutons-y un flou!". Les applications/fenêtres de terminal ne sont généralement pas transparentes car elles ont fière allure, elles sont transparentes car elles vous permettent de voir d'autres éléments derrière la fenêtre - une fonctionnalité utile comme la plupart des utilisateurs seront d'accord.

Vous devriez peut-être demander aux autres personnes de votre entreprise pourquoi j'ai été si agressif dans mon autre commentaire. :)

@ TCB13 , des voix demandaient l'ajout d'acrylique au terminal de commande, et à l'époque, ce n'était pas possible pour des raisons de compatibilité descendante, mais un nouveau terminal rend cela possible.

Le problème avec cette nouvelle version est que l'opacité n'est pas immédiatement possible avec les nouvelles API de fenêtrage qu'elle utilise, et c'est quelque chose dont l'équipe est consciente et qu'elle essaiera de rendre possible.

Il n'est pas nécessaire d'être aussi dédaigneux, simplement parce que ce n'est pas une fonctionnalité que vous souhaitez ou dont vous avez personnellement besoin.

Ce serait très utile.

En plus de ce qui a déjà été dit, la possibilité d'avoir la fenêtre acrylique lorsqu'elle est focalisée et transparente lorsqu'elle n'est pas focalisée serait très agréable car cela rendrait cette transition moins discordante.

D'accord. Personnellement, je veux le réglage d'opacité régulier car j'aime les arrière-plans très sombres avec une légère transparence. Lorsque j'ai essayé d'utiliser les options acryliques, l'arrière-plan était trop lumineux à mon goût. Je suis un vampire je suppose .

Content d'apprendre que c'est au moins prévu. Merci d'avoir créé cet outil et j'attends avec impatience les prochaines versions avec plus de fonctionnalités comme celle-ci.

D'accord. Personnellement, je pense que la fenêtre prend soudainement une couleur unie lorsqu'elle perd la mise au point. La transparence traditionnelle est une meilleure transition
Content d'apprendre que c'est au moins prévu. Merci d'avoir créé cet outil et j'attends avec impatience les prochaines versions avec plus de fonctionnalités comme celle-ci.

Le vrai, c'est que je n'utiliserai pas de console, quand il n'y aura pas de transparence classique :), c'est une fonctionnalité indispensable pour moi :)

ce n'est pas lié à ce problème mais plutôt à des ensembles de messages.

> Il n'est pas nécessaire d'être aussi dédaigneux, simplement parce que ce n'est pas une fonctionnalité que vous souhaitez ou dont vous avez personnellement besoin. lorsque les gens semblent déconnectés des attentes communes de la majorité des utilisateurs d'applications, ils reçoivent des réponses passionnées. et la transparence est disponible depuis longtemps, donc ce n'est pas une seule personne qui fait pression sur les développeurs pour plaire à une seule personne. comme votre dernière déclaration l'implique, pour une raison quelconque ; n'hésitez pas à le modifier. peut-être que TCB13 était impoli ou agressif dans un autre fil ou occasion ? comme son hyperbole pour la plupart inoffensive dans https://github.com/microsoft/terminal/issues/603#issuecomment-508031247 --- également, silverqx, voir https://github.com/microsoft/terminal/issues/603#issuecomment -546613996 https://github.com/microsoft/terminal/issues/603#issuecomment-507248317 et depuis combien de temps https://github.com/microsoft/terminal/tags?after=RS2-final est-il depuis première sortie publique. Il semble que cela prendra beaucoup de temps. ne le faites pas deux fois, voir https://github.com/microsoft/terminal/issues/603#issuecomment-507835880 --- de https://github.com/microsoft/terminal/issues/603#issuecomment-529696036 , iCodeSometime, pas d'acrylique s'il vous plaît. laissez simplement l'acrylique être invisible pour ceux qui veulent utiliser la transparence. la façon dont cmd gère c'est sympa.

pour cmd, je préfère 80 % à 95 % d'opacité, c'est-à-dire la transparence. Ce sont les mêmes choses.

l'acrylique est translucide, je pense. Je devrai tester car je le désactive sur toutes les machines Windows que j'utilise.

salutations ratatoeey

Donc pour info, j'ai joué avec ça. Une implémentation rudimentaire n'est pas super délicate, mais elle n'est pas... raffinée. La fenêtre entière devient également transparente, y compris les contrôles XAML (ligne d'onglet, boîtes de dialogue, etc.). Je pense que du point de vue de l'architecture, il serait exceptionnellement difficile d'essayer d'obtenir _juste_ le contenu "Terminal" transparent, et même alors, tous les volets seraient également transparents, y compris les séparateurs, et les dialogues seraient également toujours transparents.

Assez étrangement, le MenuFlyout pour le nouvel onglet déroulant _ne devient pas_ transparent, ce qui soulève plus de questions.

Honnêtement, à mon avis, l'expérience semble un peu grossière. Si c'est ce que les gens veulent vraiment, je ne vais pas dire non, mais je veux aussi m'assurer que nous expédions quelque chose de haute qualité. C'est pourquoi je le laisse en attente, pour essayer de trouver une _meilleure_ solution.

En fait, j'aime les régions non clientes transparentes. C'est ainsi que cmd fonctionne, et depuis un certain temps (peut-être RS5 ?) :

Honnêtement, à mon avis, l'expérience semble un peu grossière. Si c'est ce que les gens veulent vraiment, je ne vais pas dire non, mais je veux aussi m'assurer que nous expédions quelque chose de haute qualité. C'est pourquoi je le laisse en attente, pour essayer de trouver une _meilleure_ solution.

J'aime assez cet effet - les seules fenêtres solides que je veux sont les boîtes de dialogue et les listes déroulantes - maintenant je suppose que j'ai juste besoin de le construire à partir de la source :-/

Merci pour le lien vers la modification !

Ouais, je pense aussi que tout ce qui est transparent est une fonctionnalité et non un bug 😄

La façon dont cmd le fait est très utile car vous pouvez lire ce qui se trouve en dessous (bien sûr, cela dépend du niveau de transparence pour paraître "bon").

Je suggère fortement que les développeurs examinent la fonctionnalité de gnome-terminal par rapport à la transparence comme guide. Pour ma part, je n'ai pas l'habitude de l'acrylique et de son flou. Je le veux transparent pour que je puisse voir à travers, qu'il soit focalisé ou non. Merci.

Donc pour info, j'ai joué avec ça. Une implémentation rudimentaire n'est pas super délicate, mais elle n'est pas... raffinée. La fenêtre entière devient également transparente, y compris les contrôles XAML (ligne d'onglet, boîtes de dialogue, etc.). Je pense que du point de vue de l'architecture, il serait exceptionnellement difficile d'essayer d'obtenir _juste_ le contenu "Terminal" transparent, et même alors, tous les volets seraient également transparents, y compris les séparateurs, et les dialogues seraient également toujours transparents.

C'est bien d'avoir la barre d'onglets transparente, toute la fenêtre doit être transparente, avec des barres de défilement aussi.
Il serait beaucoup mieux d'avoir un peu plus de transparence pour le contenu du terminal que pour la barre d'onglets et la barre d'état, par exemple environ 10%, mais cela a une priorité inférieure et ce n'est pas substantiel.
Les dialogues modaux doivent être opaques, personne ne veut avoir de dialogues transparents. ??
L'idéal serait d'avoir une transparence différente pour le texte et l'arrière-plan, le texte devrait être un peu moins transparent que l'arrière-plan, pour le rendre plus facile à lire.

L'essentiel ici est de faire bien paraître. ??

Assez étrangement, le MenuFlyout pour le nouvel onglet déroulant _ne devient pas_ transparent, ce qui soulève plus de questions.

Ce n'est pas grave, ces menus déroulants ou déroulants n'ont pas besoin d'être transparents, il est préférable de les avoir opaques.

Honnêtement, à mon avis, l'expérience semble un peu grossière. Si c'est ce que les gens veulent vraiment, je ne vais pas dire non, mais je veux aussi m'assurer que nous expédions quelque chose de haute qualité. C'est pourquoi je le laisse en attente, pour essayer de trouver une _meilleure_ solution.

Il faut peu jouer avec, le fond violet n'est pas un bon exemple pour un fond transparent, c'est beaucoup mieux avec un fond noir.
Quelques exemples 1 , 2 .

Si vous configurez une transparence bonne et équilibrée pour un terminal, cela peut vous aider dans certains scénarios, dans mon flux de travail, cela m'aide dans 5 à 10% des cas, lorsque je n'ai pas à basculer vers la fenêtre sous-jacente. C'est bien d'un point de vue pratique et la valeur ajoutée est qu'il est beau. ??

Voici un lien vers le code, comment il est implémenté dans conemu.

@zadjii-msft Je serais tout à fait d'accord avec votre transparence expérimentale si elle était implémentée comme dans ma suggestion
concentré - utiliserAcrylique
flou - utiliser la transparence

https://github.com/microsoft/terminal/issues/4413

De gauche
CMD standard avec transparence, terminal focalisé, terminal d'arrière-plan

Pouvez-vous s'il vous plaît ajouter des options différentes pour l'arrière-plan transparent et le texte (avant)
Je ne veux pas de texte transparent. C'est difficile à lire. Mais je veux un fond transparent

@zadjii-msft @cannelle-msft

J'aimerais un bouton Peek sur la barre de titre près du bouton nouvel onglet + ou du bouton minimiser - , tout comme Aero Peek.

Si vous refaites le travail de composition, pensez à l'ajouter à la barre de titre. Ainsi, lorsque je survole, je peux voir l'écran derrière, plutôt que de rester transparent tout le temps.

__relativement lié__

Pouvons-nous avoir un bouton plein écran sur la barre de titre sur toutes les applications qui permettent de maximiser (oui dans le terminal aussi) ! Je pense que nous devrions également ajouter Peek à la liste à mon humble avis, si nous ajoutons le système de fenêtrage lui-même.

@Nirmal4G J'ai déplacé votre première demande au #5426. Je suis à peu près sûr que nous ne pouvons rien faire à propos de votre deuxième demande - cela ressemble à un changement assez important dans le fenêtrage de _toutes_ les applications Windows. Ce pourrait être une demande qui s'intégrerait bien chez Microsoft/PowerToys . IIRC, l'un des powertoys originaux a fonctionné en modifiant les boutons de légende de la barre de titre

Étant donné que cela semble être le problème fourre-tout pour la transparence et l'acrylique... Je viens d'installer cette application Bloc-notes qu'un autre gars de MSFT a fait pendant son temps libre, et elle semble être capable de maintenir la transparence de l'acrylique tout en étant floue en arrière-plan. Il utilise également XAML et Windows.UI.

Veuillez également ajouter cette capacité à un moment donné. Merci.

La page du projet : https://github.com/JasonStein/Notepads

--Éditer:
En survolant le projet, il crée son propre pinceau acrylique personnalisé pour tout cela :

https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

Je ne pense pas qu'ils disent qu'ils ne peuvent pas garder l'acrylique lorsqu'ils

Yeaaaa, eh bien... La transparence/acrylique dans le terminal est le genre de régal pour les yeux que l'utilisateur s'attend probablement à être là tout le temps. Sinon, personne n'en voudrait, car l'avoir pendant qu'il est concentré ne fait pas grand-chose à cet égard.

En outre, les utilisateurs de terminaux sont probablement des utilisateurs avancés, qui envisagent également de devoir modifier un JSON pour l'activer, et seraient probablement conscients de l'impact de la batterie d'une manière ou d'une autre.

Pourrait encore le rendre facultatif.

@ futur moi :

• https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs
  
  
  
  • Tirez, cela utilise Win2D, que je ne suis pas sûr que nous puissions utiliser, car c'est C#
  
  
  • https://github.com/microsoft/Win2D/blob/master/winrt/docsrc/CanvasDevice.xml / https://microsoft.github.io/Win2D/html/M_Microsoft_Graphics_Canvas_CanvasDevice_GetSharedDevice.htm
  
  
• Il existe cependant https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.compositor.createhostbackdropbrush?view=winrt-18362
  
  
  
  • ça a l'air prometteur
  
  
• https://stackoverflow.com/questions/43208841/how-to-use-acrylic-accent-createhostbackdropbrush-in-windows-10-creators-upd/44576160
• Ensuite, nous écrirons du code

            auto rootVisual = winrt::Windows::UI::Xaml::Hosting::ElementCompositionPreview::GetElementVisual(RootGrid());
            auto compositor = rootVisual.Compositor();
            auto rootSprite = compositor.CreateSpriteVisual();
            rootSprite.Size(winrt::Windows::Foundation::Size(
                ::base::saturated_cast<float>(RootGrid().ActualWidth()),
                ::base::saturated_cast<float>(RootGrid().ActualHeight())));

            auto b = rootVisual.Compositor().CreateHostBackdropBrush();

            rootSprite.Brush(b);
            winrt::Windows::UI::Xaml::Hosting::ElementCompositionPreview::SetElementChildVisual(RootGrid(), rootSprite);

• Oh non, même avec ça, nous obtenons du contenu pré-flou
  

• Ce qui m'amène à https://github.com/Microsoft/WindowsCompositionSamples/issues/202

• Ce qui m'amène à boucler la boucle à l'enquête que j'ai déjà menée l'année dernière https://github.com/microsoft/terminal/issues/1753#issuecomment-508070516

Je ne promets rien ici, je laisse juste des notes de l'onglet que j'ai ouvert ce matin

Attends, je l'ai bien lu ? Avoir une fenêtre partiellement transparente ou un acrylique sans flou n'est pas faisable pour des raisons de sécurité ? Quoi?

Comme beaucoup, je veux/ai besoin désespérément d'une semi-transparence terminale comme elle a été utilisée sur le front *nix depuis des lustres. Devons-nous vraiment suivre la "route de l'économiseur d'écran", capturer l'écran pendant la peinture, peindre la capture comme image d'arrière-plan dans la fenêtre, puis peindre l'opacité par-dessus ?

Je veux dire, dans quelle mesure une fenêtre semi-transparente pourrait-elle être un vecteur d'attaque… même un enregistreur de frappe entièrement transparent désactiverait la fenêtre. Vraiment curieux. Et déconcerté. Mais surtout curieux.

Certes, ce fil est assez ancien, à une époque où la seule façon de faire de l'acrylique était à partir d'une application UWP pure. Les UWP sont assez fortement isolés contre la capacité de lire l'état d'autres processus sur le système. Si une application dans ce contexte pouvait trivialement préparer le contenu de la fenêtre derrière elle, alors elle pourrait théoriquement lire le contenu de tout ce qui s'exécute sur le système, dans _n'importe quel_ contexte. C'est quelque chose qui n'est absolument pas possible pour les applications UWP.

Le monde a beaucoup changé depuis lors - il y a des applications comme le Terminal qui utilisent UWP XAML (et acrylique) mais _ne sont pas_ les applications UWP. Dans ce nouveau modèle, il nous serait peut-être possible de faire quelque chose différemment, nous avons juste besoin de faire plus de recherches.

En lisant la source de AcrylicBrush , j'ai peut-être trouvé une solution de contournement. Mais prenez cela avec un grain de sel car j'ai une expérience minimale du développement d'interface utilisateur Windows.
Il semble qu'une méthode d'usine dans le pinceau acrylique prenne en charge les arrière-plans pré-flous, apparemment là où le shell l'aurait déjà fait, SI cette méthode est exposée et SI un arrière-plan non flou est passé comme arrière-plan pré-flou et SI Je ne suis pas totalement hors de propos ici, l'usine pourrait ne pas ajouter d'effet de flou du tout. Mais encore une fois, j'ai de fortes chances de me tromper à 150% ici, alors, prenez cela comme vous le souhaitez.

OMG, cette discussion a plus d'un an, mais l'essentiel de la transparence du verre n'est toujours pas mis en œuvre. Il est standard pour les terminaux Unix.

@alxkvx Comme discuté en détail dans ce fil de discussion, il s'agit d'un problème techniquement difficile, d'où la raison pour laquelle il n'a toujours pas été implémenté. Si vous avez des suggestions sur _comment_ cela pourrait être implémenté avec notre pile d'interface utilisateur, je serais heureux de les entendre.

@alxkvx Comme discuté en détail dans ce fil de discussion, il s'agit d'un problème techniquement difficile, d'où la raison pour laquelle il n'a toujours pas été implémenté. Si vous avez des suggestions sur _comment_ cela pourrait être implémenté avec notre pile d'interface utilisateur, je serais heureux de les entendre.

eh bien, je n'ai pas vraiment creusé le problème, et je ne comprends pas pourquoi la pile d'interface utilisateur a des problèmes avec cela, je sais qu'en utilisant le terminal WSL, je peux simplement cliquer avec le bouton droit de la souris sur> Propriétés> Définir l'opacité et j'obtiendrai la transparence du verre. Pour moi personnellement, c'est une caractéristique essentielle.

Le flou et l'opacité lorsque le terminal n'est pas mis au point est tout simplement idiot. Qui a demandé ça ? 🤷 Je continuerai à utiliser cmd et powershell.

@alxkvx Comme discuté en détail dans ce fil de discussion, il s'agit d'un problème techniquement difficile, d'où la raison pour laquelle il n'a toujours pas été implémenté. Si vous avez des suggestions sur _comment_ cela pourrait être implémenté avec notre pile d'interface utilisateur, je serais heureux de les entendre.

eh bien, je n'ai pas vraiment creusé le problème, et je ne comprends pas pourquoi la pile d'interface utilisateur a des problèmes avec cela, je sais qu'en utilisant le terminal WSL, je peux simplement cliquer avec le bouton droit de la souris sur> Propriétés> Définir l'opacité et j'obtiendrai la transparence du verre. Pour moi personnellement, c'est une caractéristique essentielle.

Le problème est que le framework d'interface utilisateur (UWP XAML) dans lequel le terminal Windows est intégré ne prend tout simplement pas en charge une transparence totale comme les applications win32 ou WPF (par exemple, le terminal wsl). Le seul outil auquel ils ont accès est l'acrylique, qui est moins destiné à la transparence et plus à l'accent du design. L'implémenter sous leur pile d'interface utilisateur nécessiterait une solution bidon comme mon commentaire ci-dessus ou un remaniement total du rendu de la console (du moins c'est ce que je comprends, l'interface utilisateur Windows n'est pas mon domaine de développement)

Edit : clarification

@alxkvx Comme discuté en détail dans ce fil de discussion, il s'agit d'un problème techniquement difficile, d'où la raison pour laquelle il n'a toujours pas été implémenté. Si vous avez des suggestions sur _comment_ cela pourrait être implémenté avec notre pile d'interface utilisateur, je serais heureux de les entendre.

eh bien, je n'ai pas vraiment creusé le problème, et je ne comprends pas pourquoi la pile d'interface utilisateur a des problèmes avec cela, je sais qu'en utilisant le terminal WSL, je peux simplement cliquer avec le bouton droit de la souris sur> Propriétés> Définir l'opacité et j'obtiendrai la transparence du verre. Pour moi personnellement, c'est une caractéristique essentielle.

Le problème est que le framework d'interface utilisateur (XAML) dans lequel le terminal Windows est intégré ne prend tout simplement pas en charge une transparence totale comme les applications win32 (par exemple, le terminal wsl). Le seul outil auquel ils ont accès est l'acrylique, qui est moins destiné à la transparence et plus à l'accent du design. L'implémenter sous leur pile d'interface utilisateur nécessiterait une solution bidon comme mon commentaire ci-dessus ou un remaniement total du rendu de la console (du moins c'est ce que je comprends, l'interface utilisateur Windows n'est pas mon domaine de développement)

Xaml prend en charge la transparence, mais pas les fenêtres UWP et les îles Xaml.

Lorsque Terminal est capable de passer à WinUI 3 Desktop et peut accéder au HWND lui-même, il pourra alors implémenter une transparence non floue.

L'acrylique lui-même sera retardé pour WinUI 3 - car ils doivent le retravailler tout en l'extrayant du système d'exploitation

Attendez non, dissipons certaines idées fausses - Nous sommes déjà en mesure d'accéder directement au HWND, car nous sommes déjà une application win32. Nous travaillons avec les équipes XAML et de composition pour essayer de trouver une solution à ce problème. D'après ma compréhension (actuellement), l'île XAML a toujours un arrière-plan opaque, ce qui signifie que nous ne pouvons pas simplement avoir des composants transparents dans XAML qui sont transparents jusqu'au HWND. Je ne sais pas si WinUI 3 résoudra cela par magie pour nous, ce dont nous devrons discuter davantage avec cette équipe. Heureusement, ils travaillent dans le couloir à côté de nous (ou du moins ils le faisaient quand nous travaillions tous dans des immeubles de bureaux), donc avoir ces discussions n'est pas trop difficile

@ futur moi :

• https://github.com/JasonStein/Notepads/blob/58530f19dd0173bab13e40c9511e5277e42c4129/src/Notepads/Brushes/HostBackdropAcrylicBrush.cs

  • Tirez, cela utilise Win2D, que je ne suis pas sûr que nous puissions utiliser, car c'est C#

Je suis à peu près sûr que Win2D prend en charge c++/winrt (c'est écrit en c++ !), mais même si ce n'est pas pour ce cas d'utilisation, il y a ceci :

https://github.com/fobrs/Win2DinMFC

Aussi, je pense que l'acrylique personnalisé devrait être possible car j'ai pu réaliser de l'acrylique (avec des coins

https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/tree/master/dotnet/WPF/AcrylicEffect

Et ce post est phénoménal :

https://notes.yvt.jp/Desktop-Apps/Enabling-Backdrop-Blur

Ceux-ci sont tous très utiles si vous utilisez WPF XAML, mais nous utilisons UWP XAML, qui aura malheureusement toujours la toile de fond opaque. Nous travaillons avec l'équipe WinUI pour, espérons-le, assouplir cette restriction pour WinUI 3.0. Il faudra peut-être un certain temps avant qu'il n'y ait d'autres progrès sur cette question, pendant que nous travaillons sur les spécificités techniques avec eux.

@ zadjii-msft Donc, vous me dites le contrôle WPF du terminal pourrait éventuellement soutenir acrylique flou acrylique

Oh non, le UWP XAML peut très bien prendre en charge l'acrylique, c'est juste "l'opacité traditionnelle" (opacité sans effet acrylique) que le UWP XAML ne peut pas prendre en charge actuellement.

J'aimerais que vous continuiez cette discussion ailleurs (peut-être déposer un nouveau problème si vous avez un problème ?) parce que c'est le fil pour la _transparence non floue_. Nous avons déjà « acrylique » dans le contrôle UWP, et discuter davantage de « comment obtenir de l'acrylique dans le contrôle UWP » est… Je veux dire, par exemple, essayer d'expliquer à un cheval comment il pourrait devenir un cheval s'il était vraiment, vraiment voulait?

@zadjii-msft @DHowett Désolé, je ne voulais pas dire ça. Par acrylique, je voulais dire acrylique avec un rayon de flou personnalisable

@zadjii-msft Je souhaite faire quelques expériences, pouvez-vous m'indiquer où la fenêtre d'hébergement xaml/DesktopWindowXamlSource est créée dans votre code ? C'est une très grande base de code 😅😅

@AnuthaDev C'est dans src/cascadia/WindowsTerminal/IslandWindow.cpp

D'accord, c'est au moins possible pour wpf à coup sûr :

Peut-être que la fenêtre dans IslandWindow.cpp peut être créée avec WS_EX_NOREDIRECTIONBITMAP et la méthode suivie ici peut être utilisée pour créer un pinceau acrylique sans flou . L'utilisation de createhostbackdropbrush() introduit automatiquement le flou, donc createbackdropbrush() est la seule option. Ou peut-être que ça ne marchera pas,... idk. Je vais essayer de vous tenir au courant....

Edit : Narrateur : Cela n'a pas fonctionné !

Peut-être que la fenêtre dans IslandWindow.cpp peut être créée avec WS_EX_NOREDIRECTIONBITMAP et la méthode suivie ici peut être utilisée pour créer un pinceau acrylique _non flou_. L'utilisation de createhostbackdropbrush() introduit automatiquement le flou, donc createbackdropbrush() est la seule option. Ou peut-être que ça ne marchera pas,... idk. Je vais essayer de vous tenir au courant...

Je ne pense pas car cette méthode est sous WPF. XAML est utilisé dans deux frameworks différents WPF (cette méthode) et UWP (utilisé dans WT). J'ai fouillé dans la source de l'acrylique UWP, et la seule chose qui pourrait éventuellement faire fonctionner la transparence traditionnelle est une solution de contournement vraiment Hakki où vous trompez essentiellement le système d'exploitation en lui faisant croire que l'arrière-plan a déjà été flou, donc il n'a pas pour ajouter un flou lui-même, mais je suis un joli arbre même qui n'est pas compatible avec les îles XAML.

@zadjii-msft @DHowett D'accord, alors voici ce que j'ai trouvé :
Il est certainement possible d'obtenir un flou acrylique personnalisé dans une application win32 c++ en utilisant win2d :

(Rayon de flou 1) :

TOUTEFOIS!! Vous ne pouvez pas le faire avec les îles xaml. Comme vous le savez déjà, il y aura certainement un arrière-plan opaque derrière xaml...

Pour ce faire, nous devons utiliser des API de composition et effectuer un rendu sur un hwnd DesktopWindowTarget.

Par conséquent, comme il est actuellement, pour obtenir la transparence non flou acrylique , nous aurions besoin d'enlever XAML îles et utiliser ce lieu d'un swapchainpanel.

(Si vous le savez déjà, désolé de vous avoir fait perdre votre temps...)

Par conséquent, pas de transparence sans un changement d'architecture significatif.

(Une conclusion qui était déjà apparente et à laquelle je n'ai absolument rien contribué😅😅)

Ouais, donc TLDR pour tous ceux qui ne veulent pas lire toute la discussion précédente est fondamentalement que le cadre qui est utilisé pour le terminal Windows ne prend pas actuellement en charge cette fonctionnalité CEPENDANT le développement sur ce cadre est en cours et la transparence (pour autant que je comprends il) est en préparation. Ainsi, ce n'est qu'une fois que le framework (îlots XAML) prend en charge la transparence que ce problème peut être démarré.

Ouais, donc TLDR pour tous ceux qui ne veulent pas lire toute la discussion précédente est fondamentalement que le cadre qui est utilisé pour le terminal Windows ne prend pas actuellement en charge cette fonctionnalité CEPENDANT le développement sur ce cadre est en cours et la transparence (pour autant que je comprends il) est en préparation. Ainsi, ce n'est qu'une fois que le framework (îlots XAML) prend en charge la transparence que ce problème peut être démarré.

Je me demande pourquoi la fonction de transparence n'a pas été incluse initialement dans ce projet et n'a pas été prise en compte lors du choix du moteur d'interface utilisateur. Ayant plus de 10 ans de travail avec des terminaux Linux, tous ont cette fonctionnalité et sont activement utilisés par de nombreux utilisateurs. Étrange pour moi.

Powershell et CMD ont la possibilité de définir la transparence. Je comprends que les technologies utilisées sont différentes mais de nombreux utilisateurs utilisent des configurations de transparence

Powershell et CMD ont la possibilité de définir la transparence. Je comprends que les technologies utilisées sont différentes mais de nombreux utilisateurs utilisent des configurations de transparence

oui, le même que le terminal WSL

La transparence CMD et PWSH est réalisable avec ce terminal, mais d'après ce que je comprends, la majorité des gens (moi y compris) ne veulent pas cette version de transparence, plutôt une transparence de terminal de type * nix, où seul l'arrière-plan est translucide au lieu de tout, texte inclus.

En outre, il existe des moyens bidons de simuler la transparence, avec une capture d'écran RECT, peinte sur le terminal lui-même, puis en peignant une couleur semi-transparente, mais même dans ce cas, il existe des limites et des pièges.

Peut - être que cela peut être mis en œuvre en créant une fenêtre ci - Interop peuvent être utilisés pour rendre le contenu avec un fond translucide ( comme donc ) à cette fenêtre. Ainsi, vous n'auriez pas besoin de supprimer les îles xaml et des éléments tels que les barres de défilement devraient toujours fonctionner, seule la partie swapchainpanel serait remplacée. Ou peut-être que si cela ne fonctionne pas, vous pouvez percer un trou sur la partie swapchainpanel à l'aide de HRGN, de sorte que la fenêtre de composition en dessous devienne visible. Il ne devrait pas y avoir de régression notable des performances passant de swapchainpanel à un hwnd (probablement)

Le problème avec la poursuite d'une solution de contournement pirate est qu'elle est pirate et intrinsèquement sujette aux bogues. WinUI 3 prendra très probablement en charge la fonctionnalité proposée, il est donc prévu de l'implémenter, c'est juste un jeu d'attente pour que la chaîne d'outils officielle la prenne en charge. Les développeurs ont déjà confirmé qu'ils collaboraient directement avec l'équipe WinUI à ce sujet.

(Une conclusion qui était déjà apparente et à laquelle je n'ai absolument rien contribué😅😅)

Je ne dirais pas que vous n'avez rien apporté - je suis toujours heureux d'avoir une confirmation externe de mes propres recherches. J'aurais été encore plus heureux si vous m'aviez prouvé le contraire et trouvé un moyen efficace de le faire

Comme mentionné précédemment dans ce fil de discussion - Nous travaillons avec l'équipe WinUI pour l'ajouter à WinUI 3.0. Je pense que cela est suivi dans https://github.com/microsoft/microsoft-ui-xaml/issues/1247. C'est la voie que nous suivrons pour que cette fonctionnalité soit ajoutée au terminal, car la conduite de cette solution signifie également la conduite d'une fonctionnalité de plate-forme de développement importante pour l'ensemble de la plate-forme, qui contribuera également à améliorer d'autres applications sur Windows.

Comme mentionné précédemment dans ce fil de discussion - Nous travaillons avec l'équipe WinUI pour l'ajouter à WinUI 3.0. Je crois que cela est suivi dans microsoft/microsoft-ui-xaml#1247 . C'est la voie que nous suivrons pour que cette fonctionnalité soit ajoutée au terminal, car la conduite de cette solution signifie également la conduite d'une fonctionnalité de plate-forme de développement importante pour l'ensemble de la plate-forme, qui contribuera également à améliorer d'autres applications sur Windows.

Puisque l'équipe du terminal a choisi une direction sur celle-ci, faut-il supprimer la balise « help want » ?

@tajetaje bonne prise, merci !

(Une conclusion qui était déjà apparente et à laquelle je n'ai absolument rien contribué😅😅)

Je ne dirais pas que vous n'avez rien apporté - je suis toujours heureux d'avoir une confirmation externe de mes propres recherches. J'aurais été encore plus heureux si vous m'aviez prouvé le contraire et trouvé un moyen efficace de le faire

Comme mentionné précédemment dans ce fil de discussion - Nous travaillons avec l'équipe WinUI pour l'ajouter à WinUI 3.0. Je crois que cela est suivi dans microsoft/microsoft-ui-xaml#1247 . C'est la voie que nous suivrons pour que cette fonctionnalité soit ajoutée au terminal, car la conduite de cette solution signifie également la conduite d'une fonctionnalité de plate-forme de développement importante pour l'ensemble de la plate-forme, qui contribuera également à améliorer d'autres applications sur Windows.

@zadjii-msft, je peux voir comment WinUI jouerait un rôle dans cela, mais je ne sais pas comment le problème sans frontières nous y amène. En termes de résultat réel recherché par la plupart des gens, je pense que c'est une belle interprétation de @mdtauk ( #743 ) de ce qui pourrait être :

(Une conclusion qui était déjà apparente et à laquelle je n'ai absolument rien contribué😅😅)

Je ne dirais pas que vous n'avez rien apporté - je suis toujours heureux d'avoir une confirmation externe de mes propres recherches. J'aurais été encore plus heureux si vous m'aviez prouvé le contraire et trouvé un moyen efficace de le faire
Comme mentionné précédemment dans ce fil de discussion - Nous travaillons avec l'équipe WinUI pour l'ajouter à WinUI 3.0. Je crois que cela est suivi dans microsoft/microsoft-ui-xaml#1247 . C'est la voie que nous suivrons pour que cette fonctionnalité soit ajoutée au terminal, car la conduite de cette solution signifie également la conduite d'une fonctionnalité de plate-forme de développement importante pour l'ensemble de la plate-forme, qui contribuera également à améliorer d'autres applications sur Windows.

@zadjii-msft, je peux voir comment WinUI jouerait un rôle dans cela, mais je ne sais pas comment le problème sans frontières nous y amène. En termes de résultat réel recherché par la plupart des gens, je pense que c'est une belle interprétation de @mdtauk ( #743 ) de ce qui pourrait être :

https://github.com/microsoft/microsoft-ui-xaml/issues/1247 suit à la fois sans frontières et la transparence