Embeddability is the corner stone principle of Sciter Engine design.
Conventional browser engines in desktop applications.
HTML/CSS rendering engines used by conventional browsers are designed to provide safe browsing experience to the users. While this goal shall be honored by itself, it prevents usage of these engines in desktop applications – too many typical UI operations and functions are simply disabled. For example, browsers have very limited access to system clipboard, they cannot create rich dialog windows other than standard
confirm() boxes and so on.
For the same reason all modern HTML/CSS/script engines run UI in boxed environments – each tab or window runs in a separate OS process. That physically provides more or less safe environment but at the same time is limiting UI functionality quite a lot. Yet to be mentioned memory and resource consumption associated with such isolation methods.
Right tool for the UI
If you plan to create desktop application with declarative HTML/CSS frontend you should choose right tool for that – the engine that is specifically designed to be used in desktop applications.
Sciter Engine can be integrated into your application in one of three ways:
Standalone desktop window managed by Sciter
You can ask Sciter to create separate desktop window and load there markup with styles of your choice. In this case HTML, CSS and script can even configure so called “window chrome” – you can define custom look and feel of windows – captions, buttons and the frame itself. Below are examples of various types of windows styling in Sciter:
In this case Sciter will control just this part of your main window. Consider it as a component with rich set of configuration and UI options.
Mixing in Sciter functionality into existing windows and frameworks
Mix-in mode allows to add Sciter functionality to GUI frameworks that use their own abstractions or window wrappers. This way Sciter is embedded into Delphi UI framework and used in MFC and WinForms.NET projects.
In mix-in mode Sciter is delegated to provide rendering of window content and handle UI events: mouse, keyboard, etc.
Your application and the Sciter
As soon as you have created Sciter window you can do the following with it:
To load markup, styles and scripts into the window
HTML/CSS/scripts can be loaded into Sciter from different sources:
- From Internet – if part of your application UI resides on your web site. Sciter also can issue AJAX/JSON requests if your application requires connectivity with remote data sources.
- From local hardrive.
- From resource section of your application.
- From resource bundle linked into code of your application.
- From code of your application if you need to synthesize markup dynamically.
- From any other location of your choice because…
Application has full control on what is loaded by the Sciter
Your application may provide Sciter callback function that will receive absolutely ALL requests for loading resources into Sciter window.
By handling load resource requests your application can:
- Provide data for particular resource.
- Allow Sciter to use its default loader. Sciter knows how to load stuff from local file system and the Web over http(s).
- Or discard loading of the resource completely.
If you will allow Sciter to use it default loader then you will get “data loaded” notifications with the data loaded. You can this data for implementing custom caching policies for example.
Application has full control of UI and DOM events dispatched/generated by the Sciter.
Application can intercept any window message as before it will be handled by the engine as after it.
Application may install so called “DOM event handler” on the window or particular DOM element. In this case it will receive absolutely all DOM events like button clicks, selection and edit box changes. Script can also generate events to notify the application about particular UI events.
Application can expose native functions to the script.
Usually UI needs some information from native side. Application may define set of native functions that will provide data to the script. Script will use this data to render the UI. Native code may play a role of model and controller in MVC terms.
Application can define new native types of [input] DOM elements.
If needed application may provide native DOM elements by providing implementation of so called native behaviors. Essentially native behavior is a function similar to WindowProc in Windows but for windowless DOM elements – it can control all aspects of DOM element life cycle: creation/destruction, event handling, drawing and so on.
Application can re-define look-and-feel of absolutely all input elements and widgets.
Look-and-feel of absolutely all input/output elements provided by the engine is defined in so called master.css – single CSS file that can be redefined by the application in part on in full. Therefore application may use its own unique themes of input elements. If that is required of course.
Further reading: Sciter UI, application architecture