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.
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.
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?
I write a lot of applications for Haiku and I don’t find it that hard, honestly.
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.
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.)?
I absolutely agree with this statement from @Barrett, 100%.
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.
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.
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.
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.
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.
Yep, I was thinking the same. Qt’s UIC-generated code has a nice structure (
namespace Ui, class WindowName, functions
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.
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:
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
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.
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.
Yeah I see that… trade off for being easier to embed I guess.
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.
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.