<terminal> is a coming virtual ANSI terminal implementation. It supports all navigational commands and basic formatting:
Can be used in combination with process.spawn() to have something like CMD.EXE
Or to be used as console / log output.
Or whatever.
Sciter supports three types of graphics contexts:
| Type | GPU | Definition | How to get |
|---|---|---|---|
| <canvas> | GPU | W3C specified graphics thing.
Retained (buffered) rasterization. Hardware accelerated. |
let ctx = canvas.getContext("2d")
|
| Paint Graphics | GPU | Sciter specific.
Immediate Mode painting. paintContent method gets called when the engine paints tree of DOM elements. |
element.paintContent = ctx => {...}
|
| Image Graphics | CPU | Sciter specific.
Retained, buffered painting on bitmap image. You will get prepared graphics context (ctx) in your callback methods of Image constructor and optionally in image.update() method. |
image = new Image(100ppx,100ppx, ctx => {...});
// and
image.update(ctx => {...});
|
Paint Graphics is used in cases when you need to add some lightweight drawing to the element without changing DOM.
Consider the task of creating resizable component:
Note those eight handles that are drawn on top the element… In Sciter you don’t need to create additional DOM elements for drawing those, just define paintForeground = function(ctx) {...} method and draw them there. Fast and efficient.
Sciter supports the following drawing methods for DOM elements:
element.paintBackground = func(ctx); – invoked before CSS background drawing and return true; (a.k.a. “done”) from the func discards default CSS background drawing.element.paintContent = func; – invoked before DOM content drawing and return true; (a.k.a. “done”) discards drawing of the content – as if all children have visibility:hidden; set on them.element.paintForeground = func; – invoked before CSS foreground layer drawing and return true; (a.k.a. “done”) discards default CSS foreground drawing.element.paintOutline = func; – invoked before CSS outline drawing and return true; (a.k.a. “done”) discards default CSS outline drawing.Therefore, if you need to draw something on element on top of its content, attach paintForeground painter to the element.
Painting by these functions is done on exactly the same Graphics that is used for drawing DOM element, so it is GPU accelerated and quite lightweight.
Image graphics is always associated with some bitmap – instance of class Graphics.Image.
Painting on the bitmap surface can be done either in image constructor:
image = new Image(100ppx,100ppx, ctx => {...});
Or later, after image creation, in its update method:
image.update(ctx => {...});
Almost always drawing (primitives rasterization) is done on CPU side, and so is not that performant as GPU drawing – use with care.
Note that in Sciter you can bind instance of Graphics.Image with CSS images. Therefore, you can implement dynamic CSS backgrounds:
let imageForCSS = new Graphics.Image(w,h, painter); // create image
document.bindImage("local:someid", imageForCSS); // attach the image to the "url".
And to use that url in CSS for an element:
div.cool {
background: #fff no-repeat;
background-image: url(local:someid); // url-bound image
}
That <div.cool> element will use background-image defined on JS side and if you want to update that image at runtime do:
imageForCSS.update( ctx => { ... cool drawing goes here ... } );
document.$("div.cool").requestPaint(); // ask Sciter to repaint that element
Cool, isn’t it?
Sciter.JS is the mainstream (primary) version of Sciter.
From now and on Sciter name is used as synonym of Sciter.JS.
I’ve updated download page and will gradually refactor all other pages on the site to use Sciter.JS.
Sciter.TIS is supported and will be supported in foreseeable future but its script feature set is frozen. Please consider Sciter.JS if you are starting new project.
I’ve decided to add behavior:virtual-list as a native component (native behavior in Sciter terms).
Browsing lists is so common in UI so it deserves separate native component that works in most optimal way.
The virtual-list implements sliding window viewer – uses fixed number of DOM elements for list items. So no matter how large is recordset it will work as fast as possible and consume minimal and constant RAM and CPU resources.
Virtual-list supports following features out-of-the-box:
event contentrequired that host application needs to implement.createElement()/append()).
Sciter.JS includes default “unisex” theme in day/light variations – first two screenshots. This theme is built in into resources of the engine – available out of the box. The theme is modelled after Bootstrap 4, MacOS, Linux/Mint and so on. The goal is to provide styling that does not look too foreign for all platforms that Sciter supports.
Additionally Sciter.JS SDK will contain Windows 10 “flat” theme (second row) and Material theme.
I believe that this three themes represent all modern trends in UI styling.
And of course all this is customizable according CSS, scripts and your imagination.
One of the goals of Sciter.JS is to support loading of as existing web documents/scripts as universal documents – still web documents but aware of Sciter specifics – documents/applications that can work as in browsers as in Sciter.JS.
While Sciter.JS will use standard JavaScript in ES6 specification (whatever QuickJS++ supports), there are differences in CSS.
In browsers 1px is a “logical pixel” – exactly what is 1dip in Sciter – 1/96th of inch.
But px units are used quite a lot in web documents so it is not realistic to replace px’es for Sciter.
In order to tackle this I am introducing SciterSetOption(...,SCITER_SET_PX_AS_DIP, TRUE/FALSE) settings switch.
Yet, I am adding ppx units – unconditional “physical pixel”, use 1ppx when you will need something to take 1 screen pixels no matter of system zoom factors and SCITER_SET_PX_AS_DIP configuration. Note that dip units are also unconditional – they are always 1/96th of inch.
Therefore, in case of SciterSetOption(NULL,SCITER_SET_PX_AS_DIP, TRUE), it will be 1px === 1dip.
And in case of SciterSetOption(NULL,SCITER_SET_PX_AS_DIP, FALSE), it will be 1px === 1ppx as it is now.
So px units are conditional – their interpretation depends on SCITER_SET_PX_AS_DIP setting of your application.
@supports blocks in CSSI am adding support of @supports blocks in Sciter’s CSS.
The @support feature can be used to tackle CSS differences of documents running in web or Sciter environments.
Consider this universal document, it supports rendering as in browser as in Sciter, just uses different flex notations:
<html>
<head>
<title>Test</title>
<style>
.indicator { display:none; font-weight:bold;}
@supports (display:flex) {
.browser { display:block; }
main {display:flex;}
}
@supports (flow:horizontal) {
.sciter { display:block; }
main {flow:horizontal;}
}
</style>
<script></script>
</head>
<body>
<p>Demo of <code>@supports</code> in CSS.</p>
<p>This document can be loaded either in Sciter or in browser and will show:</p>
<main>
<div>Running in </div>
<div class="indicator browser">browser</div>
<div class="indicator sciter">Sciter</div>
</main>
</body>
</html>
Documentation of <lottie> (behavior:lottie) is here. See LottieFiles for the ideas of what can be achieved. SDK samples are in sdk/samples/animations-lottie/ folder.
I am adding new clip-box property:
clip-box: default | content-box | padding-box | border-box | margin-box | hit-margin-box
As its name stands it changes clipping box of overflow‘ed element.
For example here:
the scrollable list is defined as
@const TOOLBAR_HEIGHT: 64dip;
main {
flow:stack;
size:*;
}
section {
size:*;
overflow:auto;
margin: @TOOLBAR_HEIGHT 0 0 0;
clip-box: margin-box; // rendered outside of principal box
border-spacing:20dip;
flow:horizontal-wrap;
}
toolbar {
height: @TOOLBAR_HEIGHT;
z-index:1;
background-color: rgba(240, 240, 240, 0.55);
backdrop-filter: blur(40dip);
}
CSS backdrop-filter in Sciter:
That glassy box is styled as
.box {
background-color: rgba(240, 250, 255, 0.55);
border-radius: 5dip;
font-size: 20pt;
text-align: center;
line-height: 100%;
backdrop-filter: blur(20dip);
size: max-content;
padding: 20dip 40dip;
box-shadow: 2dip 10dip 24dip 0dip rgba(0,10,20,0.75);
margin:*;
}
With the introduction of Sciter.Lite in v 4.4.0.2 the engine becomes an universal UI solution that covers:
<frame> where applications (HTML/CSS/script+native) are loading.Sciter.Lite is built from the same sources as the Sciter. Both expose the same native and script API.
The major difference between [desktop] Sciter and Sciter.Lite is in how these two use windows.
All desktop OSes have a concept of separate [desktop] windows.
HWND, NSWindow*, GtkWindow*.
view.window(), view.dialog() and view.msgbox() functions.Element.popup() function.void* – pointer that is not interpreted internally as a window handler. Applications that integrate Sciter.Lite are free to use it as a pointer to some internal structure associated with the instance of Sciter engine.
view.window(), view.dialog() are subjects of emulation – either on engine side or on application side. The work on these functions is ongoing.Element.popup() is also a subject of emulation. Work on popups is in progress too.Sciter includes “unisex” default style system (so called master.css) that is modelled after Bootstrap. And Bootstrap theming is quite widespread and familiar to most of users.
But of course each OS/device has its own distinct styling so in order an application to look native on the platform proper styling should be applied. In Sciter UIs styling is a subject of designing proper CSS declarations.
Here, for example, is the basic Material theme from Sciter’s SDK with some animation samples of Sciter.Lite running on pretty average Android device:
In any case, core of the application that uses Sciter UI will be the same on different platforms – only styles need to be tweaked.
Initially Sciter was designed as multiplatform UI layer for C/C++ applications. While now there are a lot of Sciter wrappers for different programming languages, C and C++ are the main integration targets.
Extensibility by and integrability into C/C++ applications is what I mean by “embeddable UI engine”. It is easy to define native function and expose it to script. So instead of adding heavy JITs and WebAssembly mechanisms to the engine Sciter simply offers you to use battle tested C/C++ for functions that require heavy computations. After all C and C++ works on all platforms where term “UI” makes sense.
[desktop] Sciter and Sciter.Lite share the same API (modulo HWND related functions) and so the same native C/C++ code that communicates with the UI will work on all platforms supported by Sciter and Sciter.Lite.
That means you can really design native C/C++ applications that will work on any device that has graphical display. CSS and script will allow to tune UI up for specifics of particular device or PC – your native code may stay exactly the same.
Build RSS channel
Sciter Twitter channel