Port BeOS UI APIs to Windows, Linux

Ideas
#1

Hi,

Question:
Is it possible to port the Be library or the part related to UI applications to other operating systems such as Windows or Linux? Is it possible to say: “You can develop your graphical app in Gnome, Qt, Windows UI API, but also BeAPI SDK”. This BeAPI SDK port can even have its own website.

Benefits
If the BeOS APIs are good then they should be a major selling point. A lot of Be APIs will always be available only in Haiku, but the UI APIs related to windows, dropdowns, etc should be more portable. If people have these BeAPI to develop graphical apps on Windows or Linux then not everyone will compile its app for Haiku, but porting these apps to Haiku should be much more easier, if not trivial, when they decide to do that or the project is open source. This will allow more apps to come to Haiku on the long term. Or the other way around Haiku -> other OS. Currently it is not so inspiring to start my commercial app in BeOS UI APIs if I know that I will be locked only on the Haiku platform or I will need to spend time and money on re-writing it.

Expected problems
I know a lot of people will jump that Be architecture is different, everything is a thread, etc. The native Be graphical library is probably using a lot of things that are part of the OS, so this will make the port much harder.

Is it worth it?

Please, please:

  • stay on the topic, do not discuss icons in this topic or other irrelevant stuff such as past experiences, memories, etc.
  • do not express emotions, just give clear arguments
  • do not post one liners, these are hard to interpret and for sure miss the argument part
  • do not act as you are all mighty knowledgeable, I will think you are 14 years old
#2

Sure. The Haiku API would be a good minimal multiplatform toolkit.

Don’t believe those 90ish lies. There is one single thing which is a problem, i.e. opening files by inode. Other stuff someone may have told you, are all lies. There’s no technical argument to state that linux or OSX could not handle the internals, if any, someone can make arguments in the opposite sense and begin to list things which the Haiku kernel should provide (example: channels).

Yes it is. But not in the current form, some parts of the API should be probably dropped in favor of newever ones, not because you can’t port them, just because some parts are to be rewritten anyway.

I will anticipate officially that I am developing the media2_kit and the codec_kit on linux as part of the V\OS project. Some new development activity should be visible in the next weeks.

3 Likes
#3

Already done 3 or 4 times (Cosmoe, BlueEyedOS, and when GoBe Productive was ported to Windows, as well as V\OS that Barrett is currently working on). I hope to see it as a working and maintained offer someday, as I’d rather write my apps for Haiku and still somewhat make them available to other platforms :slight_smile: .

7 Likes
#4

Maybe an offical port from the Haiku team should be considered? :slight_smile:

#5

And who would do that? Why is Haiku dev team expected to do everything that even remotely touches Haiku?

7 Likes
#6

Other projects like Cosmoe and BlueEyedOS have already tried this and personally, I think trying to be backward compatible and port over the Be APIs on Gnu/Linux is a complete waste of time. Yes, there’s great BeOS applications (from the early 2000s), but they’re as old as something that would run on Mac OS 9. As for Haiku apps, there’s… Haiku. So I don’t see the need for Be compatibility. But that’s my own opinion, nothing more. I applaud those working on a Be compatibility layer/solution and respect their efforts (but again, I’d ask why).

That said, as for my opinion, I believe if someone is going to bring a Be experience to Linux, it needs to focus on the future, not the past. This is why my approach (Couplet) will be more like Mac OS X was.

Old applications will run inside qemu + kvm. It won’t be anything as elegant and seamless as Classic, (as its an emulator after all), but it will be able to have a graphical front end for user control, cross-mount images, open Be apps inside and take care of the legacy problem, so long as someone has hardware acceleration. Without it, the experience will be slow (but even then, it’ll still work, albeit with a warning to the user.)

But the real area to focus on is the user interface. And that’s my personal favorite. I’m not good at low level design, but I do know UI. So far, the only attempt to bring a UI over is Zeven OS on Xfce. New applications will be built on a new foundation. Couplet will have its own HTML5 based applications, which will not be backward compatible, but as web apps, will inherit all the modern capabilities, including CSS support in elements.

So there’s my answer to this question for the interested.

1 Like
#7

I use SoundPlay as a prime example of why BeOS compatibility is a must. There are great BeOS apps that have yet to be replaced with native Haiku apps.

#8

I do not want to port old BeOS apps to Linux or Windows. These are old stuff. I suggest making programming and porting for Haiku more attractive. I am talking about this when I say BeOS UI API:

#include <Application.h>
#include <Button.h>
#include <Window.h>

If you can code and test on another OS (not Haiku) that gives you comfort. Also it sounds motivating if I can code my app with the BeOS UI API and I know I can then re-compile it for Windows. Also it gives you popularity when you start competing with GNOME, Qt and the Windows UI APIs.

Another option is porting Mono and then managed bindings for the above APIs should be created.

2 Likes
#9

If many people start using:

#include <Application.h>
#include <Button.h>
#include <Window.h>

This will increase the popularity of Haiku and it will increase the number of apps available on Haiku. See my answer above.

#10

That sounds good - Im thinking about learning programming, but its more attractive to try do things, that will work on more OSes that I use, not just one. Thats why Im thinking about Qt.

#11

I still don’t understand why do you want to use BeAPI. If you want to code a cross-platform app, use Qt. It works on Haiku, is more modern and has more controls available (BeAPI shows its age in some places and we are limited in what we can change until R1 is released).

If the app is cross-platform you won’t use Haiku-specific features anyway, and if you really want to you can do the same with Qt (for example node monitoring - nothing prevents you from using that in Qt app).

IMO the cost of such port is not justified at all.

1 Like
#12

You know what I don’t understand… pushing away developers that are interested in the BeAPI in any way.

Being able to run it in some form on other OSes would be a huge plus, I think some of the developers around here have even alluded to this as they sometimes want to write apps that are portable to other OSes… but currently that means choosing QT etc… if they could write portable applications that run best on Haiku then all the better for Haiku and us all.

While some of the other projects have failed like Cosmoe etc… I don’t see why anyone wouldn’t consider them interesting at least.

Availability of the BeAPI as a portable toolkit would probably even bring more developers to Haiku. QT got where it is today because of portability. The BeAPI is software rendered… you could literally do the opposite of what the QT port does and use QT as a window proxy for the BeAPI on other platforms.

4 Likes
#13

OK. Good. So copy/paste of the source is sufficient to have a Qt app from Linux to Haiku?

#14

OK, how do you imagine competing with Qt Company? Such a layer is a maintenance cost. We’re already understaffed, and you expect us to create and maintain a cross-platform API. How many people would do that? 1? 2? Qt Company has dozens of people just doing the API.

You could say More people will come and maintain the layer. I don’t believe that. People who ‘like’ fixing the underlying platform are already here. Everyone else is going to say this is buggy as hell, I’m going back to Qt. And that would be bad PR for the project itself.

I just don’t think we would have a competitive product. You think this is a good idea? Do it and prove me wrong.

Mostly, if you don’t have linuxisms in your app (but they would not be in the GUI).

2 Likes
#15

I don’t think anyone suggested writing a layer… just reuse QT as the layer, and take some things from Cosmoe etc… for the rest.

We already have a QT port that does just that with the BeAPI, why not just go backwards of that for other platforms…

#16

To be honest I’d like to see it happen, but I don’t think the project should have it as a goal. If somebody comes and does the work, cool, maybe even under a contract from the Inc. That’s still maintenance cost though.

6 Likes
#17

Despite having the ui kit ported to make apps in other OS being cool, In my mind just said “use crossplatform ready like QT” all along.

I would say GTK too (if fully ported), but that’s like wanting to hurt yourself, even working 100%.

PS: i tried to port Mono to get the UI in a managed C#, but the port-mono premise failed… 3 times.

#18

I would be against the Inc funding such things. We have enough to care about already.

It would be nice to see other projects using the BeAPI, we can collaborate with them on extending and documenting it, but this is clearly outside the scope of Haiku.

@cb88: I’m a bit wary of “just reuse” here. It would be a lot of work to get this going and then keep it working. And it would just do the same thing Qt is already doing, for the most part. What would be the selling point? What do the BeAPI do better than Qt? (except “runs natively on Haiku”, but who would care about that when you run it in Linux or Windows).

3 Likes
#19

SoundPlay has nothing special. I find very displeasing that I continuously see people ask things I planned to implement. You may not know that I have a WIP and now abandoned branch of MediaPlayer that introduces an add-on API compatible with that of SoundPlay. If you were looking about replacing SoundPlay, that was the moment you could have get something very close.

#20

I could argue the opposite. Beta is out, do you think it was a success? What happened to the glorious OS that at some point people even considered about making a mobile version of it? Prove me Haiku is suitable for productive use.

I will not go into the technical details for why it may be convenient, but the point is just one: being able to develop an app and run on other systems will automatically be a benefit for the whole ecosystem. I’ve been saying the same things as you for a lot of years, I am sure at some point you will change idea.