c-smile

15 ms·

121.
by c-smile 4y ago
Building codes of course are written by blood and shall be followed. But looking on that photo... You see bunch of vertically standing "levers" around. With their own resonance frequencies. Dynamic of their vibrations is quite com
122.
by c-smile 4y ago
This div { width:100px; height:100px; margin:1fx; // all margins, horizontal and vertical } will place div in the middle/center of its container. a) is significantly easier to understand b) is more
123.
by c-smile 4y ago
Sic transit gloria mundi... XUL, WPF, XAML ... Main characteristic of these markups is that they define not semantic but presentational DOM. Presentational DOM is what old HTML (v.1..3) was all about: all those <FONT>s, etc. So layout
124.
by c-smile 4y ago
> incompatible with most projects. Most native UI projects on desktop OSes are not OSS.
125.
by c-smile 4y ago
Right here: https://developer.apple.com/documentation/appkit/nswindow/14...
126.
by c-smile 4y ago
SwiftUI is not a desktop UI by its concept. It is very close to Web Fronted UI - document UIs running inside a sandbox.
127.
by c-smile 4y ago
> WNDPROC is part of Win32, Users and UI developers don't care. It is part of OS and it is always there. The only things I know for sure are: 1. Desktop OS is not a distribution but set of popular GUI applications that work on that
128.
by c-smile 4y ago
Neither of RHEL, Fedora, Ubuntu, KDE Neon have APIs that GUI developers can rely on. To be short: First Linux company that will decide to provide stable API similar to `WndProc(window, params)` (Windows) or `class_addMethod(window,@selector
129.
by c-smile 4y ago
Glad you've mentioned "GDK X11 backend". It means that GTK is not a desktop API. X11 is not a desktop API either as you cannot build with it GUI consistent with other applications on target platform. Linux is not a desktop OS
130.
by c-smile 4y ago
> Huh? You're out of your mind. Do we have such basic thing as `MoveWindow(wnd,x,y,w,h)` on GTK? Seems like still not: - https://stackoverflow.com/questions/58103333/set-frame-posit... - https:/&#x2F
131.
by c-smile 4y ago
> GTK 4 renders with OpenGL It may do that but generally it still uses Cairo. BTW, I would not rely long run on OpenGL existence on Windows and Mac (especially). In any case GTK working on Windows and Mac is an artefact rather than somet
132.
by c-smile 4y ago
Sciter greatly overlaps with those. It is just that instead of XAML it uses HTML/CSS, JS/C/C++ instead of C# and works on all desktop platforms. For the note: historically Sciter appeared before WPF and WinUI/UWP : http
133.
by c-smile 4y ago
Yes, and what? How that is related to the article we are discussing?
134.
by c-smile 4y ago
> UIs provided by the operating system ... GPU accelerated That depends on what you mean by "system UI". Most system utilities on Windows are still using GDI. GDI is not GPU accelerated (other than BitBlt). Same apply to MacOS
135.
by c-smile 4y ago
> Unlike the UIs provided by the operating system, where you can say "draw a button with the label 'delete'", you have to tell OpenGL how to make a button out of triangles. Just use Sciter, by default for rendering it
136.
by c-smile 4y ago
> computer e.g. in the shape of a 10" netbook I'll buy it immediately Haven't tried OpenBSD but Windows 11 works quite well Samsung Galaxy Book 2 (ARM): https://www.theverge.com/2018/10/26/18
137.
by c-smile 4y ago
2 cents from Sciter developer... For the note: Sciter is an embeddable HTML/CSS/JS UI engine. For desktop and mobiles. By feature set it overlaps 96% with Flutter. It differs in ideology and implementation significantly though. 0.
138.
by c-smile 4y ago
Close but not exactly, there is no esoteric HTC stuff for example. element.selector { prototype: ClassName url(in-module.js); color: blue; ... } That above is significantly better than almost-dead-at-birth WebCompo
139.
by c-smile 4y ago
My sample is correct. CSS prototype property is a Sciter specific extension. When the engine computes styles it does [if needed] this (pseudocode): Object.setPrototypeOf(element, thatClass); element.componentDidMount(); on applie
140.
by c-smile 4y ago
Seems like Safari has quite naive element.append(...list) implementation and/or "destructuring to argv" operation is slow there. I suspect that element.append(...list) is just a for(auto arg : args) element.append(
141.
by c-smile 4y ago
In Sciter you do not need any preprocessor at all, not even JS in your HTML: <style> div.beer { prototype: Beer url(/components/beer.js); } </style> <body> <div cl
142.
by c-smile 4y ago
> native developer You probably haven't done any native UI as native UI uses exactly the same idiom. CWnd* parent = ... parent->appendChild( new EditBox() ); native UI also uses DOM concept, it is just that instead o
143.
by c-smile 4y ago
Again, in case of Sciter, event handlers are not the problem at all as it supports declarative event handlers: class FooBar extends Element { render() { return <form.foobar> <button.foo>Foo<&#x2
144.
by c-smile 4y ago
> this doesn't seem to be accurate It is pretty accurate here, case #3 is significantly (almost two times) slower than case #1.
145.
by c-smile 4y ago
To make it even closer to Svelte, Sciter has native signal() implementation, so let bottles = signal(0); function Beers() { return <span .bottles multiple={bottles.value > 1}>{bottles.value} bottles of beer<&#x2F
146.
by c-smile 4y ago
It depends how really you use virtual DOM. React's "reconciliate whole world" approach can be excessive, yes. But, for example in Sciter, vDOM works in [web] component cases that are similar to Svelte: class Beers extend
147.
by c-smile 4y ago
This: element.append([array of Elements]); is in magnitude of times faster than for(const el of [array of Elements]) element.appendChild(el); so yes, it helps to improve situation. But think about updates like this:
148.
by c-smile 4y ago
Not so easy unfortunately. 1. BeginUpdate stops a control from repainting itself and that is what browser is doing already - no painting happens at the moment of JS execution. So primitive "postpone painting" does not really help.
149.
by c-smile 4y ago
I was thinking of how to improve DOM updates. One of ideas is to add Element.update() method: Element.update(function(updateCtx) { updateCtx.setInnerText(this, "new text"); updateCtx.setAttribute(this, "title
150.
by c-smile 4y ago
Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock

More ›