Profile: c-smile - Hacker Neue

c-smile

Joined May 20, 2016 2,792 karma

Author of

- Sciter Engine - https://sciter.com

- Sciter Notes - https://notes.sciter.com

- HTML Notepad - https://html-notepad.com

MS in Applied Physics and Mathematics.

GH: https://github.com/c-smile/

SO: http://stackoverflow.com/users/421163/c-smile

CP: http://www.codeproject.com/Members/c-smile

Participated in HTML5 specification development at W3C HTML5 WG as an invited expert.

c-smile Dec 24, 2025
Lua syntax is pretty good for DSL (domain specific language) cases / configuration definitions.
For example Premake[1] uses Lua as it is - without custom syntax parser but with set of domain specific functions.
This is pure Lua:
```
   workspace "MyWorkspace"
      configurations { "Debug", "Release" }
   
   project "MyProject"
      kind "ConsoleApp"
      language "C++"
      files { "**.h", "**.cpp" }
   
   filter { "configurations:Debug" }
      defines { "DEBUG" }
      symbols "On"
   
   filter { "configurations:Release" }
      defines { "NDEBUG" }
      optimize "On"
```
In that sense Premake looks significantly better than CMake with its esoteric constructs. Having regular and robust PL to implement those 10% of configuration cases that cannot be defined with "standard" declarations is the way to go, IMO.
[1] https://premake.github.io/docs/What-Is-Premake
c-smile Oct 11, 2025

<output type="currency">123456.00</output> formats output using user's settings: https://www.elevenforum.com/attachments/currency_format_cont...
If you want specific country format then you may use lang:
<output type="currency" lang="de-DE">123456.00</output>
Currency conversion is not a subject of a browser.
c-smile Oct 11, 2025

"better" in what sense? If in hypothetical semantic meaning then another old zombie <var> is better in that sense, isn't it?
c-smile Oct 11, 2025

Not sure I understand why do you need exchange rates with it.
<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

c-smile Oct 11, 2025

Also, if to allow form.value to accept JSON-ish objects it will be possible to set form values in single shot:

   form.value = { transAmount: 12345n, transDate: new Date() };

where form is

   <form>
     ... <output type="currency" name="transAmount" />
     ... <output type="date-local" name="transDate" />
   </form>

c-smile Oct 11, 2025

Problem with <output> is that it is half-baked making its usage almost useless.

It would be significantly more practical for the output to have "type" attribute in the same way as in the input.

I did experiment with oputput|type in my Sciter and added these:

   type="text" - default value, no formating
   type="number" - formats content as a number using users locale settings,
   type="currency" - formats content as a currency using users locale settings,
   type="date"  - as a date, no TZ conversion, 
   type="date-local" - as a date in users format, UTC datetime to local,
   type="time" - as a time
   type="time-local" - as a local time, value treated as UTC datetime.

This way server can provide data without need to know users locale.

c-smile Oct 5, 2025

I used to have NEC MobilePro 900 like here: https://live.staticflickr.com/213/481422006_92cdaeb6ee_b.jpg
I miss that form factor really.
And BTW, I regret that WindowsCE is not the thing anymore. IMO it has the best development infrastructure out there backed with MSVC IDE.
I classify OSes into two major groups: "writer OS" (all desktop OSes primarily) and "reader OS" (all mobiles). But there is a void in between for palmtop form factor devices.
Sigh, probably its only me who needs this ...

c-smile Aug 18, 2025

Well, Highlight API ( https://developer.mozilla.org/en-US/docs/Web/API/Highlight ) should just work inside <textarea> too.

At least it works in my Sciter like this:

    <style>
      textarea::mark(myHighlight) {
        background-color: yellow;
        color: red;
      }
    </style>
    <body>
       <textarea>Lorem ipsum dolor sit amet</textarea>
    </body>
    <script>

      // Select a range of text to highlight
      const range = document.createRange();
      const textNode = document.querySelector('textarea').firstChild; 

      range.setStart(textNode, 6); // Start at the 6th character
      range.setEnd(textNode, 11); // End at the 11th character

      // Highlight the range
      range.highlight("myHighlight")

    </script>

Ask your browser vendor to enable highlight API in <textarea> too :) so such tricks will not be required.

c-smile Aug 6, 2025
DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general.
Their API is probably the problem. Not modular so makes the mess.
Options to modularize them:
DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:
```
   element.tagName
   ... and the rest of DOM-as-a-tree methods ...
   element.textarea // <textarea> specific interface of its behavior
   element.textarea.select(startEnd) // interface method
   element.textarea.selectionStart // interface prop
   element.textarea.selectionEnd // interface prop
   element.textarea.rows // interface prop
   element.textarea.columns // interface prop
   ...
```
CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace:
```
   section {
     color: red;
     // ... and other basic CSS 2.1 props

     display: grid(
       rows: ...;
       columns: ...;
       align-items: center;
       justify-items: start
     );
   }
```
So different layouts ( like display:flex(), display:waterfall() ) may have their own rows, columns, etc.
As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.
c-smile Aug 3, 2025
From the very beginning in Sciter an Image can be constructed in two ways at runtime ( other than just getting loaded image reference):
1. By painting on it using Canvas/Graphics API:
```
    new Graphics.Image(width, height, painter(graphics) [,initColor]);  
```
Where _painter_ is a function used for paining on the image surface using Canvas/Graphics reference.
2. By making snapshot of the existing DOM element:
```
    new Graphics.Image(width, height, element [,initColor])
```
Such images can be used in DOM, rendered by other Canvas/Graphics as also in WebGL as textures.
See: https://docs.sciter.com/docs/Graphics/Image#constructor
c-smile May 27, 2025
Consider <textarea> that has resizing handle on the corner (try to reply to this message to see it alive). And now try to imagine how would you render those diagonal lines in HTML/CSS ?
While in Sciter, that has such immediate mode rendering form the very beginning, you can simply draw them as:
```
   resizableElement.paintForeground = function(gfx) { // draw on top of background & content

      let box = this.getBoundingClientRect();
      gfx.moveTo(...); gfx.lineTo(...);
      gfx.moveTo(...); gfx.lineTo(...);
      ...
   }
```
Easy, right? And does not need to modify DOM and place artificial positioned elements.
c-smile May 4, 2025

> "Includes" functionality is considered to be server-side
Exactly! Include makes perfect sense on server-side.
But client-side include means that the client should be able to modify original DOM at unknown moment of time. Options are
1. at HTML parse time (before even DOM is generated). This requires synchronous request to server for the inclusion. Not desirable.
2. after DOM creation: <include src=""> (or whatever) needs to appear in the DOM, chunk loaded asynchronously and then the <include> DOM element(sic!) needs to be replaced(or how?) by external fragment. This disables any existing DOM structure validation mechanism.
Having said that...
I've implemented <include> in my Sciter engine using strategy #1. It works there as HTML in Sciter usually comes from local app resources / file system where price of issuing additional "get chunk" request is negligible.
See: https://docs.sciter.com/docs/HTML/html-include
c-smile Mar 15, 2025

yEd, for those of us who knows word "Visio"
https://www.yworks.com/products/yed
c-smile Mar 14, 2025
Interesting timing...
I've just made something similar but with JS: C modules in JS.
```
    import * as CModule from "./module.c";
```
C module gets compiled to native code on load. I think that clear separation of execution models is a good thing.
https://sciter.com/c-modules-in-sciter/
https://sciter.com/here-we-go/
c-smile Mar 4, 2025

> anti-virus companies decided to use your platform?
One of the reasons: AV application should look modern to give an impression that the app is adequate to modern threats. So while app backend is relatively stable, its UI shall be easily tweakable. CSS/HTML is good for that.
Check this: https://sciter.com/wp-content/uploads/2018/06/n360.png
c-smile Mar 4, 2025
Slightly orthogonal...
In my Sciter, that uses QuickJS (no JIT), instead of JIT I've added C compiler. That means we can add not just JS modules but C modules too:
```
   import * as cmod from "./cmodule.c"
```
Such cmodule will be compiled and executed on the fly into native code. Idea is simple each language is good for specific tasks. JS is flexible and C is performant - just use right tool that is most optimal for a task.
c-modules play two major roles: FFI and number crunching code execution.
Sciter uses TCC compiler and runtime.
In total size of QuickJS + TCC binary bundle 500k + 220k = 720k.
For the comparison: V8 is of 40mb size.
https://sciter.com/c-modules-in-sciter/ https://sciter.com/here-we-go/
c-smile Jan 9, 2025
NSUserDefaults is a key-value storage. Same as localStorage in browsers/js.
On other side persistence in QuickJS is more than that. Essentially it is a NoSQL DB integrated into the language and its runtime. For example you can write
```
   let uname = root.users[2].firstName; 
```
to access the data using pure language constructs. While with NSUserDefaults you will need to call DB's facade methods like objectForKey("some") and so on.
And also, in QuickJS, Storage is not reading whole DB in memory but fetches/unloads data on demand transparently for the user. You can think about content of DB as about genuine language data structure with root at storage.root
c-smile Jan 9, 2025
= Value Database
I've added this feature to QuickJS [1] and it works quite well in Sciter as persistent Storage [2] mechanism, used in Sciter.Notes [3] for example.
```
     let storage = Storage.open(filename);
     let persistentData = storage.root;
     if( !persistentData ) storage.root = persistentData = {... initial storage structure ...};
```
Everything written to persistentData will be persistent between runs.
= Semi-Dynamic Language
De-facto we already use similar approach quite a while. In form of GPU shaders or WebAssembly. The solution is not in making script JIT friendly (that is against its nature) but with an option to use native/compiled/loadable modules written in languages that were designed to be compileable from the beginning.
My Sciter, as an embeddable engine, is an example of such environment. Native host application exposes native functions/classes to HTML/CSS/JS engine that implements UI layer of the application. UI is dynamic (fluid,styleable,etc.) by nature while application backend (a.k.a. business logic layer) is more static and linear by nature.
[1] https://gitlab.com/c-smile/quickjspp
[2] https://docs.sciter.com/docs/Storage/introduction
[3] https://notes.sciter.com/
c-smile Dec 20, 2024

Correct CSS grid layout calculation is about solving system of equations and constraints. In simple cases, when there are no spanned cells (like in flexbox), it can be done relatively trivially.
Otherwise solving that system is far from being trivial, you will need simplex solver or the like, for example https://constraints.cs.washington.edu/solvers/cassowary-toch...
c-smile Dec 9, 2024
Eh, if you drink, then drink...
1. Add `;` as a separator of elements, so you may have:
```
   { a: "foo"; b:"bar; }
```
2. Add array tags and space separated value lists so you may have
```
   { a: 12 13 14; }

   to be treated as [12, 13, 14] with the tag " ". Normal arrays are parsed with the tag ","
```
3. Add "functors" as, again, tagged arrays
```
   rgb(128,128,14);

   will be parsed to an array with the tag  "rgb". Also you may have calc(128 + 14);
```
4. Add tagged numbers so
```
   90deg 

   will be parsed as a number with the tag "deg"
```
And you will get pretty much CSS that is proven to define quite complex constructs with minimal syntax.

This user hasn’t submitted anything.

Preferences

Keyboard Shortcuts

Story Lists

Navigation

Miscellaneous