Linked by Thom Holwerda on Tue 27th Oct 2009 11:02 UTC
Qt The Haiku alpha is barely out the door, and we already have another important news item about the open source reimplementation of the BeOS. About 18 months ago, Evgeny Abdraimov started porting the Qt4 graphical toolkit to Haiku, and now, we ave some seriously epic screenshots showing a multitude of Qt4 applications running in Haiku, as well as a developer preview release.
Thread beginning with comment 391351
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: qt, not native
by moondevil on Tue 27th Oct 2009 13:20 UTC in reply to "RE: qt, not native"
moondevil
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.

Reply Parent Score: 7

RE[3]: qt, not native
by bornagainenguin on Tue 27th Oct 2009 13:43 in reply to "RE[2]: qt, not native"
bornagainenguin Member since:
2005-08-07

moondevil asked...

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?


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...
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.


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

Reply Parent Score: 5

RE[4]: qt, not native
by sbergman27 on Tue 27th Oct 2009 14:06 in reply to "RE[3]: qt, not native"
sbergman27 Member since:
2005-07-24

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,

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

Reply Parent Score: 5

RE[4]: qt, not native
by moondevil on Tue 27th Oct 2009 15:22 in reply to "RE[3]: qt, not native"
moondevil Member since:
2005-07-08

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.

Reply Parent Score: 1

RE[3]: qt, not native
by boldingd on Tue 27th Oct 2009 17:21 in reply to "RE[2]: qt, not native"
boldingd Member since:
2009-02-19

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.

Reply Parent Score: 5

RE[3]: qt, not native
by StephenBeDoper on Tue 27th Oct 2009 18:02 in reply to "RE[2]: qt, not native"
StephenBeDoper Member since:
2005-07-06

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."

Reply Parent Score: 4

RE[3]: qt, not native
by zittergie on Tue 27th Oct 2009 19:26 in reply to "RE[2]: qt, not native"
zittergie Member since:
2008-01-24

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.


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 ...

Reply Parent Score: 1

RE[4]: qt, not native
by cjst on Wed 28th Oct 2009 00:10 in reply to "RE[3]: qt, not native"
cjst Member since:
2009-03-30

[quote=zittergie]
so it's fun to have an application that can be compiled on Haiku, Linux, Windows & MacOS (or others) just the same.
[/quote]

It's fun only for the developers not for the users.

Reply Parent Score: 1