Sciter-XGL

December 16, 2014

Filed under: Sciter — Andrew @ 10:00 pm

Thinking about making so called sciter-xgl – smaller version of the Sciter but with OpenGL backend and with slightly reduced feature set. Targeted on games and the like use cases. And with broader platform support including all mobiles I can put my hands on.

Thinking…

Linux version is coming

December 10, 2014

Filed under: Sciter — Andrew @ 3:21 pm

Actually it is not about Linux only but any POSIX compatible system that is capable to run GTK 3.0 and above.

Sciter on Ubuntu Linux

Sciter on Ubuntu Linux

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.

display:none is considered harmful

October 28, 2014

Filed under: HTML and CSS,Sciter,Script,Web Application Techologies — Andrew @ 7:51 pm

Quite often in HTML/CSS based UIs we need to hide/show some elements in runtime.

Probably the most widespread (and the worst) solution is to set display:none CSS property programmatically.

That sounds quite easy at the first glance but solves only half of the problem – it hides – removes the element from rendering tree. But what you would do when you need to show element that was previously hidden that way? Setting it to display:block is very wrong. Far not all elements have display:block model by default in HTML.  <img>, <input>, <select>, <textarea>, etc are display:inline-block. <table> and all its children have special display:table**** values. Setting them to display:block will lead you to quite surprising results.

Therefore in order to use display:none in runtime you will need to know original display value of the element. Not quite convenient and maintainable. Imagine that your web designer (probably sitting on other continent) decided to replace some elements horizontally by declaring display: table-cell on them. You will get problems hiding/showing such elements by switching display: none <-> block.

To overcome such a problem jQuery for example implements its hide() method by storing existing display value to special property named "olddisplay". And restores the display from that property when you need to show the element. That approach is far from ideal either for obvious reasons.

Better solution

Better solution is to use attribute "hidden". So instead of setting element.style.display CSS property you will need to add attribute "hidden" to the element when you need to hide it and remove that attribute when you will want to show the element. In order this to work you will need to add single and simple rule to your stylesheet:

[hidden] { display:none !important; }

If some elements need to be hidden by default you will use hidden attribute in your markup, for example as:

<button id="ok-button" hidden>OK</button>

In Sciter you can define some virtual property, e.g. "shown", to all DOM elements (in some common "utilities" module):

/* CSS must have [hidden] { display:none } rule in order this to work */
property Element.shown(v) 
{
  get return this.style#display != "none";
  set this.attributes["hidden"] = v ? undefined : true;
}

and use it as

var someEl = ...

someEl.shown = true; // to show
someEl.shown = false; // to hide

The solution is not free from obvious drawbacks though:

  1. you need that special [hidden] { display:none; } rule to be present in your CSS and
  2. In all cases when you need to hide/show the element you should do it either through that special "shown" property or explicitly by removing "hidden" attribute from the element.

visibility:none

Since Sciter version 3.1.0.15 you can use visibility:none; in CSS to exclude the element from rendering. Exactly in the same way as display:none;. It has exactly the same effect.

As the visibility property is orthogonal to the dsiplay you can safely assign "none" and "visible" property to it without affecting display model of the element.

Therefore, the visibility property in Sciter can accept following values:

  • none – the element is excluded from rendering tree in the same way as display:none, that is Sciter specific;
  • hidden – the element is in rendering tree, takes space but not rendered;
  • collapse – the element is in rendering tree, takes space but its height or width is collapsed to zero. E.g. in flow:horizontal container visibility:collapse child will take space vertically but rendering width will be set to zero. In Sciter this will work for any elements but in standard CSS only for table rows for some unknown to me reason.
  • visible – default value, element is rendered normally.

And here is modified version of the shown scripting property defined above:

property Element.shown(v) 
{
  get return this.isVisible;
  set this.style#visibility = v ? "visible" : "none";
} 

Context menus in Sciter

September 27, 2014

Filed under: How-to,HTML and CSS,Sciter — Andrew @ 1:57 pm

Context menu is a standard UI feature and in order to support them Sciter has following mechanisms on board:

  1. custom CSS property named context-menu. It defines location of DOM element ( usually it is one of <menu class=context> ) that will appear on context menu activation.
  2. Menu behaviors and their DOM events associated with menus.
  3. Context menu activation and initialization mechanism.

(more…)

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.

Next Page »