To view parent comment, click here.
To read all comments associated with this story, please click here.
moondevil asked...
As a developer I would not care about the BeOS frameworks if my application is QT based.
If all functionality that my application requires is provided by the framework is already there, why should I look elsewhere?
Personally (and I hope to no offense) I hope you don't care about Haiku if you are a QT based developer. I really don't think this is about you if you are already a happy KDE developer, this is about something else altogether. This is about the applications.
As much as I love my Ubuntu desktop I am aware that (thanks to the tireless efforts of Linus Torvalds to cut out developers like Con Kolivas) Linux is not intended to be a desktop operating system, it is intended for servers. Haiku on the other hand has always been intended as a desktop operating system from the start and has performance to match. What the porting over of QT does for us is provide Haiku with the necessary applications any desktop operating system needs to survive.
Thanks to the efforts of FOSS desktop application developers there will be no chicken and the egg issues on other free operating systems like there were in the past for Linux.
moondevil asked...
Which is why I consider these applications to be a stopgap measure. They will eventually be replaced by better applications written for the Haiku platform itself and as such they will perform better and work better than the ports do. The whole pervasive multithreading was always more than just being buzzword-compliant you know...
How can 'simple' ports of QT applications possibly stand up to Haiku applications written to be able to take full advantage of the possibilities Haiku offers?
--bornagainpenguin
Edited 2009-10-27 13:48 UTC
Let's refrain from spreading disinformation. Con did some interesting and important work in bringing completely fair scheduling to Linux. But his scheduler had problems... which is OK. But his attitude was that the people reporting the problems were corner cases and didn't matter... which is not. Linus told Con so in no uncertain terms. Con threw a hissy fit.
Ingo Molnar decided to do more than just talk and wring his hands regarding the issue. He wrote a new completely fair scheduler, which also had its problems at first. But Ingo took on a more responsible and "work with" attitude toward the bugs and his users. Linus selected Ingo's scheduler because of that, and said so. Petulant Con took his ball and went home, but not without posting one last drama piece on the way out.
Of course, recently he has made noises suggesting a return. And early indications suggest that he intends to bring the drama with him.
Edited 2009-10-27 14:17 UTC
I am all for native Haiku applications.
Actually I am more interested to try out Haiku than Linux nowadays.
I had some contact with BeOS back in the day, and still have the old R5 CDs somewhere.
My comment was more to emphasis that contrary to what many people think, multiplatform toolkits also bring problems.
For example, lets say you are targeting MacOS X, then maybe your usage of some CoreXXX APIs is what will set your application from the rest. Or if you are targeting Windows, maybe there are also some Win32 API calls that will make your application shine, when compared with the available applications.
This is of course an experience that cannot be made multiplatform.
Sometimes you can only target a specific platform.
That's very much a false choice. Part of your application can use platform-neutral Qt code and part off the application can be platform-specific. In that case, whenever you port to a new platform, you only have to re-write the (ideally small) platform-specific bits. This arrangement makes porting easier, and it makes it much easier to keep the code-bases for the different platforms in sync.
There's a quote from Arthur C. Clarke that went "A faith that cannot survive collision with reality deserves few regrets."
IMO, the same principle applies to alt. OSes and ported applications. Apps written using the native API(s) will be better integrated with the OS, more consistent with other apps on the OS, etc. If those advantages aren't sufficient to make native apps more compelling than their ported equivalents, then that OS is probably "worth few regrets."
That's not entire true, you can use the framework as a gui for you multi-platform app, and for taking advantage of the used OS you can use OS DEFINES procedures.
That said, a lot of apps do not need any OS advantages, so it's fun to have an application that can be compiled on Haiku, Linux, Windows & MacOS (or others) just the same.
If someone would like to port freepascal (should be easy, foundation for BeOS is in the source)/lazarus (This is the hard part) to Haiku, it would rock my day ...





Member since:
2005-07-08
Why?
As a developer I would not care about the BeOS frameworks if my application is QT based.
If all functionality that my application requires is provided by the framework is already there, why should I look elsewhere?
This is exactly the problem of multiplatform GUI development.
If you want to take advantage of what makes a certain platform unique, your application will be tied to that system. If on the other hand you want to make your application work everywhere, then you have the problem that your framework can only provide common features.