Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scenario: Add support for 3rd-party extensions #4000

Open
5 of 8 tasks
zadjii-msft opened this issue Dec 17, 2019 · 10 comments
Open
5 of 8 tasks

Scenario: Add support for 3rd-party extensions #4000

zadjii-msft opened this issue Dec 17, 2019 · 10 comments
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Scenario Product-Terminal The new Windows Terminal.
Milestone

Comments

@zadjii-msft
Copy link
Member

zadjii-msft commented Dec 17, 2019

Updated thread from #555

Now that we have a better understanding of what work will be needed to support 3rd party extensions ("plugins"), this thread is the megathread to track all the work that's needed to support them.

Before any real work can begin here, we're waiting on some support from the Windows operating system that will be coming SoonTM. Fundamentally, third-party code extensions for packaged applications (like us) isn't supported currently.

This is not work slated for 1.0. It may not even land in 2.0. This work will likely span multiple releases. Whenever this work does end up starting formally, we'll likely have a number of minor versions with prototypes of the extensibility model, with breaking changes up until the major version release of the Terminal. So if extensions are scheduled for 3.0, then 2.4 might introduce bts of the extensibility model that are later broken in 2.5, 2.6, etc.

What should extensions be able to do?

  • Add their own profiles via Dynamic Profile Generators
  • Customize the rendering of the Terminal, with things like:
    • custom shaders, font renderers
    • custom formatting of the buffer (like hyperlinks)
  • Add their own Color Schemes, keymaps
  • Modify the UI theme (for adjusting appearance of tabs, scrollbars, etc.)
  • Modify the layout of the UI
    • Add elements to the UI like status bars, toolbars, minimaps
    • reposition existing elements of the UI? Tabs on bottom for example.
  • Create Panes with their own UI elements
  • Read the contents of the text buffer, for parsing things like hyperlinks
  • When extensions modify the UI, they'll need to adjust how large the initial window size is
  • Add commands to the Command Palette, including nested commands
  • Add commands to various context menus (such as the TermControl context menu, TabViewItem menu).

Work needed to support extensions

Some of this work is more directly related to extensions, while others on the list are simply adding features to the terminal to provide points for extensibility in the future.

Mega-list of extension ideas

Dynamic Profiles / settings

Additional Connection types

Buffer Parsing/Manipulation

Suggestions

UI Elements

App elements

Control Elements

Other Elements

Custom Rendering

Advanced Settings

Miscellaneous


@ future me, 10/14/2021

I tried this in dev/migrie/fhl/adaptive-card-extension, but ran into a number of unfixable build issues that made me hate the world. I couldn't get another package built to be able to load that into the terminal at all. Maybe next month I'll try again. For now, it's on to honks.

@zadjii-msft zadjii-msft added Product-Terminal The new Windows Terminal. Issue-Task It's a feature request, but it doesn't really need a major design. labels Dec 17, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Dec 17, 2019
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Dec 17, 2019
@zadjii-msft zadjii-msft added Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Scenario and removed Issue-Task It's a feature request, but it doesn't really need a major design. labels Dec 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Dec 17, 2019
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Dec 19, 2019
@WSLUser
Copy link
Contributor

WSLUser commented Feb 11, 2020

You should add #3468 that needs to be brought into an extension instead of living in the main code base.

@gbritton1
Copy link

Why on earth would you need support from the WIndows team? That doesn't apply to VS code, e.g. in any environment. Can't we just do it the same way?

@DHowett
Copy link
Member

DHowett commented Nov 5, 2021

@gbritton1 Terminal is (for better or for worse) deployed as a "MSIX" package using the new Windows packaging/installer infrastructure; VSCode is not. That infrastructure is missing some features that would allow for:

  • "In-process" extensions, which...
  • ...support being updated while they're in use, and...
  • ...can be installed for multiple users trivially.

Had we chosen to install using MSI, traditionally, into C:\Program Files... yeah, we wouldn't need anything else from the package subsystem. We'd also lose(1) support for easy, atomic updates for the entire Terminal. 🤷🏻

We've since learned that there's a way forward where we don't need in-process extensions, but we do want to make sure that it will perform adequately for things that impact the rendering engine or the text buffer.

(1): "Lose" insofar as it is easy. We could always write a bunch of code to support it, but on the balance we decided to invest most of our effort in making the Terminal and Console Host itself better. :)

@gbritton1
Copy link

gbritton1 commented Nov 5, 2021 via email

@ntindle
Copy link

ntindle commented Nov 5, 2021

I'm glad you put this out there. I honestly had the same opinion on why it required updates on the windows side. Thanks for clarifying that.

@zadjii-msft
Copy link
Member Author

zadjii-msft commented Apr 20, 2023

Notes comment:

See https://github.com/microsoft/terminal/tree/dev/migrie/fhl/dyndep.

microsoft/WindowsAppSDK#66

Todo

  • Find 3p app using extension catalog
  • Register it as a dependency using dyndep
  • Be able to instantiate a WinRT class implemented in that package which implements an interface we declare.
  • Figure out why the SampleApp package always wants to include MUX 2.7 in its package. Just manually deleting its activatableClasses from the Appxmanifest.xml worked but, sheesh
    • I didn't hit this in my public/terminal clone, only the private/Openconsole one. So maybe it's just a dirty repo.
  • Actually communicate the class name in the properties of the extension implementation
  • Create some sort of "smart dyndep scope" class / struct, to keep the package dependency alive...
    • ... and release the dependency when no longer needed
  • Try to get the extension to return a XAML object, created in codebehind
    • 🎉 This is like a pretty big milestone IMO 🎉
  • Try to get the extension to return a XAML object, as defined in XAML
  • Try to get the extension to implement a "HackerTyperConnection : ITerminalConnection"
  • Clean up the way the extension projects build. Right now they're all bog-standard so they scatter shit all over the build tree. use the common props instead.
  • Can an extension that creates a XAML button that gets added to the UI tree then somehow iterate upwards and get at the XamlRoot (and therefore, the whole Terminal UI tree?)
    • Or, acutely, just get at the XAML root even without user interaction like that?
  • C#?
    • This was pain
  • more...

Notes circa May 2023 Hackathon

  • DynDep works perfectly.
  • You can totally have an extension host instantiate classes that are hosted in another package.
    • You absolutely need to make sure they are declared as activatableClasses in the extension's manifest. This will only happen if you have a separate component (dll) that implements it. Hence ExtensionHost and ExtensionComponent. Component actually does the hard work.
  • Extensions can build WinUI types at runtime, and add them to the host's UI: e0c8135
  • You can even have the extension return a WebView2! That's awesome. 497fea8
  • You need to make sure to keep a reference to the extension class, obviously, but even WinRT events work too: 82dc26f
  • C# might be Hard to do. I don't think I understand how it works with WinRT anymore. I was able to convince the tooling that my class implemented the interface from the C++ project, but I don't know how to package it up to make it callable. And IIRC the new C#/WinRT stuff is all WASDK which is all WUI3 which is incompatible with WUI2.

Now, the questions are:

  • How do we feel about in proc extensions?
  • What do we want to expose as extensibility points?
    • Additional actions
    • Additional profiles / dynamic profile sources
    • Send actions to the Terminal
    • Custom actions
    • Custom panes / UI surfaces
    • Custom suggestion sources
    • Custom connection types

@jonwis
Copy link
Member

jonwis commented May 14, 2023

@zadjii-msft before you merge this we should chat. See my comment here - microsoft/WindowsAppSDK#66 (comment)

@zadjii-msft
Copy link
Member Author

@jonwis haha don't worry - that was firmly FHL code, not real shipping code. I use FHL to push the boundaries of what the platform will let me do. But I'm absolutely going to make sure there's proper boundaries set up here before doing anything like this in real Terminal code 😆

@jonwis
Copy link
Member

jonwis commented May 15, 2023

(Also, don't get me wrong - I love it when we figure out the power latent in the platform. We've done sooo much here over the years that compiles together well but we don't have enough time or hands to document all the possible combinations. :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Scenario Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

7 participants