DahliaOS operating system, combining the best of GNU/Linux and Fuchsia OS

Example: if one tool outputs JSON, another tool, like grep, would recognize that is a subtype TEXT, and be able to process it.

Example: a more sophisticated hypothetical grep tool, would recognize that it might grep JSON differently than it greps TEXT.

Example: Tool 1 exporting JPEG might be incompatible with Tool 2 that only accepts JSON. A nice shell error message could result.

It seems like it renders text via a SVG on top of a canvas layer that is the background, so that's a plus for a11y. As for the downsides, and I'm not sure how much this is due to flutter or the app itself:

* I can't use the browser search for elements outside the viewport

* I can't select text at all

* I can't tab through elements/links at all (which is often seen as a strong indicator of bad a11y)

* Browser back/forward do not work as expected (back exits the app completely, and then forward does not bring me back)

The second demo there: https://gallery.flutter.dev/#/shrine

* All the same as the first one, but also clickable elements do not give me any feedback that they are clickable (hand-pointer cursour or any underline/similar effect)

---

Maybe these are just demos that have not thought of these specific things but since it is a web showcase of a framework meant to work on the web (although not exclusively) and these were the first links up there it's a bit disappointing.

My point is that you get most of these things for free (or easy) on the normal web, but flutter seems to try to patch them back onto it instead of using what is there.

Amazing was what Burroughs was doing in 1961, 10 years before C came to be, IBM RISC research in PL/S and PL.8, VAX/VMS stuff in BLISS, Solo OS in Concurrent Pascal, Xerox XDE in Mesa, ....

Those were amazing in the 60's and mid-70's.

For you to get where I am coming from, for me Longhorn only failed due to the usual set of politics between DevDiv and WinDev that those of us on Windows know so well throughout the years.

Had they actually worked together and Longhorn, with .NET based stack would have happened, just like it did with Android and ChromeOS. When technical limitations exist, they can be sorted out when everyone rows into the same direction.

So after its failure, and reboot as Vista, the Windows team took many of the Longhorn ideas and redid them as COM libraries.

This decision started a trend (hence my started with Vista), where all major new APIs that were added to Windows since then, were COM based instead of classical Win32.

You can see this by following the C++ Hilo tutorial later released for Windows 7.

When Windows 8 came to be, they decided to double down on this direction and came up with WinRT, which if you read the Ext-VOS paper, looks quite similar. Ext-VOS being what was being designed as successor to VB/C++/J++ as COM evolution, before all the events that made .NET happen.

So you got the Windows team creating WinRT, they also had their own shot at what .NET should be, hence why it uses AOT based compilation with a compiler that only supports the MSIL sets that they cared about.

As we all know by now, due to several reasons this did not turn out as expected, still UWP (as COM evolution is now know) is still the way to go to all major APIs, even in the context of Project Reunion.

So we changed from Win32 + some relevant projects using COM, to Win32 mostly frozen in Windows XP API level + everything else is COM/UWP based.

This was my point about Vista being the turning point where this took place.

I might be wrong, but this is how I see the evolution of those events.