In the recent thread about reinventing wheels, a popular theme was trashing C++. Another theme that emerged was a graphical code editor that uses XML. This will be the thread about the machine readable/writable XML format.
http://www.o-xml.org/ was one attempt. Its code is lost but the specification remains.
dead link you can check here if curious o:XML Downloads
Yes. The code is gone but the specs are still there. I looked at the Wayback Machine earlier. Thanks for trying. I suspect the compiler targetted a JVM.
I tried a later date but the Wayback Machine didn’t have it. This one has source and Jar file! Thanks!
Continuing the discussion from Any wheels that need to be redesigned?:
I’ll have to look at XSLT. I’m not familiar with it but thanks for the mention @cocobean .
@mazbrili found a link to the o:XML source on the Wayback Machine and it transpiles to Java4 source. Replacing the generator’s string generation will be simple.
The Java source now compiles with Ant. The only modifications needed were that the 1.3 compiler version had to be updated to Java7, and there are obviously deprecation notices but it still works. Hosting is at https://github.com/SamuraiCrow/oXML and CI is active.
I was thinking of modelling the syntax of the new transpiler backend around C++17 using Svelte as a model. Now I’m beginning to wonder if that’s the best way. It’ll work, but my concerns are starting to shift from the graphical editor to the XML language its based on. A graphical development environment is only as strong as its foundation.
I’m looking at Svelte because its compiler-driven approach to GUI development is not based on a fancy object-oriented framework. If I made it work on future operating systems, the code generator would have to be changed anyway. If I used an OO framework instead, it would have to shift the implementation to the runtime library and would be slower and would require the same amount of work for every new OS regardless.
Are there any web devs here that can comment on Svelte and how it stacks up?
The starting point for describing user interfaces should be the BMessage format of archived BView. That should be seasonably easy to translate to xml if you want to
That sounds ok. Is that the raw format that ALE uses?
If you really want XML, look at XAML. It is already a fully fledged descriptive XML based language for UI design, and is used by quite a few .Net frameworks, bit least Maui, the new cross platform one. There is at least one C++ implementation of a XAML parser also : GitHub - Berrysoft/XamlCpp: A cross-platform GUI framework described by XAML, for C/C++ and I also found GitHub - JayDT/XUI: C++ Xaml based User Interface and basic reflection, which lists more projects as its dependencies.
I looked at both. The WebView requirement of XAML is pretty much a show-stopper for me. It makes everything needlessly complicated because making hypertext should not imply a dependency on 3 other languages (HTML, CSS and JavaScript). If I wanted to make a button out of a word-wrapped text object and call it a link, I’d expect the dependencies of that function alone to be little more than that of a word-wrapped multiline text object and a button.
Back in my college years I attended a few ACM meetings and during the XAML demonstration, the presenter showed how to embed a browser in a drop-down menu. I don’t think Haiku can (or should) do that.
In summary, promoting a web-view to a first-class gadget is not going to fly; not on my watch. Consider the Microsoft bloat-ware to be persona-non-grata on my desk.
I’m a little confused: XAML is just a serialization format. For example, I’ve use XAML to create a generic menu structure before, the XAML was loaded at runtime and the menu structure was built from the data. When you instantiate XAML, you end up with a bunch of class instances. The serialization works a lot like SVG or the way the AXML works in Android. There is nothing like what you are saying unless you are trying to do something silly. Here is a Be API specific pseudo code example:
<BWindow Frame="20,20,200,60" Title="Test">
<BWindow.Children>
<BView Offset="B_ORIGIN" Name="MyView">
<BView.Children>
<BButton Click="SomeClickHandler" Text="Click" />
</BView.Children>
<BView>
</BWindow.Children>
</BWindow>
I mean - no web browser. That would map to a BWindow with a BView and a Button. More idiomatic version would be:
<BWindow Frame="20,20,200,60" Title="Test">
<BView Offset="B_ORIGIN" Name="MyView">
<BButton Click="SomeClickHandler" Text="Click" />
<BView>
</BWindow>
No web browsers, no web. This would literally just instantiate a BWindow with a BView and a BButton. I think you might need to actually derive from those classes because they don’t lend themselves to injecting data quite in that way, but the event mechanism can be added. I did this back in the day when I was playing with Free Pascal and making UI for that in the Style of the Delphi API (also event driven.)
Remember - XAML is a markup, XAML is used to represent concrete classes in a serialized format, it is nothing to do with the deserialized version - that is implementation specific. XAML is used by a lot of technology now, WPF, UWP, WinUI, Maui, Xamarin Forms, UNO, Avalonia - a lot of those are cross platform. XAML doesn’t even require you to use any specific classes or implementation - the serializer/deserializer on the platform deals with working out how the markup maps.
This also bothers me, because it demonstrates you have absolutely no clue what XAML is, nor do you understand how it works. Please go back and look again. XAML is exactly what you are trying to reinvent - a markup for defining a UI that can be human edited or edited in a UI editor, and is instantiated in to the exact classes at runtime that you might have hand crafted in code. No HTML, no CSS and seriously, no Javascript. Have a look at this for an example on using XAML to serialize and deserialize arbitrary non UI data: Almost everything you need to know about XAML serialization (part 1) – The Stochastic Game
I must have been thinking of WinForms. Since that is only an application of XAML and not XAML itself, I’ll reconsider your advice. Your earlier 2 links indicated Boost dependencies and one mentioned a WebView as a dependency.
Whether XAML is compatible with Relax-NG or any other parser schema outside of Mono/.Net is another consideration. .Net has some visual language capabilities already via 3rd party add-ons and can be used instead of any less-integrated, modular library but I don’t want to drag in excessively large dependencies. Having never used Microsoft products on a regular basis, I’d prefer to keep it that way.
After looking at the Haiku Book closely, I’m beginning to wonder if it would be possible to make a BViewToXML class that inherits the BFlattenable interface that would use the product of a BMessage like you just suggested. That way the resultant XML could be treated like a resource and just edited externally with an updated ALE app (possibly renamed HALE to differentiate it from the original. 
). The idea of using an editor for a GUI isn’t new, Apple does it with the XIB format, but it would save a UX developer the time of having to write a new export engine every time a new language comes out or a new InterfaceKit version the next time the winds of change hit the UX sector of the industry.
I never saw this page about layouts before. This may affect my decision.