You might be in luck with that one, given that C++ Interoperability it is actually being worked on in Swift, making Swift API bindings for Haiku possible.
https://github.com/apple/swift/blob/master/docs/CppInteroperabilityManifesto.md
2 Likes
I need a new port of Alex the aligator 1 - 3 for haiku, (Last available for beos). Some new stuff for my son. I have tried it but have no luck with them.
If Haiku had OpenVPN support, I’d be mostly there for using it daily for work. Webcam support would be nice, along with Slack/WebEx.
In this order:
- QupZilla/Falkon
- OpenVPN
- Pidgin
- proxychains4
- GIMP
- Anki
Built-in feature to anonymously report crash of program would be cool.
Gimp use x11 to run, we had a port back in beos.
We have some alternatives around:
Wonderbrush
https://depot.haiku-os.org/#!/pkg/wonderbrush/haikuports/2/1/2/-/9/x86_gcc2?bcguid=bc2377-UNJT
Krita
https://depot.haiku-os.org/#!/pkg/krita_x86/haikuports/4/3/0/-/1/x86_gcc2?bcguid=bc2108-WXYC
Imagemagick
https://depot.haiku-os.org/#!/pkg/imagemagick/haikuports/6/9/11.14/-/1/x86_gcc2?bcguid=bc2502-REWL
Imagemagick gui
https://depot.haiku-os.org/#!/pkg/imagemagickgui/besly/1/1/-/-/2/x86_gcc2?bcguid=bc2780-SHNJ
Watch out haiku depot
It does not necessarily need X11. As it is using Gtk having a working Gtk port which supports Haiku’s display server for output should work, just like it works for e.g. Qt.
1 Like
Sounds like a challenge 
1 Like
We have not done this because we think such reports won’t help much. Usually when someone makes a bugreport, we need to ask some questions to them about what they did to trigger the crash, and get confirmation from them that the problem is solved when we have a fix. And as our team is small, there is currently no use in getting dozens or hundreds of semi-automated bugreports where we can’t do that.
Sorry for making life harder for users in that area, but our small team and beta status means that this is a better balance of work (more work for users, but less work for developers fixing the bugs)
2 Likes
None I’m going to take up, though. But I think I have seen some discussion about porting Gtk somewhere.
Emacs, with GUI. Emacs is best used with GUI, our Emacs is terminal version.
Java. We already have OpenJDK. But it’s buggy. Searched on this forum it’s still possible to found screenshots of Netbeans happily running under Haiku and the fonts looks awesome, making us running on Linux envy. It’s no longer the case. The fonts now looks worse than on Linux and Netbeans no longer runs.
Should we need a FreeBSD compatible layer? It will ease porting software, as we could grab it from FreeBSD’s port tree and patch it to work on Haiku without much efforts as currently we do. The software ported using this layer should not be mixed with packages on HaikuDepot but better remains separate. The user install the compatible layer from the Depot, and the compatible layer includes it own package manager, could be based on FreeBSD’s pkg. These packages will be installed to a separate directory to not mix with Haiku’s native packages, this directory should preserve the FreeBSD’s file system hier, e.g: it contains usr, usr/local,… to ease the porting job. The compatible layer should include a X server. It’s basically a FreeBSD userland running ontop of Haiku.
It’s nothing shame to doing so. Even FreeBSD has to implement part of the Solaris kernel to be able to have ZFS. It’s a big job indeed, but I think it’s worth. You are free to develop native application for Haiku, on the other hand, you will have a large number of applications ported and running.
Note: The software ported by this way will not replace already ported software, as they live in separate place. It’s another way of porting software, but not the only way. To illustrate that, I have this example:
Program X, based on Qt. Haiku already has a port of it on HaikuDepot. (Qt/Haiku)
Thanks to the compatible layer above, there is also another version of program X. (Qt/X11)
It should be able to install both and run them simultaneously, as they don’t conflict with each other.
The applications installed using the compatible layer should be put in a separate category in Haiku’s menu to distinguish them from the HaikuDepot ones.
I also want to suggest a specially shell for the compatible layer, something like MSYS2 on Windows, where the environment is set to run applications ported using the layer only, to avoid conflicting. The normal Terminal would not able to call these applications.
But why? The biggest problem at porting stuff is actually linuxism.
We decided to not port X11, because it is a mess, which we dont want to use (this however wont stop you to port it, but the HaikuPorts team not interested in it.
If you attemp it, at least make it rootless, please.)
2 Likes
I really don’t think this is a good idea for an operating system that strives for a consistent user experience. I have used msys on Windows and X11 on OSX and it was a terrible experience, even if sometimes technically useful.
Compatibility layers that the user doesn’t have to deal with are a completely different story, like our FreeBSD compat layer for network drivers that is very useful indeed.
1 Like
That would degrade the user experience a lot. These programs would run inside an X server, the clipboard would not be shared with Haiku apps, etc.
It would also be a huge lot of work: adding FreeBSD compatiible system calls to the kernel (which may require major refactoring of the kernel), porting an X server, and all of this for apps that don’t integrate at all. It makes Haiku a less usable and more buggy (because there will be bugs in all this new code) than FreeBSD.
If you want to run FreeBSD applications, just… install and use FreeBSD?
4 Likes
And we have the FreeBSD guys sorted out all of the linuxism for us
MSYS2 is pretty good, though. What I described should match Cygwin more than MSYS2. And yes, running X11 applications through Cygwin on Windows is a bad idea, too. But given the fact that both Haiku and FreeBSD are more similar to each other than Windows and Linux, I think it will not that bad. I have used to FreeBSD’s Linux compatible layer and it’s pretty good
No. I don’t want FreeBSD. I only want Java. The current state of Java on Haiku is not good. It used to be good, as I mentioned on my previous post. I have studied the log and it turn out something with mmap (or nmap?) was wrong. Then I come up with that idea. First, it solved my Java problem. Second, I will have all of GTK based applications that I used to use, e.g: Firefox, Chromium,…
Can be doable, if you bite the bullet and port X11 and the other required tools. Pretty bad i have no time for adventures like this nowadays.
First of all, there is a GTK3 port in progress already. Secondly, Blink (Chromium’s web engine) is also undergoing a port in the form of QtWebEngine which has recently started to render pages and video:
Thirdly and lastly, it is extremely difficult to port full-fat web browsers like FF and Chromium due to their complexity; there are entire platforms (almost like OSes) themselves and it doesn’t help that those two in particular use GTK3, a port of which is still (as mentioned earlier) still in-progress.
As for the Haiku devs, they (especially @PulkoMandy) would rather spend their time improving WebKit (which WebPositive uses).
Closest thing to what you want that could realistically be achieved in the foreseeable future is when the QtWebEngine port is finished and something like Falkon can be ported over.
No X11 port necessary for any of that.
3 Likes
There is a separate thread where you can see progress of GTK / GDK port by 3deyes:
https://discuss.haiku-os.org/t/haiku-backend-in-gtk-gdk/9338