Text Editor component

[adrientetar]

It would be nice to have a text editor component with syntax highlight, line numbers, autocompletion.

I'll probably give it a shot if someone can give an overview of how to implement this efficiently in UWP.

[Odonno]

@adrientetar So, that would be a Code Editor, and not a Text Editor?

If that's so, we should reuse the beautiful Monaco Editor. https://microsoft.github.io/monaco-editor/
I suppose the easiest way to integrate it is to use an embedded webview.

[adrientetar]

Well, code is a special kind of text.

I am using Monaco in a web view currently but:

1. web view has an initial white flash before it loads the page
2. web view swallows some events like drag and so it prevents performing a file drag on the page when hovering over the web view
3. needs a special bridge to communicate with c#, all the editor logic is to be written in js, won't use XAML brushes events etc etc.
4. no native focus rect, caret, narrator support

Those are some of the advantages of using native controls, I mean many controls on this repository could probably just be done in a web view as well.

[Odonno]

@adrientetar Nice arguments. A native Monaco editor for UWP would bring a better user experience but from my point of view, it's a huge amount of work unless someone already did it.

I don't say we should not do it, we first need to see the value of this. Can you create a uservoice entry for a native Monaco editor? Here is the link https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/193402-uwp-community-toolkit

[hawkerm]

I can't believe the timing of this. I just started wrapping Monaco in a UWP runtime component this weekend: https://github.com/hawkerm/monaco-editor-uwp

Not sure if it makes sense to pull into the toolkit with the dependency, but it's a start. There's a lot of work left to be done on the wrapper, but I did fix your first issue on your list. It doesn't show until it's ready to render, so there's no flash of a white blank page.

[Odonno]

@hawkerm Nice. When do you think you can have a first version with the most wanted features (drag'n'drop, C# <-> JS communication, events) ? Can you post some screenshots of the result once it is done?

I suppose we can integrate it in the Toolkit later but first, I think you should stay on your repository for now.

[hawkerm]

@Odonno I'm developing it for some other projects, so whatever I need for those is going to get done first, next on my list are things like line highlighting (for like error messages).

I did take a look at drag'n'drop quite a bit last night actually. I had some of the tracking and event propagation hooked up, but there are a couple of issues. 1) I can't see a way that UWP let's you construct your own DragEventArgs, so the interface will have to be a bit different/simplified. 2) JavaScript/Edge serialization of the drag event in JavaScript doesn't work for some bizarre reason and returns a blank object. So, I'll have to do some more of the event parsing manually in JavaScript to hand-up to the C# layer.

This project is actually bleeding into my work life too, so I'll actually be working on this later in August more for some other Toolkit related things.

[hawkerm]

Released an update with very basic line highlighting support and keydown intercept support. (Had to rename the editor to not conflict with the namespace, so it's a breaking change).

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[Odonno]

I still see a great added-value on this control.

@hawkerm How is it going?

Otherwise, I am interested to see what @nmetulev used to render live XAML editing in the new Sample app.

[nmetulev]

The sample app is using @hawkerm's control :)

[Odonno]

@nmetulev Good. It looks like a really functional components.

[lucaasrojas]

Hey! What's the status of this issue?

[hawkerm]

@Kyaa-dost we can assign to me. I think we just need to decide if we want to pull this into the toolkit or not.

[michael-hawker]

I know there's been more recent conversations on this in the community discord. For now, bringing this into labs for visibility.

Like DataGrid, a code editor control is a project in itself. I don't think we'd have plans to bring anything this large into the toolkit. At least not within the repository directly, a project within the organization would be a different topic (e.g. similar for https://github.com/w-ahmad/WinUI.TableView as well on this specific note/example).

These large types of components really have their own requirements and need finer grained details afforded by being separate projects vs. overwhelming the size and scope of everything else that exists in the toolkit today. Though we've been working on abstracting our infrastructure as well, so projects looking to build components similar to how we do so in the toolkit could adopt that as well and work with us on any improvements in that space as well.

However, there's been great work done in the community on this front by wrapping the Scintilla editor. I'd suggest folks looking for this type of component check out the https://github.com/BreeceW/WinUIEdit project.

[lostluna1]

Thank you for reply, and understanding your concerns, WinUIEdit is still not a solution, it still has a very high memory footprint, even so, it is not as good as MonacoEditor in terms of functionality, in short, it is not recommended