A Belgian developer has ported parts of the OpenBeOS/BeOS toolkit and API to Windows. This is not the first time something like this is being done, but possibly it is the most advanced of the efforts. This is also similar to what the B.E.O.S. team does, trying to port the BeOS API to Linux. Update: Xentronix project leader seems to have stop developing BeOS apps and the Sequel OS, citting personal reasons.
Projects like this one allow developers that want to develop for a certain OS to do so without the fear of loosing out on the Windows market. Apple should release Cocoa for Windows since they already have it made (OPENSTEP for NT and YellowBox for Windows were released by NeXT and Apple respectively and allowed OPENSTEP/Cocoa applications to run on Windows). Not to mention the fact that both Cocoa and Be offer much easier and cleaner development enviornments that may attract some developers that don’t care about the alternative OSs at all, but are looking for an easier way to develop for Windows.
One thing that I have to get out is that it [OBOS toolkit for Windows] won’t be adopted by developers as a valid way to write Windows programs until it uses native (or native-looking like Mozilla) widgets. A lot of people have enough trouble using a computer without dealing with multiple widget types. People get thrown when something doesn’t look the way that they are used to things looking.
This might just be an early version of WinOBOS so the author might have everything native-looking before OBOS is even released.
I know a lot of people on this site make a big deal about native widgets and consistency, but I honestly think the average user does not notice such things. I personally notice it, but I think I’m in the minority.
it is noticeable, but not as much as differences in menu layout. mainly it is the difference in where the prefferences of the application are at and such things. I heard somewhere that on mac computers those interfaces are more consistent in design and I think that plays a bigger role in making things easier than what the widget look like. basically, imo, consistency in interface layout plays a huge role and few operating systems have it. not even windows.
I think people notice, but don’t particularly care. I mean, if you’re aiming for strong UI, it’s a hum-dinger, but if you’re focusing on just getting that functionality thing down, people are very forgiving.
Of course, that doesn’t mean Linux doesn’t have odd-widget UI scars.
This is great but I am looking forword to the OBOS and B.E.OS
I have often wanted something like this in order to develop with friends who use windows. I was hoping it would arrive when Gobe Prod v3 was supposed to be open sourced as the windows version included this technology.
What I would love to see next, is Windows API-> BeOS!
Nice done BNickname!
Iam really looking forward to see this with my own eyes.
Thanks!
/Konrad
IF this project is based at 95% on the OpenBeOS source code, could someone explain me how the screenshots show UI components implemented in the OpenBeOS CVS as:
float BFont::StringWidth(const char *string) const
{
// TODO: implement
return 0.0;
}
or non existing classes like TextView…
My personal opinion is that the author did alone this huge work (app_server + 80% of the libs) in a year, and tweaked it with a minimalsit app_server (maybe 1 per application) and a big win32 ‘glue’ in the libs themself.
Regards,
Guillaume
So can I expect to see OpenTracker soon? The idea of a BeOS desktop on Windows is very appealing, then I can keep 2 comps running at the same time, the real thing, & Windows made cool.
The idea of using BeOS API on other platforms is absolutely the way to go, platforms have a hard time to run away. In the reverse case, its always a moving target.
WinBe was the other project, not sure how far that got.
check out the OpenBeOS site and see what they have to say about this…
http://open-beos.sourceforge.net/news.php
they have a link to the interface kit mailing list:
http://www.freelists.org/archives/interfacekit/03-2003/msg00072.htm…
pointing to conversations with this developer
TextView is not non-implemented. There is a whole folder of text-view related files, with many methods completed. The last time I looked it was “incomplete, but working”.
Many of the BFont methods call the app server, as I understand, so these would have to be written differently for the developer’s own app server anyway.
Plus, Marc (who appears to be the developer) is the author of most of the OBOS interface kit items, so he may have more up to date code locally than in the CVS.
Just because the article is about something related to OBOS, does not mean you have to post a sneering comment about the project.
I wish you luck with B.E.OS, and I hope OBOS make something worth using too.
“My personal opinion is that the author did alone this huge work”
Sorry if I seem critical, but I read your post as attempting to undermine the efforts of OBOS. Surely you don’t want to give this impression? Just seems odd to me…
it’s a bigger news for beos developper than anything else, and beneficiary to all project. App that ask for lot of power being not 100% native under window (at least about as native as SDL can be) might be preferred in window api compiled binary.
But for utility and all the stuff that always have to ask for user input, it’s great. In fact this would act better than visual basic stuff we see all around (entire developper live just on that).
As for window developper addopting it so we could have BeOS port of it, chance are slim but they exist. I guess we could see some like we often see SDL allegro etc… app on win32. Even is the % is real small, the size of the pool of win32 develloper is big enough so a small % would show a big increase on bebits.
So, in the end, the shareware market is the real winner and the average BeOS user because if our develloper do moeny they can code more! I guess nothing prevent this to be ported to amiga or plain unix.
awwwwwww…
I feel sorry for him, I hope they are able to work it out.
Such a waste of good developer time. BeOS is dead guys. So porting a dead API to other platforms where it will
be layers above where it should be implemented just means
it’s still dead.
Use your talented skills on something useful.
Zeta is the new BeOS, so it’s not a waste of time at all.
Such a waste of good developer time. BeOS is dead guys. So porting a dead API to other platforms where it will
be layers above where it should be implemented just means
it’s still dead.
It’s quite common for rich, sickly old men to get fresh organs from dead youngsters.
You should read news more often. BeOS is hardly dead, on the contrary, it’s more alive than ever.
Even if it would take 2 more years for OBOS to come out (which is very pessimistic time frame), it would still be years in front of Windows for the desktop, and I guess that means it’s decades in front of Linux….
So there’s really not pressure on the OBOS devs….
However, it’d be a tragic loss if Frans work would go down the drain…
> It’s quite common for rich, sickly old men to get fresh organs from dead youngsters.
Perhaps, but it sure is not common to try to retrofit another kidney in a perfectly healty body… Even if the kidney comes from a good sprinter.
Just to let yall all know,
This BeOS on windows here was something OpenBeOS started themselves.
They did this so they could get attention.
They are playing every one!
> in a perfectly healty body
I don’t find windows to be in a perfectly healthy condition… It’s just like every other American: getting more and more weight
Also, just to let you know the opposite of this BeOS-gui-runs-on-win effort, the sources of “WinBe” (which seems to be a Wine-like library) has been published on SourceForge:
http://sourceforge.net/projects/winbe/
Btw, I’m very sad for Frans, he deserves better.
Geez, what a requiem for the best OS ever made. Don’t get me wrong, if OBOS gains a little more momentum I’ll go back, but for time being Windows runs on cheap hardware and Mac OS X (.2) provides me with the best user experience.
At least the BeOS world is still pretty much togather on the OBOS. For the polar opposite check into the Amiga scene (a beautiful way to screw an OS)
Use your talented skills on something useful.
Who are you, moron, to decide on what programmers should put their OWN PERSONAL FREE TIME on ?
An easy way to port all those beos apps , like … or … um yeah – great 🙂
Thank you for all support, Frans!
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~
This is fantasic, it’s a shame its not Win32 L&F native, which means I still will have too either learn the Win32 API, the MFC or wxWindows. Ahh well