Specifically, look into how XAML apps work on the Universal Windows Platform [1]. Windows application development moved past Win32 about ten years ago with the initial version of XAML (Windows Presentation Foundation).

Nowadays, the event loop is still there under the hood, but it's abstracted away by the UI framework. You are left with independent views that can render themselves, but the raw event loop is exposed as higher level events raised by individual views (e.g., a single "Tapped" event instead of having to handle separate mouse/touch/pen/controller down+up events).

Apps often use some sort of message bus for communicating between non-UI components in a decoupled way, which may or may not re-use the UI thread's event loop. In general, you try to minimize what happens on the main loop, since it can lead to UI unresponsiveness. However, in XAML the main event loop is actually a priority queue, so you can put stuff into it at lower priority than regular input events[2].

1. https://msdn.microsoft.com/en-us/library/windows/apps/dn8946...

2. https://msdn.microsoft.com/en-us/library/windows/apps/window...

Disclaimer: I work at Microsoft, where we're using XAML to build the Windows Shell.

> Disclaimer: I work at Microsoft, where we're using XAML to build the Windows Shell.

This is off-topic, but I have a question about the Windows 10 shell. You previously said that the new XAML-based part of the shell is written in C++/CX. Why not C#? Is the performance and/or memory footprint of the .NET Framework still not good enough, even with .NET Native?

Except that XAML itself is just the XML friendly way to describe what traditionally was done by a resource fork.

Yah, sure its got a few new tricks, but in that regards its just another all that is old is new again. In that it basically serializes the CLR where as the old resource fork serialized the windows API.

For another example see the delphi DFM....

XAML is great, that is what XHTML should have become if browser vendors played ball. Oh well.

Source? I always took XHTML to be an effort to make html into a stricter more parse-friendly format. Xhtml lets you use an xml parser to pull apart a page rather than having to deal with some kind of markup tag soup (which also makes it a great target for tooling within an IDE). XAML is concerned with layouts and binding in ways that, I don't believe, were ever intended for Xhtml. I could be wrong but they've always seemed to be worlds apart.

That is what many that didn't bother to learn the specification thought.

Quote (http://www.w3.org/TR/xhtml1/#why)

Document developers and user agent designers are constantly discovering new ways to express their ideas through new markup. In XML, it is relatively easy to introduce new elements or additional element attributes. The XHTML family is designed to accommodate these extensions through XHTML modules and techniques for developing new XHTML-conforming modules (described in the XHTML Modularization specification). These modules will permit the combination of existing and new feature sets when developing content and when designing new user agents.

Quote (http://www.w3.org/MarkUp/2004/xhtml-faq):

If your document is just pure XHTML 1.0 (not including other markup languages) then you will not yet notice much difference. However as more and more XML tools become available, such as XSLT for tranforming documents, you will start noticing the advantages of using XHTML. XForms for instance will allow you to edit XHTML documents (or any other sort of XML document) in simple controllable ways. Semantic Web applications will be able to take advantage of XHTML documents.

The old HTML behaviors would be achieved by XML stylesheets, rendering into HTML4 or XML events.

There were then a plethora of standards planned to augment XHTML with application level.

http://www.w3.org/standards/xml/components

Bindings in XForms for example, http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-ex...

I've seen comments followed by inappropriate disclaimers a bit recently, so I'm going to go all old man here and let you know that a disclaimer is a statement denying something, not a statement of credentials.

I'm not sure what single catchy word you want here, but that's not it.

I think the word most people are looking for in these cases is "disclosure", in that they want to "disclose" their affiliation so that readers are aware of potential biases in their views.

Yeah typically it would be "full disclosure".

Or maybe the poster is just being self-deprecating :p

Wasn't XAML deprecated some time ago? (Sorry, I'm out of the loop with Windows development).

I am too, but maybe you're thinking of Windows Presentation Framework? XAML files are still used to describe user interfaces in whatever they're calling Metro these days.

no, but they've introduced a bunch of versions of it under different names (WPF, Silverlight, Phone Silverlight, WinRT XAML, UWP), a few of which broke compatibility, so that's probably where you got that impression.

Anyone can bitch about the latest tech because there's very little new under the sun. It's far more constructive to suggest improvements. Like the adage "give me solutions not problems".

In Mac OS (1984), controls were different from windows. Advantage was that controls were more light-weight, disadvantage that one couldn't build a control out of smaller controls (at least, the system did not support that). Its event loop also was extremely rudimentary. If you got a mouse click event, you would have to make a system call to find out what window it was in, then a system call to find a control, etc. If the OS had a real kernel and memory protection, that would have killed performance.

Carbon moved the "giant switch statements" out of the views, inside the library (edit: maybe, even into the kernel. That way, application processes only would be woken up if they really had work to do). Controls had to tell the library what events they were interested in, and what function to call to handle them.

Advantage was that the system didn't need to fire zillions of events to controls that didn't do anything with them (for example, few controls respond to "mouse moved" events, but if the system doesn't know that, it has to send corresponding events to a top-level window, the control below it, the control in the control below it, etc.). That decreased power usage (at least in theory; code and data accessed could be closer to each other, decreasing cache misses, and there were fewer JSR-switch-do nothing-RTS cycles), and allowed for the system to introduce more high-level events (double-click, triple-click, "mouse entered", "mouse moved outside the area of the control", etc) without decreasing performance; disadvantage that registering the exact set of events one was interested in wasn't fun (especially because, in those days, one needed to pass universal procedure pointers to the Carbon library to register handlers)

If you have lambdas and reflection, the latter can be made free for programmers. So, I guess that is an area one could look at. I'm not sure the gains will be real in a system where the windows live in a browser window, though.

A well-defined problem defines the solution. A solution without a problem is worthless.