sciter-sdk

Ah, they abandoned the old code with the bad license: https://github.com/c-smile/sciter-sdk At least something is BSD licensed: https://gitlab.com/sciter-engine/sciter-js-sdk They sure hate admitting that: https://sciter.com/prices/ (and the links on sciter.com go to the old repo, abandoned for a long time.. I really don't understand why this is supposed to motivate anyone into using it)

I'm a bit curious here. I see that RustDesk is licensed AGPL 3.0. At the same time the GUI component (Sciter - https://www.sciter.com) is proprietary software with it's own non-compatible license (https://github.com/c-smile/sciter-sdk/blob/524a90ef7eab16575...). Was the intention to use something like LGPL to stand on the shoulders of the external libraries or was the choice of AGPL just a hopeful goal with licensing issues to be resolved in the future?

It is part of the sciter sdk. License is: https://github.com/c-smile/sciter-sdk/blob/master/license.ht... . Which well known open source license is this equivalent to?

There is no standard way of representing HTML in clipboard on Linux/GTK. Unfortunately. Even plain text has multiple, conflicting formats. Sciter definitely puts text in GTK clipboard. And it works as far as I can tell, proof: https://sciter.com/linuxnotepad/ on my Linux Mint. So your problem needs some details. And try recent version from GitGub: https://github.com/c-smile/sciter-sdk/tree/master/bin.lnx/x6... You will need 2 files from there: html-notepad and libsciter-gtk.so

The intention was to have exactly Notepad but for structured HTML. Latest version: https://github.com/c-smile/sciter-sdk/tree/master/bin.win/x3... , two files from there: notepad.exe and sciter.dll It does support editing as in WYSIWIG as in Markdown form. Actually markdown is also form of WYSIWYG. But WYSIWYG on steroids I would say. Markdown format was explicitly designed to emulate WYSIWYG but in plaintext.

Please use recent one at: https://github.com/c-smile/sciter-sdk/tree/master/bin.win/x3... You just need notepad.exe + sciter.dll in the same folder.

It's kind of doing that already. Also HTML that is pasted from external sources (browsers, MS Office, etc.) gets "cannibalized" on pasting: https://github.com/c-smile/sciter-sdk/blob/master/notepad/re... with white listed tags and attributes.

Just for the note: it is not ElectronJS. html-notepad is Sciter based application so its distribution is only 5 MB. It's sources are here https://github.com/c-smile/sciter-sdk/tree/master/notepad . This still uses old Sciter.TIS and I am porting it to new Sciter - the one that uses JavaScript. I am an author of the editor (and Sciter).

Yes. Check https://github.com/c-smile/sciter-sdk/tree/master/samples/vi... But Sciter do not have codecs embedded. Instead a. it [re-]uses streaming services of underlying OS; b. has interface for the hosting application to supply its own video streams. This way some applications use WebRTC as video sources, some use ffmpeg library to provide video streams. Video playback architecture is app dependent usually. Sciter provides to them "video rendering site". That's idea of Sciter - to reuse underlying OS services as much as possible. For example Sciter has spellchecking but only if OS provides spellchecking API (and usually they do).

"It does!" at some extent that is far from being adequate for native UI needs. Consider that you need add <word>...</word> element that will implement natively MS Word editing area. This will allow you to define MS Word editing chrome in HTML/CSS but keep core editing functionality native and effective. Consider implementation of <tabs> native element/behavior: https://github.com/c-smile/sciter-sdk/blob/master/include/be... This is a demo of how native code can extend DOM - adding native "drivers" of app specific DOM elements. Yet there are other examples of native behaviors: https://github.com/c-smile/sciter-sdk/tree/master/include/be... Essentially native behavior can do anything that built-in elements can do, even drawing on the same surface that the rest of DOM is using. Good luck with achieving anything like that in browsers, or in E

"Because DOM is slow" DOM is not slow, in principle. What makes updates slow is the fact that each mutating DOM function must left the DOM in consistent state - rendering trees invalidated, etc. This creates significant overhead on massive updates. But: element.innerHTML = "new content"; is significantly faster than sequence of appendNode & Co. because element.innerHTML mutation is transactional. Browsers do not need to notify observers on each element parsed - only whole subtree at the end. I have tests of different methods of DOM updates in Sciter (https://sciter.com) see: https://github.com/c-smile/sciter-sdk/blob/master/samples/te... The test shows that these two methods: element.html = "new content"; and element.content( vector-of-vDOM-nodes ); are significantly faster than anything else as both methods are transactiona

Just to get a feeling, see screenshots of Sciter Notes application on major desktop platforms: https://notes.sciter.com/ The application uses exactly same code on all platforms: https://github.com/c-smile/sciter-sdk/tree/master/notes It even runs on Windows 2000: https://sciter.com/necromancing-sciter-on-windows-2000/

In fact original EverNote implementation (EverNote 2.0) used physical notebook metaphor. Notes appeared as an "endless tape": https://www.phonearena.com/news/Two-thirds-of-app-users-in-U... I think we (initial EverNote dev team [1]) were first who came up with reasonable virtual list implementation for notes. The metaphor of notes tape (a.k.a. "writing notes down") was quite natural for most of people, that's why EverNote got so many users initially. The key point was to add powerful search tools (including OCR and image recognition) and categorization (tags) on top of that tape. Just in case: Sciter's SDK contains sample implementation[2] of such virtual tape: https://quark.sciter.com/wp-content/uploads/2020/05/vtape.pn... [1] https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-... [2] https://github.com/c-smile/sciter-sdk/tree/m

Check this: https://sciter.com/wp-content/uploads/2020/06/ide.png that one has menu, check menu.htm in that sample: https://github.com/c-smile/sciter-sdk/tree/master/samples/id... > So can you run the benchmark suite with Sciter or not? Yes, I may do that but purpose is not clear. Their compiled C versions in Sciter will run definitely faster. These functions have nothing with UI per se. Yet, you can extend Sciter with native DirectX or OpenGL code (see: https://sciter.com/sciter-and-directx/) , that will definitely beat any possible browser/Electron solution. So script benchmarks are orthogonal to the reality. They make sense in Electron case as JS is the only realistic option to write app code. But not in Sciter case. It is not a browser for that matter.

> QuickJS benchmarks Typically we do not do such task in scripts. And indeed who would need ray tracing in script if you have native libraries for that? 100% that number crunching tasks will be slower in order of magnitude than native ones so why to bother? For the comparison you can try https://notes.sciter.com/ that uses Sciter not just for UI but its logic layer is also using script (https://github.com/c-smile/sciter-sdk/tree/master/notes/res). The application has UI and complexity similar to VSCode, Slack, etc. It is hard to come up with some formal benchmarks but startup times, CPU/RAM consumption, responsiveness can be estimated.