Port BeOS UI APIs to Windows, Linux


The API is open source, so if anyone is motivated enough, no technical reason it cannot be done - Gobe did it for the Windows / Linux port of Productive back in 2001.

This is a community / volunteer project, so naturally people will work on scratching their own itch in their spare time.

A great Haiku exclusive open source app may get other communities to do the port instead. It worked for GIMP.


I am using BeAPI to write a program running under OpenWrt. :smile:


Why not join the project and write a linux framebuffer or sdl backend for the app_server? You have most of it already in etkxx.


… if you ignore APlayer, the open source alternative to SoundPlay that I got to run on Haiku with little interest from anyone.


I did not expect anything from the beta release and it did not disappoint me.

I’m using it as my main OS for the last few years. I consider myself quite productive both in and outside of Haiku. It’s not done yet, but it works well enough for me and not necessarily worse than others (it has different problems, and at least it has problems I can attempt to solve, making the thing so much less frustrating for me).


You also took a bounty to update UltraDV, to which I donated some money. You promised lots of fixes and enchancements to the app, but from what I know, no new major version was released in the end.


I think you’re still missing the point, a portable version of the BeAPI would still not be equivalent to running on Haiku… it would merely let you write some apps on other OSes with the BeAPI that you would otherwise have to write with QT/SDL/GTK or what have you.

You’d still need to run natively only Haiku for some things, like queries, system integrated replicants, and the rest of what makes Haiku what it is… the BeAPI is the core, sure but it is not the be all and end all of what Haiku is, design of the kernel, UI and now the package management all make it unique.

Also, SDL or FLTK might make a better target since they change much less than QT, given all three have similar levels of portability.

Many BeAPI applications could become popular on other OSes though… in which case it would attract developers to them to make improvements. And if they like one BeAPI application why not just run an OS designed to run them the best???


There are three outcomes here:

  1. The BeAPI is not used on Linux except for one or two applications. This makes the BeAPI port a waste of time for the Haiku developers and sets development of Haiku months back due to the time it took to develop the new Linux port.
  2. The BeAPI becomes popular and many Haiku apps are ported to Linux and new developers make their apps using the BeAPI. Unfortunately, these apps are not ported to Haiku instead favoring the well-established Linux. Haiku slowly dies and Haiku, Inc. becomes BeAPI, Inc.
  3. The BeAPI becomes popular and many Haiku apps are ported to Linux and new developers make their apps using the BeAPI. This boosts the popularity of Haiku. Development speeds up and Haiku quickly reaches R1.

The first option is probably the most likely…


The first option is the most certain not to happen… They Haiku developers aren’t going to do this at least not the core developers working on Haiku currently… there are a couple guys like already working on similar things though and it’s possible much if not all of their work could be adapted relatively quickly. If it was created I imagine they wouldn’t mind maintaining it though since it would be pretty handy after all.

2 is extremely unlikely also… due to the fact that the BeAPI is only part of what makes Haiku what it is. If anything the BeAPI being sucessful elsewhere would funnel money into the Haiku project to develop Haiku more.

3 is a bit optimisitc but possible.

The most likely is a 4th option is most likely where a few developers not working on the main body of Haiku work on it, Barret/athonylee for instance, and it becomes easier for Haiku developers to write all thier applications even portable ones as BeAPI applications instead of having to deal with QT etc… it may or may not attract more developers but it would be a major conveniece factor for developers that already know the BeAPI or even those just learning it.


I promised to port UltraDV on Haiku, not sure of what features you are referring to. However, why not reaching to me before? I think we even had some email exchange or IRC chat. I am not even going to question the fact that there’s actually a release on haikuports. I see you donated 20 USD, do you want a refund?


You promised some ‘news’ regarding your work on UltraDV in IRC once blog posts about your work on the app stopped being published. Here just some examples:

(31st Jan 2017)
[02:36:06] there are some UltraDV news coming in the foreseeable future

[03:08:53] so I will just get UltraDV one step forward for now

[03:14:34] hello Barrett … do you still work on UltraDV? Is it usable now?
[03:15:02] Vidrep, LoL
[03:15:19] ups
[03:15:27] BrunoSpr, it needs some love still
[03:15:41] news in February

(23th May 2017)
[01:08:53] I have already something to say about UltraDV, it’s just I’m trying to reach the wave for this to happen
[01:09:13] AndrewZ made me a donation, now close to a year ago, but I didn’t complete what he asked still
[01:09:29] that’s because I got into a project, then another like a chain

[01:25:22] Are you going to finish UltraDV to everyone’s satisfaction?
[01:26:40] I made a donation as well, with the understanding that it was possibly not going to be a completely finished app.
[01:27:13] I’m going to add something to UltraDV to call it alpha1

But nothing emerged from these promises unfortunately.

And no, I don’t need the refund. Lets consider my small donation as ‘thank you’ for you work on Media Kit.


Please do not spread misinformation. My relationships with AndrewZ have absolutely nothing to do with the “freedom sponsors crowdfunding”.

The donation mentioned in IRC has been done privately, with a precise request. I actually made 80% of what we agreed, and he already received an email a couple of months ago with apologies and my availability to refund him if the project isn’t finished by 2018.

You can clearly read in the crowdfunding page, that the agreement was to work for a couple of weeks for 550 USD/week. In total I received US$ 265.00. Just go in my github, you can look at the timeframe, see the amount of work and tell me if I recovered my living costs or not. I actually did two weeks of very boring work to get the app ready for future development, that was the purpose of the crowdfunding.

From this perspective I don’t really have a credit with you of any sort. This is one of the reasons I gradually detached from the community and stopped most of my public activity and your behavior is not certainly make me step back.

Sorry, at this point I am not going to accept any thank you from you.


Quit being such a pain both of you (Barret,Akuji)… and just get along with people for a change. The least you can do is be polite and understanding. I disagree with others quite often but I do my best to be civil about it and certainly I realize that holding grudges is counterproductive so in the end I either end up coming around to their point of view or convincing them of mine anything less is unacceptable in my book.

On the one hand $20 tends to make people expect things to move along quickly but frankly $20 just doesn’t’ go very far unless there are alot of other $20 along with it… development is expensive.

On the other, Barret you’ll win more people over with honey than vinegar…


I love SoundPlay, but that’s me :wink:

How is your new project coming?


The way I see it:

It becomes possible to port apps to Linux “easily”. For app developers, this means 2 OS to support instead of one. The codebase for the BeAPI and other parts of the OS is not the same, so there are 2 sets of bugs to avoid/workaround. Existing Linux devs don’t bother and still use Qt. Existing Haiku devs maybe use the BeAPI, but don’t bother about what happens on Linux with their apps. The apps are full of glitches there, making a bad impression. The whole thing never really takes off. Eventually we have a more fragmented ecosystem.

Look at how it’s going with MUI on Aros, MorphOS, and AmigaOS 4. The 3 systems are similar, but maintaining an app for all 3 is just very annoying. And each app has its own preferred OS.


That’s the best answer. Could be done (like in do it yourself if you want to), but it’s not going to be “official” by the disadvantages told here.

Even people using GTK are beginning to migrate to Qt as their api changes and broken things make people unhappy. Like Thunar author iirc.


It’s about time GTK is abandonned. It was created as an alternative to Qt back when Qt was not under a free software licence. But doing oriented object programming in C was never a good idea.


I think those are “bar discussions”. You all remind me of those smart people, that 10 years ago were saying to the world that wayland was going to replace XOrg and that it was near to abandon. At that time, I’ve been telling users that it’d take a long time before xorg is dropped. It’s 2018 now and even if wayland had certainly some applications, especially in mobile, it just has not happened. Now you tell me gtk is going to be abandoned. I say the same, it’d be a long time.

But, those arguments are interesting. Following you reasoning, then the HaikuAPI has absolutely no possibility to get app developers. If gtk that runs on a mainstream platform with millions of users is going to be abandoned. Following this train of thought, then Haiku should drop the BeAPI and move on top of the Qt framework.


You are perfectly right. But, there’s a strange situation here. I can’t speak for other contractors, but since when I started to work on Haiku, occasionally some people pop out and do things like that:

  • Blame me for breaking their audio, when there’s no relevant change from me and it probably depends on the very cool Haiku Heisenbugs™ feature.
  • Blame me for “optimizing Haiku for real time audio, blah blah, you should do this or whatever, blah blah”, that said from people who doesn’t absolutely understand what they are saying.
  • People join in IRC and pretend that I fix their problems.
  • Someone contacted me each time I joined in IRC to ask me news about the development.
  • Receiving emails from all sort of strange people, like someone asking me to develop his idea for the most secure operating system ever, and when I told him that he doesn’t understand how computer works he continue to don’t listen.

I could continue for a while. And don’t misunderstand me, I am a kind of talkative person, I like being in touch with people, even crazy people. Most of those people are nice in the end, majority of them doesn’t even do it with the intention to offense or to annoy. But on the long run, it just becomes too much.
So I am not holding grudge with anyone, I am just gradually switching my communication model to be as silent as possible. I already unsubscribed from all haiku MLs except haiku-commits. I want to finish the discussion here, as I don’t want to discuss this stuff anymore, and I hate going out topic for so much time.


Let me add another consideration. We are discussing of Qt and GTK, which both are multiplatform toolkits. They are both oriented towards GNU/Linux, but certainly part of their success is due to the fact that it made easier to port some software to OSX or Windows. There are even some applications that switched to those toolkits for the sole ease of development.

In the end, you are citing as argument two toolkits which did exactly what I think Haiku should do. Did you ever considered what could have happened if that path has been taken from the begin?

I remain convinced the community has a problem handling with the future and possible strategic switches that could improve the ecosystem situation a lot. It took years to make people understand why I am for implementing a new media framework, it will take years to make people understand why we need to go multiplatform at least partially. That’s why I am switching my media development in a multiplatform environment.