Merge request for added QtQuick/QML support for Scintilla and SciteQt implementation

116 views
Skip to first unread message

Michael Neuroth

unread,
Oct 28, 2020, 5:58:37 PM10/28/20
to scite-interest
Hi,

as a programmer I'm using the great Scintilla Editor Control since more than 15 years (via the Qt wrapper QScintilla) in my editor VisiScript and via other applications like Notepad++ and wxWidgets.

The Qt support of Scintilla is very good for desktop platforms like Windows, MacOS and Linux but for the modern mobile platforms like Android and IOS the user interaction is not optimal. The reason is that the Qt Widget platform is not developed/optimized with touch devices in mind. For the modern multitouch user interfaces the QtQuick/QML platform of Qt is developed. Unfortunately to the best of my knowledge there exists no QtQuick/QML support for the Scintilla control.

Because I would like to have a good (cross platform) programmer editor which runs also on my android devices, I started to play around a little bit to port the Scintilla control to the QtQuick/QML platform. Within a few weeks I managed to modify the existing Qt support of Scintilla so that the Scintilla control could be used as reasonable QtQuick/QML control. After that fast success I thought it would be possible to port the SciTE editor to the QtQuick/QML platform. This task took a little bit longer but now I think the project has reached a quite usable status.

So I would like to invite you to test the QtQuick/QML port of SciTE named SciteQt. The project homepage with the source code and binary releases for some platforms can be found on github:


I know that the "resource overhead" introduced by the Qt framework is not in the spirit of SciTE, which should be small and fast, but on the other side Qt brings a great cross platform support: you write the application once and it can run (nearly) everywhere ;-).
Scite runs now even in a modern web browser via webassembly, try this link SciteQt Demo in a web browser, but please be aware that this is just a demonstration of what might be possible with webassembly!

If you find the project usefull you might think about integrating the SciteQt source code into your Scintilla/SciTE source code repository? Or at least integrate some small patches for Scintilla and SciTE and the modifications for the Qt support of Scintilla so that the synchronization between Scintilla/SciTE and SciteQt would be more easily manageable?

I'm looking forward for your feedback about the SciteQt project.

  Michael

Neil Hodgson

unread,
Oct 28, 2020, 6:57:21 PM10/28/20
to scite-interest
   Hi Michael,

Because I would like to have a good (cross platform) programmer editor which runs also on my android devices, I started to play around a little bit to port the Scintilla control to the QtQuick/QML platform. Within a few weeks I managed to modify the existing Qt support of Scintilla so that the Scintilla control could be used as reasonable QtQuick/QML control.

   QtQuick/QML support may be worth adding to the Scintilla project. I don’t have a good feel for the relationship between QtQuick and lower level Qt.

After that fast success I thought it would be possible to port the SciTE editor to the QtQuick/QML platform. This task took a little bit longer but now I think the project has reached a quite usable status.

   That is very impressive.

Scite runs now even in a modern web browser via webassembly, try this link SciteQt Demo in a web browser, but please be aware that this is just a demonstration of what might be possible with webassembly!

   Wow!

If you find the project usefull you might think about integrating the SciteQt source code into your Scintilla/SciTE source code repository? Or at least integrate some small patches for Scintilla and SciTE and the modifications for the Qt support of Scintilla so that the synchronization between Scintilla/SciTE and SciteQt would be more easily manageable?

   Currently I am extremely stretched and have to avoid working on non-core areas of Scintilla/SciTE. Scintilla 5.0 is my priority.

   If I ever have sufficient time, its more likely I would look at Scintilla for QtQuick than any additional SciTE ports. An additional platform for SciTE that covers Android and WebAssembly as well as the desktop OSs will expand the possibilities but also the support area.

   Neil

Michael Neuroth

unread,
Oct 29, 2020, 4:45:58 PM10/29/20
to scite-interest
Hi Neil,

I absolutely understand that your resources are limited and you want to concentrate on your primary Scintilla and SciTE targets. I have no problems to continue to develop the SciteQt project with the existing github project page. I agree with you that the SciteQt project does not need to be integrated into your SciTE source code repository, I just wanted to ask you and the SciTE community if you are interested in a code merge. 

But I also think, that (in some future time) the integration of the QtQuick support for the Scintilla control would make sense. Is there a maintainer for the current Qt support of Scintilla with which I could talk to and discuss the different options on the way to integrate the QtQuick support?

In the meantime it would be very nice if it would be possible to integrate some really small patches/modifications into your Scintilla and Scite source code, to make the synchronisation effort between Scintilla/SciTE and SciteQt much easier.

The following files from your original Scintilla/SciTE source code (version 4.4.5) are modified for the SciteQt project:

Preferred patches:
- scintilla\include\Platfrom.h     // 7 lines added: Added a define for the new platform: PLAT_QT_QML, typedef for PainterID, new overload for method init() in Surface class
- scintilla\src\Editor.h           // 1 line modified, 4 lines added: Patches for using the new overloaded Init() method
- scite\src\GUI.h                  // 1 line: additional define checks to support more target platforms
- scite\src\SciTEProps.cxx         // 1 line: additional define check to support more target platforms

Optional patches (needed for support to show the full path of the file as a tooltip over the tabbutton of the edit page):
- scite\gtk\SciTEGTK.cxx           // 2 lines modified
- scite\win32\scitewin.h           // 1 line modified
- scite\win32\SciTEWinBar.cxx      // 1 line modified
- scite\src\SciTEBase.h            // 2 lines modified    & marked Save() method as virtual, needed for Android Storrage Access Famework support
- scite\src\SciTEBuffers.cxx       // 2 lines added, 1 modified

The QtQuick support is mainly handled in this files with extensive patches inside the files. It might be an option to divide the QtWidget and QtQuick support in two diffent code lines, despite they have much in common. Currently you can choose via the define PLAT_QT_QML if you use the (existing) QtWidgets or the (new) QtQuick implementation.
- scintilla\qt\ScintillaEditBase\PlatQt.h              
- scintilla\qt\ScintillaEditBase\PlatQt.cxx            
- scintilla\qt\ScintillaEditBase\ScintillaQt.h         
- scintilla\qt\ScintillaEditBase\ScintillaQt.cpp       
- scintilla\qt\ScintillaEditBase\ScintillaEditBase.h   
- scintilla\qt\ScintillaEditBase\ScintillaEditBase.cpp 

It would be a really great support for the SciteQt project if you could find some time to integrate the attached patches (against the current stable release 4.4.5) into the mainstream Scite/SciTE source code repository, at least the 4 files in the preferred patches section. I could also make a merge request on a repository branch if you prefer this method?

  Michael
SciTEGTK.cxx.patch
SciTEBase.h.patch
SciTEBuffers.cxx.patch
Platform.h.patch
SciTEProps.cxx.patch
Editor.h.patch
SciTEWinBar.cxx.patch
GUI.h.patch
SciTEWin.h.patch

Neil Hodgson

unread,
Jul 16, 2021, 10:51:00 PM7/16/21
to scite-interest
Michael Neuroth:

> - scintilla\include\Platfrom.h // 7 lines added: Added a define for the new platform: PLAT_QT_QML,

The PLAT_QT_QML definition is fine. Committed.

> typedef for PainterID, new overload for method init() in Surface class

Are these really needed for the SurfaceID-free constructor which is used for measuring text? Can’t the value be retrieved from the WindowID that is passed into Init? Perhaps a global WindowID->QQuickPaintedItem map.

> - scite\src\SciTEProps.cxx // 1 line: additional define check to support more target platforms

OK, committed.

> Optional patches (needed for support to show the full path of the file as a tooltip over the tabbutton of the edit page):

> - scite\src\GUI.h // 1 line: additional define checks to support more target platforms

5 cases so probably better to check the other way round for just _WIN32.

For TabInsert, the full path can be found from the index with buffers.buffers[index].file.

> - scite\src\SciTEBase.h // 2 lines modified & marked Save() method as virtual, needed for Android

OK, committed.

Neil
Reply all
Reply to author
Forward
0 new messages