I am not familiar with the BeAPI.
Please start here:
http://www.haiku-os.org/legacy-docs/bebook/TheInterfaceKit_Overview.html
It’s a bit too late to start changing the GUI and framework this far into development. Haiku will be Haiku, it cannot suddenly change to QT. This would lengthen the time for the R1 Final to be released, and many applications would either be wasted or would have to be rewritten. In essence, a dangerous move.
Hi neonnds,
I think it may be a bit premature to recommend the replacing of the Haiku GUI API with Qt if you are not at all familiar with it. As Zenja said it was designed with multi-threading in mind and in that sense Be was way ahead of their time. But now Haiku is just in time to take advantage of all the multi-core CPUs now available. As we have all seen new speed gains in chips are really gained by adding more cores, and honestly few other operating systems are designed to take advantage of this as much as Haiku is.
So while Qt may be a fine framework it just is not designed with multiple threads in mind at the core. So it will always be behind or hard to use in that sense. And threads are just too deeply embedded in Haiku because of our BeOS heritage to replace our whole API with Qt.
But as everyone has said you can use Qt quite well on Haiku and the developers who ported it did such a good job some people think our port is better than that on other operating systems.
In addition Qt has certainly inspired some of the additions that we have made to the BeOS API, such as the layout kit. I’m also looking at the Qt animation framework to possible add something similar to Haiku, and the Qt network classes may inspire some of my work in making a Haiku network API for WebPositive.
Well i understand that Haiku and its APIs have been designed with multi threading in mind and what advantages this will bring. But to try and bring the haiku api up to the level of qt is going to be an up hill battle. I could be wrong.
But unless you are directly taking the Qt source and adapting it to Haiku i don’t see how Haiku can provide developers with the same feautre rich technology the Qt community grasp. I also wonder how many people will develop an application using the Haiku API which doesn’t allow them to move the application to another platform, when they can just use Qt.
I think doubling up on effort trying to produce a haiku version of Qt is somewhat futile. I hope it ends up that Haiku is even more awesome then it is now and people only want to develop for it using the haiku APIs.
Maybe the existing gui can be tightly coupled to Qt or something like that. Although i imagine such a design as being tedious and somewhat hidious.
Does anyone have documentation on how Haiku’s underlying kernel and interconnected components work together. I’m thinking diagrams and explainations. Maybe if i could read such material i could propose more sensible solutions.
Cheers.
[quote=neonnds]Well i understand that Haiku and its APIs have been designed with multi threading in mind and what advantages this will bring. But to try and bring the haiku api up to the level of qt is going to be an up hill battle. I could be wrong.
But unless you are directly taking the Qt source and adapting it to Haiku i don’t see how Haiku can provide developers with the same feautre rich technology the Qt community grasp. I also wonder how many people will develop an application using the Haiku API which doesn’t allow them to move the application to another platform, when they can just use Qt.
I think doubling up on effort trying to produce a haiku version of Qt is somewhat futile. I hope it ends up that Haiku is even more awesome then it is now and people only want to develop for it using the haiku APIs.
Maybe the existing gui can be tightly coupled to Qt or something like that. Although i imagine such a design as being tedious and somewhat hidious.
Does anyone have documentation on how Haiku’s underlying kernel and interconnected components work together. I’m thinking diagrams and explainations. Maybe if i could read such material i could propose more sensible solutions.
Cheers.[/quote]
they already have version 4.8 pretty much wrapped up and v4.7 works very well.
told ya before and I will tell you again. Plenty of working QT apps, help port apps for the QT framework. Its already done and AFAIK its the complete QT framework and its very native. Much much better then the linux implementation currently is.