50 million PCs are running Sciter or HTMLayout code.

December 2, 2014

Filed under: HTMLayout,Philosophy,Sciter — Andrew @ 6:43 pm

pc-crowd

Quite conservative estimation of number of PCs and Mac’s running either Sciter or HTMLayout code is 50 million worldwide so far.

Thanks to Sciter/HTMLayout customers and their great applications.

UPDATE: I’ve been told that at least one of companies from the list has 90 million registered users. So the total number is way above 100 mln computers.

10 years road to Sciter

July 17, 2014

Last year it was a jubilee of my BlockNote editor – it is 10 years old now. Quite a serious age for software product I think.

BlockNote

BlockNote, in particular its HTML WYSIWYG editing engine, was the very first version of H-SMILE core that works now inside the Sciter. H-SMILE core was used in other software products, for example in EverNote. In fact I was one of four developers who implemented excellent idea of Stepan Pachikov (EverNote idea-monger and founder) and created first public versions of EverNote.

In parallel and after that I was designing various UIs and editing components. WordProcessor engine that I’ve created for Top Producer Systems (The move.com company). That WordProcessor still works in their flagship product AFAIK. Current stack of Web technologies still does not provide facilities for page oriented WYSIWYG editing so there is nothing to replace WordProcessor yet. I’ve got quite interesting experience implementing text layout and editing algorithms there. Ideas from there have found their way in Sciter code in one way or another.

At some point I’ve got an impression that C++ is not the best language for UI programming. In particular GC as a memory management mechanism is significantly better suitable for typical UI tasks – many small objects with quite non-trivial ownership graphs. I’ve started looking on Java but having dependency on installed Java VM didn’t look right at the moment. So I’ve created so called j-SMILE JavaVM (based on SuperWaba) that was tailored specifically for UI purposes – designed to be combined into executable of the applications together with bytecodes it is running. J-SMILE demo (buggy but works somehow) and sources of class files are available here.
J-SMILE screenshot.

In J-SMILE I started experimenting with HTML as a UI layout manager and sinking/bubbling event propagation mechanism used in Web browsers. These mechanisms were proven to be highly useful for desktop UI purposes too.

Pretty much at the same time with my J-SMILE development Sun-Microsoft “Java Wars” had begun. And this immediately put the end to my J-SMILE development. I realized that I have no chances on this front and started looking for other options.

Some time later D-language raised in the sky and gave me real hope for the best ever language-behind-UI. GCable, natively compileable so fast and with pretty sufficient functional features. So I’ve started porting J-SMILE to it under the name Harmonia framework.

Harmonia testbed application

Harmonia testbed application

For those who are interested to see Harmonia in action: Harmonia demo, Harmonia sources and class tree.

D is really very cool and convenient language but after some time I’ve decided to stop Harmonia development for the following reasons:

  1. It was time when D-language was changing very frequently. Pretty much each nightly build was changing core grammar. So Harmonia development was similar to shooting a moving target. Far from being normal development process.
  2. Having each and every object manageable (garbage collectible) is far from being optimal. HTML DOM tree is a large set of small objects. All these small objects are flooding manageable heap making GC cycles very CPU intense. That’s not about Harmonia only by the way – I believe Android suffers from this problem too when its UI freezes noticeably.
  3. I’ve got very strong feeling that each part of UI framework shall use its own memory management and ownership principles that are optimal for the role they are playing. HTML DOM tree has very regular structure with clear one parent – many children ownership graph. Life cycle of DOM elements (read “UI elements”) is also quite deterministic. There is absolutely no need for GC if to speak about HTML/CSS.
  4. But code-behind-UI – code that does UI automation in “on-click-here-push-item-there-and-collapse-panel-over-there” fashion has to be manageable. GC there is the must – ownership graph is unknown upfront and frequently contains loops.

So I reverted back to C++ and created pure DOM and rendering implementation – HTMLayout. And started looking on embeddable languages that can be used with it as “language behind UI”. Here are languages that I considered for that purpose:

  1. Ruby and Python – were rejected almost immediately. HTML friendly language shall have syntax that is not dependent on tabs, line feeds, etc. For quite many reasons. And yet Python was using C/C++ heap for object allocations, UI objects lifecycle require compacting GC – objects created and destroyed frequently.
  2. Lua – pretty much for the same syntax reasons. But it was a good candidate. I even started creating JS syntax alike compiling front-end for its VM. But discovered in process that Lua’s object/class model is too rudimentary I would say.
  3. JavaScript – as a natural choice was always there. But its prototyping schema, “hackish” way of doing classes there and that famous “automatic semicolon injection” problem were stopping me each time I was trying to consider it. Only ECMAScript version 6 has started to appear solid enough. But that’s just recently.

Needless to say that my investigation ended up in creation of first C-SMILE and then TIScipt. TIScript is almost JavaScript (JavaScript++ if you wish) but with modular system (namespaces) and classes. It also got built-in persistence. And it inherits base syntax and runtime library from JavaScript.

HTMLayout combined with TIScript became Sciter as you see it now.

Oh, and in parallel with all this I was working as UI Architect and team lead at Top Producer Systems (move.com company) on various desktop UI, Web and mobile applications projects. And yet participated in HTML5 and CSS3 specification development as invited expert in W3C HTML Working Group.

“Theory” of URLs for developers

July 9, 2014

Filed under: HTML and CSS,HTMLayout,Sciter,Web Application Techologies — Andrew @ 11:25 am

We are using URLs these days quite a lot, but not all of us understand what they actually are.

By this post I will try to explain their structure and how Sciter/HTMLayout deals with them.
Please note that this is sort of informal explanation and I am using term “URL” here while “URI” is more correct name for that entity strictly speaking.

URLs are made from these 5 major parts:

<scheme name> : [//] <resource identification > [ ? <query> ] [ # <fragment> ]

Where:

  • scheme name – is in principle any name token – name of the URL scheme. Some of names are well known: “file:”, “http:”, etc.
  • // part – if present, means that the following “resource identification” part uses hierarchical naming convention, with ‘/’ character as a delimiter.
  • resource identification – is either ‘/’ separated path name if ‘//’ is provided. Or it is some “flat” name.
  • query part is in principle meaningful only for dynamic client/server scenarios. It is an instruction to the server to provide that resources with those parameters.
  • fragment – is a name or ID of some sort that identifies some location or part inside the resource.

Consider that you have the same HTML test-file.html available from these three locations:

  1. file:///c:/test-folder/test-file.htm
  2. http://example.com/test-folder/test-file.htm
  3. res:test-file.htm

Let’s imagine that the document contains image with relative path:

  <html>
  <img src="image.png">
  </html>

Sciter, while loading the document, will resolve relative path name “image.png” to these:

  1. file:///c:/test-folder/image.png – as base URL is hierarchical one.
  2. http://example.com/test-folder/image.png – ditto.
  3. res:image.png – but here only resource schema is inherited as base URL uses “flat” naming convention.

In principle your Sciter application can use your own URL schema. You just need to decide will it be hierarchical or flat.

For example if you will call SciterLoadHtml(html, "app://module/main.htm"); then all relative links inside that document
will be resolved against app://module/ base name. So in your SCN_LOAD_DATA handler you will get: “app://module/images/img1.png”, “app://module/styles.css” and so on.

But if you plan to put all your files into resource section of your executable then you should use “flat” schema, like “res:”.

And the last note: if you use hierarchical URLs in SciterLoadHtml and SciterLoadFile calls then these urls must be absolute ones otherwise Sciter will not be able to resolve them reliably.

HTMLayout, GoLang wrapper by EricRoy

January 27, 2013

Filed under: HTMLayout — Andrew @ 11:48 am

GitHub: github.com/ericroy/go-htmlayout

Project status

Go-htmlayout is written for Go1. Most of the HTMLayout API has been wrapped (especially dom element related stuff), but there is still more of the HTMLayout API that I haven’t tackled yet. Tests are also incomplete at this point. In short, this wrapper is probably not ready for serious production use.

Sciter 2.0.0.12

February 27, 2012

Filed under: HTML and CSS,HTMLayout,Sciter — Andrew @ 12:10 pm

Just published Sciter 2.0.0.12 SDK that is available at terrainformatica.com/sciter/sciter2-tech-preview.zip.

Sciter 2.0.0.12 screenshot

What’s new in the build:

  • Demos:
    • bin/layered.exe (sdk/demos/layered) demonstrates use of WS_EX_LAYERED windows. That is about windows of non-rectangular shapes. W7 has better support of such windows so even animations are feasible on such windows. Just run the demo to see.
  • CSS features:
    • New layout method: flow:row(tag1,tag2) – that is a variation of flow:grid | "template" that allows to define grid-alike layouts when number of rows is unknown upfront. For example list of info items on the screen shot above is defined as:
    • <dl #info>
        <header>Sciter</header>
           <dt>version:</dt>        <dd #version>...</dd>
        <header>System</header>
           <dt>OS type:</dt>        <dd #os-type>...</dd>
           <dt>OS version:</dt>     <dd #os-version>...</dd>
      ... </dl>

      and styled simply as flow:row(dt,dl) to replace <dt>/<dd>s in grid rows.

    • The design of font-rendering-mode property is finalized and now it looks as this:
    • font-rendering-mode: snap-pixel | sub-pixel;
      

      Default value is sub-pixel and it is an inheritable property. For large fonts and fonts in elements under 2D transforms look better when rendered in sub-pixel mode. Normal and small UI fonts are better readable in snap-pixel mode.

  • Core changes:
    • flow:text layout module ( used to render text block containers like <p> ) was rewritten from a scratch. Previously I was using IDWriteTextLayout for that but was forced to get rid of it. IDWriteTextLayout has no means to support things like floats (require "jagged" text boundaries) and text-align:justify.
    • So now the engine passes all floats related tests from W3C CSS test suite.
  • List of intrinsic behaviors supported so far:
    • buttons:
      • behaviror:button  attached to <input type=button> and <button>;
      • behavior:clickable – focus-less buttons like toolbar buttons, etc.
      • behaviror:check  attached to <input type=checkbox> and <button type=checkbox>;
      • behavior:radio attached to <input type=radio> and <button type=radio>;
      • behavior:switch – flawor of behavior radio but activation happens on MOUSE_DOWN rather than on MOUSE_UP, used for tabs alike containers.
      • behavior:hyperlink – attached to all elements having href DOM attribute, including <a>.
    • date and time:
      • behavior:calendar – shows month/year/century calendar. Attached to <input type=calendar> and <widget type=calendar>.
      • behavior:date – date input with popup calendar, <input type=date>
      • behavior:time – time input <input type=time>.
    • edits:
      • behavior:edit – text input, <input type=text>;
      • behavior:password – password input, <input type=password>;
      • behavior:textarea – multiline input, <texarea>;
      • behavior:number – numbers (integer or decimal) input element, <input type=number>;
      • behavior:integer – integer number input element, <input type=integer>;
      • behavior:decimal – decimal number input element, <input type=decimal>;
      • behavior:masked-edit – masked input element, <input type="masked" mask="...">
      • behavior:slider
    • selects:
      • behavior:select – single select list, <select size=2,3,...>, <select type=select>;
      • behavior:select-multiple – multi-select list, <select size=2,3,... multiple>, <select type=select multiple>;
      • behavior:select-checkmarks – multi-select list, <select size=2,3,... multiple=checkmarks>, <select type=select multiple=checkmarks>;
      • behavior:tree – single select tree, <select type=tree>. Select with <option>s containing other <option>s;
      • behavior:tree-checkmarks – multi-select tree, <select type=tree multiple=checkmarks>;
    • menus:
      • behavior:menu-bar – menu bar;
      • behavior:menu – context/popup menu;
      • behavior:popup-menu – button with popup menu <button type="menu" menu="css selector">;
      • behavior:popup-selector – button with popup menu list, <button type="selector" menu="css selector"> ;
    • indicators:
      • behavior: progress – progress bar, <progress>, <meter> elements.
    • gestures recognition:
      • behavior:swipe – recognizes swipe gestures and generates BEHAVIOR_EVENTS::SWIPE / Event.SWIPE events.
    • frame/form:
      • behavior:frame – the behavior behind <frame>. Used for loading other documents inside elements thus to support DOM elements with "foreign" DOM sub-trees;
      • behavior:history – navigation history in system of <frame>s;
      • behavior:frame-set – that is just a handler of containers with splitters, by default attached to <frameset cols=...> and <frameset rows=...>;
      • behavior:form – the behavior behind the <form>. Form here is a "submitable/resetable" collection of input items. Note: behavior:form can be  assigned to any container. Value of the form is collection(map) of name/value pairs – names and values of input elements.

Sciter v.2 technology preview

March 13, 2011

Filed under: HTMLayout,Sciter — Andrew @ 6:27 pm

You can download Sciter v.2 SDK preview from here http://terrainformatica.com/sciter/sciter2-tech-preview.zip

/bin/sciter.exe in the archive is a demo application to play with. Its sources are in /demos/sciter/ folder. After start you should see something like this:
article2

Note: this version works only on Vista/W7 as it uses Direct2D/Write graphics backend. Aero and W7 Basic DWMs only for a while.

New features in this version:

  • Direct2D/Write graphics backend – pretty fast on some operations. Expect animations to work faster.
  • Support of CSS 2D Transforms Module Level 3: http://www.w3.org/TR/css3-2d-transforms/ – everything except matrix() function. Will add it later if needed.
  • Internal DOM representation was redesigned to avoid need of that ugly <text> element injected by the parser. DOM is more standard now and in principle H-SMILE core can pass ACID2 test (if I will have a time to tweak it for that). DOM is represented by Element and Node entities. Node wraps text and comment nodes in HTML.
  • TIScript got support of "tagged n-tuples" data type. http://en.wikipedia.org/wiki/N-tuple with optional tag (a.k.a. name).

Some observations about Direct2D/Write:

Font rendering

Font rendering as I’ve mentioned already is significantly different in GDI and DW. Small an basic UI fonts looks better in GDI mode. Larger fonts are better in DW. For white text on black background with small and medium font sizes the GDI rendering is the only option I think. Just load /samples/basics/test-font-rendering.htm into the Sciter and you will see what I mean.

I was forced to introduce font-rendering-mode proprietary property for applications to be able to tweak this aspect.

Direct2D performance

While it is good on medium/high-end graphic cards it may behave very badly on low-end graphic cards or when there are applications on desktop that do graphic intense operations. Notably running Adobe Flash may affect speed of rendereing of other applications. That is not only about Sciter per se but other applications. Windows Live application suite is an example of graphics sensitive application. You may notice frame drops in animations inside Windows Live Mail or Messenger.

It appears as Direct2D/Write is a foundation for future high-DPI displays. As for now that font-rendering-mode workaround is the must I believe.

Next Page »