Has anyone ever considered writing a porting utility that can map x qt etc to the native api and prodyce a tree of diffs that could speed up and simplify ports ?
This way the tool could make the application native and patches could be upstreamed.
It seems like 95% of the effort exists in writing the library to start with. Afaik the biggest hurdle for ports to a different api is the large amount boiler plate code that makes it tedious.
It would also dramatically improve the odds of the haiku api being used.
The last time someone succeeded with a similar effort was the collection of awk scripts for converting SunView programs to Open Look, and that was with OL intrinstics specifically designed to resemble SunView to make porting trivial. Modern toolkits are much more complicated than SunView, so I don’t think an automatic porting tool would be realistic.
Even 50% of the calls would be very difficult to get right. Simple example: how do you distinguish between a Window used as a widget (where the corresponding Haiku concept is BView), and a Window used as a top level window (like a BWindow)?
The parent of the Window is only available at runtime, and that’s the only difference that distinguishes them (toplevel windows are attached to the root window, while “widget” windows are attached to something else.)
That would be an awesome AI project! The complicated thing is getting the training data, which would require a lot of examples of many applications in various other APIs then in the Haiku API. Preferably function to function (function A in QT, function A in some Windows junk, function A in GTK, etc and then function A with Haiku’s API). But given that, should be do-able with an convolutional neural network.