Haiku: Where to innovate?


#62

I was thinking about GUI editor recently, and given the availability of C++ frontends (libclang namely) I’m not convinced any intermediate formats are necessary. Something like C# WinForms editor had (SampleWindow.Designer.cs) could work for C++ now as well, I think.


#63

Yeah,as long as it works well a direct layout editor might be fine as well…

Also there is https://github.com/vgvassilev/cling

That would allow you to live update the live preview of your application… by actually interactively compiling and running it as you write it.


#64

That cannot be ideal, right? Unless the development machine has top-end components (processor, RAM, etc.), it’d be very cumbersome to use it. Wouldn’t it be compiling every time something changes?


#65

The Flutter approach is very similar, it uses Dart which is something like a Java-ish javascript. And it has some interesting and futuristic features, I think we should surely take inspiration from things like that. Flutter has the advantage of using FIDL, which is heavily inspired on the OpenBinder IDL and Android AIDL. As stated various times we should move into adopting a definition language as first, that’d allow easy bindings with other languages and conversely, easy adoption of new technologies like Dart. If Dart was ported to Haiku and something equivalent to FIDL could be provided then the Haiku ecosystem could boom up and regain some of the lost ground in 20 years of development. We really need to make easier writing applications for Haiku.


#66

I write a lot of applications for Haiku and I don’t find it that hard, honestly.

If I was to work on some language specifig for gui building, I would not jump into dart or javascript, however. Why use a programming language here? What’s wrong with c++ then?

What I can see an use for is an easier way to describe user interfaces for prototyping. A declarative language is what we would need here. We have sort of abused the c++ compiler into doing that with BLayoutBuilder, but the compile/run/test can get a little annoying.

The Aukland Layout has a GUI builder, that’s one way. Layouts can be archived to BMessages, this could work nicely and there were some attempts at this already.

Just add some declarative language above that and I think we could have a good start for this.

However so far, I’ve been happy enough with the existing tools and did not feel the need to start working on something like this.


#67

Well, you (and probably a couple of others here) may certainly not find it hard to use C++ and the currently existing tools for building and designing applications, but there are even more others who may find it difficult for a number of reasons:

  • They may be used to different paradigms
  • They may be used to different syntax standards (like ECMAScript)
  • They find the current tools difficult to grasp
  • They may be more proficient in other programming languages

Being “fine” with what is now available is not necessarily a good thing, especially with a niche OS like Haiku. Making application creation easier will open up the platform to more programs being made for it. As a first step to this, may I suggest BeAPI bindings for other languages besides C/C++ (e.g. Python, Go, Rust, etc.)?

:point_up: I absolutely agree with this statement from @Barrett, 100%.


#68

Please, please, please do not suggest the use of JavaScript for such things. It’s annoying enough to use for web development :unamused:


#69

Oh no, I’m just pointing put that it is an option for use in conjunction with QML. If you don’t like it, you can avoid it or use C++ instead. Besides, QML is faster than JS. :grin:


#70

I think we need a decent browser before we can think of where to innovate. I know a lot o man hours gone down with Web+, and I am greatful for that. Still it’s very bad compared to what modern browsers look and works like on other systems. Today everything is about browsers, slack, spotify (electron, node.js).

I like C++ but its like regular expressions, if you plan to solve a problem using C++, you got two problems and some memory leaks.

That said, I think C++ should stay the main language for developing Haiku, but offer bindings for other languages for App development. I would love to see full Swift support.


#71

Is Swift used extensively on non-Apple platforms? There is Linux support (not sure about Windows), but it is really used outside of iOS and macOS? Someone, please enlighten us regarding this.


#72

Its used on Linux. I met some IBM developers during WWDC that uses Swift in a webserver enviroment. Compared to C/C++ its indeed very small.


#73

Are there any user-facing (read: GUI) Swift applications on Linux that might be useful on Haiku? What toolkit do they use if there are any? Tbh, Haiku is not ideal as a server OS for a variety of reasons.


#74

Yep, I was thinking the same. Qt’s UIC-generated code has a nice structure (namespace Ui, class WindowName, functions SetupUi and TranslateUi, etc.) that we can think about preserving. We can just read/write BLayoutBuilder structures in here.

I’ve been wondering how much of this should be first-party tools though. There are a lot of in-tree applications that could benefit from a GUI designer tool, and other OSes are now shipping GUI profilers as well with the system itself.


#75

It isn’t that slow, it uses incremental builds to do it… so it’s really only rebuilding whatever code you change as you go along.

Bringing a REPL to C++ is a pretty big deal, I’d suggest watching this:


#76

Hmm. I’ve known about that for a while, but I’ve never really tried it. Perhaps I should…

Uh, no, you misunderstand the point of cling. It does compilation/interpretation on-demand, like JavaScript is, instead of compiling ahead-of-time. So it would require a beefier machine that would normally be needed to use the software you are writing indeed, but not that much beefier…


#77

Note the guy in that video is using https://github.com/onqtam/rcrl which is different from cling and apparently easier to embed. I think both probably have their own place.


#78

And it actually looks slower and less flexible than cling since it just uses a regular compiler on the backend, instead of cling's “Clang as JIT” model.


#79

Yeah I see that… trade off for being easier to embed I guess.


#80

With this approach I don’t think it’s an issue. Since it’s just a regular language file it can be edited by hand (if I understood what you’re trying to say), and external tool is not a requirement.


#81

I’ve built c++ API before with bindings for c#, python etc using swig: http://www.swig.org

Might prove a fairly quick way to give access to other languages. If you write the binding scripts properly you can use the target languages own idioms (Eg native iterators).

Would this be of interest to anyone? C++ to python is pretty easy to do.