|Definition||Windows Presentation Foundation (or WPF) is a graphical subsystem for rendering user interfaces in Windows-based applications by Microsoft.||Is an embeddable graphical user interface engine (dynamic or static library) by Terra Informatica Software.|
|Released||2007 as part of Windows Vista.||2006 – h-smile core release date (HTMLayout, Sciter1, Sciter2 and Sciter3).|
|OSes||Microsoft Windows||Microsoft Windows, Mac OS X, Linux/GTK.|
|Technology||.NET Framework 3.0 and above. Only managed API.||Native code with native plain C API.|
|Distribution||WindowsBase.dll, PresentationCore.dll, PresentationFoundation.dll (without .NET core) ~ 5 Mb||Single sciter32/64.dll ~ 4 Mb|
|UI Architecture||XAML DOM tree||W3C compatible DOM tree.|
|Markup language||XAML||HTML5 and SVG.|
|Style language||XAML, no cascading||CSS – cascading style sheets.|
|Data Binding||XAML data binding: one-time/one-way and two way||
|Media services||vector and raster images, audio, video||vector (SVG) and raster images, video with audio.|
|Graphics||WPF rasterizer on top of DirectX.||
|Graphic primitives||2D graphics along with brushes, pens, geometries, and transforms.||
|Templates||Look of an element can be defined directly, via its properties, or indirectly with a Template or Style.||Look of an element can be defined directly, via its style properties, or indirectly via style sheets. Structure of elements can be "templated" by Behavior classes (native or in script) and Aspect functions and applied to elements via CSS – properties: behavior, prototype and aspect.|
|Animations||low level animation via timers and higher level abstractions of animations via the Animation classes.||CSS transform property based animations, timeline (TweenLite alike) animation engine, low level animations via Element.animate().|
|Printing||Supports paginated documents via DocumentViewer class.||<frame type="pager"> supports print preview and printing of paginated HTML documents. Supports CSS page-break-after/before/inside properties.|
|Accessibility||Microsoft UI Automation||Microsoft UI Automation on Windows.|
I have started BlockNote campaign on Kickstarter
That is about funding of BlockNote2 development: WYSIWYG HTML editor for the rest of us that will work on Windows, Mac and Linux.
BlockNote editor was free last 10 years and if you have found it handy please donate if you can. Each river starts from a small stream.
As a part of this campaign I am also offering discounts (up to 50%) for Sciter license and source code access. And yet advertisement spots on BlockNote front page. Note: that space and number of offerings is limited.
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.
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, 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.
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.
D is really very cool and convenient language but after some time I’ve decided to stop Harmonia development for the following reasons:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
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.
10 or so years ago I was asked to design Word Processor WYSIWYG editing component. The editor should handle editing of paged documents. It has notion of pages where document text is replaced. The text can wrap around absolutely positioned (page box related) blocks – images, text boxes, etc. To be short – something like micro-Word but lighter and PDF-output oriented.
The target application, where it was used initially, was online Web application with UI written as a quite large Java Applet. These days such a technology is know as “single page web applications”. But 10 years ago browsers (actually it was just one at that moment) were simply not ready for productive applications – applications that people are opening in the morning and closing when they leave workplace.
Even at that moment of time Java handled that type of UI pretty well. We just did our own UI framework/set of widgets for it but still.
The Word Processor component was written in C++ and integrated with the rest of Java application through JNI.
We were happy with the app and so did 70,000 users of the application. But joy was lasting only couple of years. As one day Microsoft and Sun did not reach an agreement on Java destiny inside the browser and so our application literally became deprecated in one day. Doh!
So the development of the UI of the application started from scratch again. At this moment of time Microsoft added almost accidentally AJAX support to IE and that gave a hope to the team that they can finally use HTML/CSS for UI of the app. And development started.
But it was still not clear what to do with our nice Word Processor and HTML WYSIWYG editor that used BlockNote editing engine for e-mails. Users already created tons of documents so we cannot simply drop editing functionality from the app. Web platform hadn’t and still has no means to support WYSIWYG editing of paged documents. And even HTML WYSIWYG editing (a.k.a. contenteditable) is still quite far from ideal (e.g. to insert an image you need to upload it to the server first, and so on).
At that moment I almost had Sciter v.1 ready and we’ve decided to wrap it as an ActiveX component (for IE) and so called Netscape Plugin (NPAPI, for Firefox). I’ve created editor’s chrome as Sciter’s HTML/CSS/tiscript and wrapped the editors as Sciter’s DOM behaviors. And we’ve got our application up and running again. As the same Sciter engine run in different browsers we saved a lot of time on cross-browser testing of the editors, it just worked in each of them. And even in Google Chrome that arrived later.
Joy of having convenient and stable application lasted little bit longer this time. Up to couple of months ago when Google Chrome and Mozilla pretty much at the same time declared that, basta!, they are not going to support NPAPI starting next(!) year.
Their motivation is in principle quite understandable: 95% of internet users do not use any plugins at all so why to bother. But, hey, what about our 70,000 users? What they should do? Except of NPAPI there is simply no other means to run native components on the web page in GC and FF… And, again, that happened with 3 months notice… Cool, eh?
So the team is in this interesting position again – what to do with our app.
People, seriously, I believe it is time to consider Sciter as a front-end for even online (productive, business) web applications. Just create HTML/CSS/tiscript once and it will work in all Windows versions and Mac OSX (coming). Linux version will be ready shortly after OSX version.
And forget about testing everything separately in IE, FF, GC, Safari and Opera. Sciter does not require installations – just copy and run it.
Enough is enough, no?
And yet, if you not convinced yet then check this news for IE 11. If in your Asp.Net you happen to rely on things like
if(request.browser.ActiveXControls) ... else ... apply hot-fixes from the article above. Otherwise your app will not work properly in IE 11.
Just in case: here is an example of Word Processor document shown above saved as PDF.
I’ve found first answer in this topic on StackExchange extremely representative.
That reminded me discussion we had when were designing the first version of Evernote application.
Challenge there was to provide UI that allows the user to find notes quickly without need of excessive scrolling.
Each note may have so called tags (a.k.a. labels) assigned. By clicking on tag (left side bar) the tape will get filter applied – only notes with such tag are shown.
By expanding the tag (“+” sign) you can see intersection of notes that have this tags and some others. For example here click on hello->world (on the left) will give you set of notes with the condition
has-tag:"hello" AND has-tag:"world" (see top bar):
And if you type “wonderful” in the search field you will get filter
has-tag:"hello" AND has-tag:"world" AND has-text:"wonderful" applied.
Pretty convenient I would say.
Usually business applications are split in three tiers: user interface layer (UI), business logic layer (BLL) and data access layer (DAL). That split is also known as Model-view-controller architectural pattern.
Ideally each layer should be isolated from the rest. For many good reasons. In any case each layer operates using its own vocabulary (namespace if you wish). For example “Account” in UI means some set of fields (<fieldset> literally). In BLL it is an instance of some class with attributes and methods describing logic. And in DAL it could be just a record in DB with associated triggers and stored procedures.
Code that works on each layer(domain) is serving different tasks. Ideally each such layer may require different programming languages that are optimal for each particular layer. E.g. DB layer as a rule uses TSQL as it better suits DB manipulation needs.
The same thing is about UI. Usually UI tasks are just sequence of rules like “if user clicks here than enable that thing over there”. Such tasks may or may not be handled equally well by universal languages like C++.
Ideally UI layer should have its own language that is better suitable for UI needs. In the same way as DB has its own language (couple of them actually: DB schema definition language and transaction definition language).
After many years of designing various UI and UI toolkits I shall admit that UI automation/programming is not quite OOP task in general. Usually it is better describable in terms of something close to functional programming but with the ability to define classes/objects.
UI is an assembly of sometimes very different UI components/controls. That requires language that is flexible enough to glue them together. That is my vision on TIScript in Sciter.
And of course markup and CSS are also Good Things for the UI. Especially CSS.
I have started Graphin.dll project – portable and compact graphics engine based on AGG (agg2d in particular).
Graphin url is code.google.com/p/graphin
Graphin.dll includes also pnglib/zlib and jpeglib with the ability to load and save image object to/from byte vectors (and so mm files) as png/jpeg.
Intention is to have graphics engine that is portable and simple to use. With Graphin it should be possible to reproduce <canvas> functionality
in any language/environment.
There is nothing spectacular yet there but structure is established and couple of methods like graphics_rectangle, graphics_line, etc are written.
Graphin is based on agg 2.4 and contains that agg2d thing written by Maxim Schemanarev .
agg2d class was ported by Jerry Evans from agg 2.3 and contains fixes made by Maxim, myself and Pavel Korzh.
New members of the project are very welcome.
I am planing to use Graphin as graphics backend of multiplatform versions of htmlayout and sciter.
Update: here is a screenshot of Graphin Demo project.