I don’t mean cross compile but if it’s supported then it’s much better.
I mean cross platform frameworks, e.g: GUI toolkits, that support Haiku.
Since Haiku can’t be used as a daily driver for me, I would prefer to develop on Linux and got the product to compile on Haiku.
The reason is very simple. It’s not just because Haiku lacked of a decent browser as I used to said. It’s about Haiku’s poor performance. It’s still in the stage of early development, the developers already said they turned on all of the debug options that caused the performance to suffer. I confirmed this when I tried to build a medium sized C library on Haiku. It’s much, much slower to compile than on Linux, perhaps more than twice as slow.
So I think my approach is right. Let’s treat Haiku as the RPi. People develop on x86_64 and then bring their products to the RPi to compile, if the compilation is too slow then they cross compile to the RPi from x86_64.
The only one of such framework now is Qt. Haiku got pretty good Qt support, apart from the QtWebEngine. But what about something different?
I think the OpenGL/SDL based GUI toolkits is the solution. They looked the same on all platforms, have reasonable appearance despite the look and feel is not as native as Qt.
Utilizing these frameworks, we could develop on Linux to enjoy the very good development tools there and got our products to compile and run on Haiku without much code changes (hopefully we could compile the code as is without any modifications).
Only in nightly builds. Did you try beta2? Also, did you put your sourcecode on a non-indexed BFS partition? Did that make a difference?
Well, personally I’m not interested in Haiku if the only point is running apps that also exist on Linux, but running them slower. That’s not what we’re trying to do, and that’s not something that will make Haiku succesful. Native apps using the system the way it’s meant for, and optimizing the system so it is faster, are the way to go
Well there are cases where having a standalone cross-compiler would still be useful, like CI (NetSurf complained for years, and had to install a Haiku VM while other platforms can be compiled from linux).
I guess we should someday upstream the GCC patches first.
You’re correct, of course. However, it’s going to take quite a time to develop a decent number of native Haiku applications, and until that process is reasonably complete there will continue to be a need for ported apps.
The success of the LibreOffice port is a case in point. It has made a huge difference to the usability of Haiku as a general purpose operating system.
I think devs may be inadvertently putting people off contributing to Haiku, when it is repeated that they want native apps. It gives the message to newbies that they will need to code native apps from scratch - which most will probably be unable to do. So they leave. But they may have enough coding ability to port an app first and see how it goes. After that, and they see that the ported app is not as great as they thought, they may like to progress to coding a native app. Perhaps all that’s needed is a “ported app” repository, separate from a native app repository.
It seems a perfectly reasonable opinion to me, and the words “I think” indicate that Syd knows it is only conjecture. Nonetheless, the fact that he holds it is evidence that at least one person is discouraged by the impression given that ported apps are not wanted.
As a Haiku user, and (extremely modest) contributor to its finances, I feel that Haiku should be happy to support any efforts to add to its application base, whether ported or not, whilst hoping that those who can will endeavour to develop native applications.
At the end of the day, the Haiku user experience is superior (in my view) to that of competing OSes, and the main thing holding the project back from getting many more users (other than sorting out a few bugs) is the dearth of good applications, whether native or not
A bit offtopic, but OpenGL / FreeGLUT / SDL / GLFW / GLEW do not provide any widget library, so they are not “GUI toolkits”. They only provide an abstraction layer to OpenGL 2D / 3D graphics. They can create a window with single OpenGL canvas in it, but no button, checkbox, combo, menu, etc.
On the other hand, wxWidgets, GTK, QT, FLTK and some others are really GUI toolkits (all crossplatform) with capability to use OpenGL.
HaikuPorts is the appropriately named place where ported applications find a home. It happens they do such a great job at it that native apps are now distributed through the same channel. It seems people find their way to porting apps just fine already
In this thread we are talking about a different thing: writing new applications for Haiku using a non-native toolkit. That’s different from porting, I’d say.
Also, the native toolkit is easy and fun to use, and easy to get started with. I don’t expect it would be the thing to put people off in that configuration.
But if I don’t run Haiku as my development machine, the only solution left for me is to use a non-native toolkit, isn’t it? I hope someday I could use Haiku as my daily driver, too, but it’s not the case now.
Well you can also work inside a Haiku virtual machine. And yes, the SDL based toolkits are probably fine. I’d avoid OpenGL because it’s software rendered and may end up using more CPU when there is no reason for that in a plain UI, but that also depends what your app is about. If you’re going to have lots of 3D or other OpenGL stuff in it anyway, it’s worth considering
I mentioned this in another thread but I think the OCaml/ReasonML based framework called Revery is pretty nice and I would like to see that working in Haiku. Unfortunately it might be a lot of work since it requires porting some of the OCaml fundamentals but I think some work has been done on that. AFAIK it uses SDL, Cairo and OpenGL for the UI drawing.
I successfully got the Onivim 2 editor which is the flagship for Revery building and running on macOS, Windows and Linux so the cross platform support is pretty good.
Getting Revery working in Haiku is on my long list of things to look into when I get time, but for me at the moment that probably means not for a while.
