Scintilla on WinRT

[Neil Hodgson]

   Windows Runtime or WinRT (http://en.wikipedia.org/wiki/Windows_Runtime) is the API used for Metro apps on Windows 8. Scintilla works well in the desktop box of Windows 8 which will remain the best environment for heavyweight IDEs. However, there may be some opportunities for Metro applications containing source code display and editing where Scintilla could be useful. I've been taking a look at this and have published some experimental code as a Mercurial repository MetroSci at

https://bitbucket.org/nyamatongwe/metrosci

   It looks like this:

http://www.scintilla.org/MetroSci.png

   MetroSci contains two parts - a control called Skeen which is a port of Scintilla, and Schott which is an application that embeds Skeen. Schott initially shows a snippet of code. The black app bar at the bottom is shown/hidden with the secondary mouse button as is common with Metro. The Load File button displays a file selection screen where a file can be picked for editing. The Save File button saves any edits back to that file but this is experimental code so don't trust it on anything precious. Typing in the text box does incremental search and the Find button finds the next occurrence of the search text.

   Many standard Scintilla key actions work. Not all typed characters do - WinRT's key events are low-level so have to be translated from scan code and virtual key codes into characters and that code is incomplete. There isn't even a way to find out which modifiers are currently pressed so the code has to track press and release of the Shift, Ctrl, and Alt keys. The mouse works but fingers not-so-well. Good touch interaction would require more planning and implementation effort.

   WinRT includes DirectX with Direct2D and DirectWrite so the current implementation using Direct2D / DirectWrite was copied into Skeen. The scroll bar control wouldn't work so instead Skeen's drawing area is embedded into a ScrollViewer. This has some advantages such as supporting inertial scrolling but it also required some large changes to Scintilla and it means horizontal scrolling moves the margins too. There are 3 Microsoft-suggested ways to use DirectX in WinRT - with a simple surface matching the screen, with a virtual surface covering the document, or with direct control over the swap chain.

http://msdn.microsoft.com/en-us/library/windows/apps/hh825871.aspx

   The simple surface could work if the scroll bar was working and that would have required less changes to Scintilla. MetroSci uses the virtual surface approach. With this technique, image tiles are presented to application code to draw on and are cached as they may be redisplayed as scrolling occurs. This makes scrolling quite smooth. A tile may not be (all) visible on the screen when the drawing request occurs so the code in Scintilla that avoids drawing offscreen has to be disabled. Coordinates are also document-based - I did try using a transform so they would be screen based but that had bugs with scrolling backwards.

   To get styling working, a copy of all of SciTE's .properties files is embedded in Schott as C source code - ugly and it seems to slow initial load down but it makes for a more complete demonstration.

   I'm not planning on integrating this code into the standard distribution in the near future and it may be redesigned completely before inclusion if it ever happens. While Metro isn't currently meant for complex applications, it will probably be extended in the future. WinRT looks quite decent and could be extended for use as the primary API for desktop apps. 

   If you want to experiment with this code, you'll have to install the Windows 8 Release Preview along with the RC of Visual Studio 2012. Open the MetroSci.sln solution file, make Schott the Startup Project and press F5. VS will want to create and install a temporary developer key (due to Metro being locked down) so allow that.

   Neil

[Neil Hodgson]

FlashTek:

> But you didn't build in a textchanged event, or something equal, or did I just miss it?

No events had been implemented. Updated with all the Scintilla defined events. modifiedEvent should be used for detecting changes to the document text.

C++/CX restricts the types that can be used in methods, properties and events of a ref class object and does not allow char* or void*. The modified event includes the a text parameter which is filled in in some cases. Currently this is cast into size_t for transmission in the event and must be cast back out into a pointer. A Platform::Array could be used but that adds allocation overhead. OTOH, it works with all languages. In the future there may be a way for a client to choose whether to receive this data and so pay for the allocation.

Neil

[FlashTek]

   No events had been implemented. Updated with all the Scintilla defined events. modifiedEvent should be used for detecting changes to the document text.

And how do I watch the  modifiedEvent?

[Neil Hodgson]

FlashTek:

> And how do I watch the modifiedEvent?

Its in the Schott example code: search for modifiedEvent.

Neil

[FlashTek]

Strange - I guess I've damaged my project because it never triggerd that event. After I redownloaded the source, it works now. But I found some bugs. I think the 'line' value in the modifiedEvent is not commited - at least it is always 0 for me. Then there are tweo are problems which are kinda annoying: when you switch between a app, using the control and another one, it can happen, that you are not able any more to modify the text in it. The second thing is, that sometimes a app using the control crashes, randomly.

It would be nice, if you would answer me as fast, as you used to do;)

Thanks - again.

[Neil Hodgson]

FlashTek:

> But I found some bugs. I think the 'line' value in the modifiedEvent is not commited - at least it is always 0 for me.

That is normal Scintilla behaviour with only the minimal fields set: http://www.scintilla.org/ScintillaDoc.html#SCN_MODIFIED

> Then there are tweo are problems which are kinda annoying: when you switch between a app, using the control and another one, it can happen, that you are not able any more to modify the text in it.

Its possible to lose focus. This used to occur more often before the key down event was marked handled. Clicking on the text or showing the app bar and dismissing it may get focus back onto the control. Another issue is that the control can lose track of the modifier keys if you switch apps or trap into the debugger. For this, press and release each of Ctrl, Alt, and Shift.

> The second thing is, that sometimes a app using the control crashes, randomly.

Yes, this is early code.

Neil

[FlashTek]

Okay, but I guess the autocomplete functions does not work at the moment. At least something strange happens calling it. Instead of showing kind of autcomplete-menu, it simply adds the list contence to the control's text. Another thing I recently found out is, that the keyEvent will never be raised. 

[Neil Hodgson]

FlashTek:

> Okay, but I guess the autocomplete functions does not work at the moment. At least something strange happens calling it. Instead of showing kind of autcomplete-menu, it simply adds the list contence to the control's text.

No secondary windows such as autocompletion, calltips, or context menus have been implemented as these will be very different from the Windows implementation.

> Another thing I recently found out is, that the keyEvent will never be raised.

The key notification was never implemented on Windows as the window can be subclassed instead and I expect something similar can be done for WinRT. keyEvent should be removed.

Neil

[Neil Hodgson]

   Updated for Visual Studio 2012 and Windows 8 RTM. Since the control has methods that take argument types that JavaScript doesn't support it is marked as not supporting WebHost: [Windows::Foundation::Metadata::WebHostHidden]. It may be possible to hide just those methods but that would require more investigation. Also changed some argument names to avoid compiler warnings.

https://bitbucket.org/nyamatongwe/metrosci

   Neil

[Neil Hodgson]

FlashTek:

> are you going to work on this project again? Or do you even have changes whitch are not already published?
> Thanks for you work and your answer because I'm really interested in your MetroSci.

WinRT is too restrictive to be a great platform for most local development applications. There may be some remote development applications where WinRT is successful and you can write a simple text editor, but something like SciTE does not appear to be possible. The OS X sandbox is also limiting but it does, for example, allow running subprocesses which is not possible with WinRT.

WinRT may be extended in the future to be a better match for IDEs but, for now, the desktop will suit most applications better.

Other people may have product ideas that fit within WinRT and they can continue improving MetroSci but, for me, the platform is just too limited.

Neil

[FlashTek]

Could you at least try to make the current version of the control stable enough? Because I'd really like to port an editor to the WinRT platform, and already made great progress. But sadly the current available version of the control is too unstable. And it's to complex to solve this without the knowlegde of the whole structure.

So, I really hope you continue this project and the developement of the control

-FlashTek

[Neil Hodgson]

FlashTek:

> Could you at least try to make the current version of the control stable enough?

Unless WinRT becomes more widely useful, I'm not really motivated to work on it further. There are other areas where effort would be better spent. If a customer wanted to pay for improvements then I'd be interested but even that couldn't occur until next year since I'll be travelling for most of the rest of this year.

Neil